Activity Logs

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.

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.

What’s in a record

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

A record never contains a real secret. Requests are logged as the agent sent them, before the swap, so path shows only the placeholder; credentials lists secret names, not values; header values and request bodies are never logged.

Log levels

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.

Where the records go

Local proxy

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.

Standalone proxy

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.

Next steps

agent-proxy CLI reference

Every flag for start and connect, including the logging options.

Audit Logs

Configuration changes to your proxied services are recorded in Infisical’s own audit trail.

Secrets Management

Product Reference

Integrations

What’s in a record

Log levels

Where the records go

Local proxy

Standalone proxy

Next steps

agent-proxy CLI reference

Audit Logs

​What’s in a record

​Log levels

​Where the records go

​Local proxy

​Standalone proxy

​Next steps

agent-proxy CLI reference

Audit Logs

What’s in a record

Log levels

Where the records go

Local proxy

Standalone proxy

Next steps