docs/documentation/platform/agent-proxy/activity-logs.mdx
Activity logs record what the agent proxy did with each request: which agent called which host, and which credential was applied. Together they form an audit trail of every credential your agents used, and a way to spot blocked or failed requests. Both setups produce the same records; only where they are written differs, so Where the records go has a section for each.
<Note> Only requests that reach the forwarding stage are logged. Requests rejected earlier (malformed proxy auth, an invalid `CONNECT` target, TLS failures) never reach it and aren't logged. A request whose identity can't be resolved at forwarding is still logged as an `error`, just with an empty agent. </Note>Each request is logged with these fields (plus the standard time, level, and message):
| Field | Meaning |
|---|---|
event | Always agent-proxy.request, so activity is easy to filter from other logs |
decision | brokered, passthrough, blocked, canceled, or error |
agentId / agentName | Who made the request: the agent's machine identity behind a standalone proxy, or your own account (or token) on a local proxy |
projectId / environment / secretPath | The folder the request was scoped to |
serviceName / serviceId | The matched proxied service (omitted when none matched) |
method / host / port / path | The request line, before substitution (so path shows the placeholder) |
status | Upstream status on brokered / passthrough; 403 on blocked; 502 on error; omitted on canceled, where no response was ever returned |
credentials | What was injected: each entry's secret key (or, for a dynamic secret, its name and output field), and the header or surfaces it landed in |
Written out, two records look like this:
2026-07-17T14:32:09 INF agent request event=agent-proxy.request decision=brokered agentName=claude-agent serviceName=github method=POST host=api.github.com path=/repos/acme/app/issues status=201 credentials=[{"key":"GITHUB_PAT","role":"header-rewrite","header":"Authorization"}]
2026-07-17T14:32:12 WRN agent request event=agent-proxy.request decision=blocked agentName=claude-agent host=evil.example.com method=GET status=403
Each decision is logged at a level, so --log-level controls how much you see: the default info hides passthrough and canceled requests, debug shows everything, warn shows only blocked and errors.
| decision | level |
|---|---|
passthrough | debug |
canceled | debug |
brokered | info |
blocked | warn |
error | error |
canceled means the agent hung up before the request finished, which happens when you interrupt a prompt or the agent exits mid-request. Nothing failed and there was nobody left to answer, so these stay at debug and off your terminal. A request that really failed, an unreachable upstream or permissions that could not be resolved, is still an error.
Nothing is written unless you pass --log-file, since the agent owns the terminal and a file you did not ask for is one you cannot find. With it, records go to that path and you can tail -f them:
infisical secrets agent-proxy run -e dev --log-file=/tmp/broker.log -- claude
The file is written in the human-readable format shown above, and is appended to on every run without being rotated for you, so use logrotate (copytruncate) if you keep one around. Without the flag, warnings and errors still print to your terminal; only the per-request trail is dropped.
Records go to stderr, so whatever supervises the proxy collects them. --log-format sets their shape, and --log-file additionally writes json to a file, which lets you watch a readable stream while persisting machine-readable records for a collector:
# Watch live, readable (default)
infisical secrets agent-proxy start
# Watch the console and also persist json (e.g. for a SIEM)
infisical secrets agent-proxy start --log-file /var/log/infisical/agent-proxy.log
# Container: json on stderr for your platform to collect
infisical secrets agent-proxy start --log-format json
In json, the same record looks like this:
{"level":"info","time":"2026-07-17T14:32:09+05:30","message":"agent request","event":"agent-proxy.request","decision":"brokered","agentId":"9c1e40cf-...","agentName":"claude-agent","projectId":"53c8b330-...","environment":"prod","secretPath":"/coding-agent","serviceName":"github","method":"POST","host":"api.github.com","port":443,"path":"/repos/acme/app/issues","status":201,"credentials":[{"key":"GITHUB_PAT","role":"header-rewrite","header":"Authorization"}]}
To keep records long-term, forward that output with a collector such as Fluent Bit or the OpenTelemetry Collector to your logging platform: Splunk, Datadog, Elastic, or anything else. For rotation, containers let the platform rotate the stream; for --log-file, use logrotate with copytruncate.