DocsZero-code captureBrowse
Getting started
Reference

Zero-code capture

Two paths put a record under agents you cannot or would rather not touch: a pipeline you already run, and a gateway you already run. Both are stated with their limits, because a capture path sold as complete is the one thing a compliance record must not be.

An OpenTelemetry pipeline you already run

Add one exporter to your Collector. POST /v1/traces is the standard OTLP path, so the generic endpoint is enough; the body may be protobuf or JSON, gzip or plain; and the mapper is the same one the SDKs apply in-process, held to parity by test. The file below is in the repository at deploy/otel-collector/config.yaml, verified under otelcol-contrib.

deploy/otel-collector/config.yaml
receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }

processors:
  batch: {}

exporters:
  otlphttp/auditant:
    endpoint: ${env:AUDITANT_ENDPOINT}          # https://api.auditant.co
    headers:
      authorization: "Bearer ${env:AUDITANT_API_KEY}"   # or x-auditant-webhook-secret
      x-auditant-log: ${env:AUDITANT_LOG_ID}
    compression: gzip
    encoding: proto

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/auditant]

No Collector? Any OTel SDK reaches the same endpoint with two environment variables and nothing installed:

two env vars
OTEL_EXPORTER_OTLP_ENDPOINT=https://api.auditant.co
OTEL_EXPORTER_OTLP_HEADERS=authorization=Bearer%20ak_…,x-auditant-log=tenant_acme/prod

A Collector config file is the least protected place a credential lives, so the write-only webhook secret is accepted here as well as the API key: leaking it costs spam, never disclosure. The agent on the record is the resource attribute auditant.agent_id, then the x-auditant-agent header, then OTel's own service.name.

A gateway you already run

One callback line on a LiteLLM gateway captures every model call from every agent behind it — including agents whose source you don't control — with MCP tool calls promoted to first-class tool_call events. The gateway can also enforce: its pre-call hook asks decide() and refuses or holds the request when armed (AUDITANT_ENFORCE=1); it starts in record-only mode, because a compliance product that blocks production traffic on install does not get a second call.

config.yaml
callbacks: auditant.gateway.handler
# AUDITANT_API_KEY, AUDITANT_LOG_ID, AUDITANT_ENDPOINT in the gateway's env

What zero-code cannot do

stated plainly
blocking       nothing arriving over OTLP can be stopped — spans describe what already
               happened. The gateway can refuse a model call; only the SDK's guard()
               can stop a tool before it runs.
custody        hashes only over OTLP. There is no customer-side sink on a server that
               received a span. Mode B custody is an SDK feature.
completeness   only what your spans say. A tool call your framework emits no span for
               is not on the record, and the coverage report says so.
TLS            we do not intercept your HTTPS traffic, and will not. Capture is what
               your process chooses to export or route — never a proxy in your path.

Each of these is a deliberate line. The alternative on offer elsewhere — a proxy that terminates your TLS to read prompts — would put every payload through a third party to produce a record whose whole argument is that payloads never travel.