Log who used the agent, which tools it called, what permission decisions were made and which MCP servers connected. Keep prompt text, tool output and raw API bodies off unless you have a clear reason, because they can hold secrets and customer data. Claude Code's documented telemetry follows this split, with sensitive fields as opt-ins.
Definitions
Metrics. Counts and totals, such as sessions, tokens and commits.
Events. Individual records, such as a tool decision or an API request.
OpenTelemetry (OTel). A standard way to export metrics, logs and traces to a backend you choose.
What to log, with the sensitivity
| Data | Example from the documented telemetry | Default stance |
|---|---|---|
| Session counts and active time | Sessions started, active time | Log |
| Tool decisions | Accept or reject decisions for edit tools, tool decision events | Log |
| MCP connections | MCP server connection events | Log |
| Token and cost usage | Tokens by type, cost | Log for spend control |
| Prompt text | Redacted by default, only length recorded | Off |
| Tool details | Bash commands, tool inputs, MCP names, opt-in | Decide per risk |
| Tool output | Opt-in in traces | Off |
| Raw API bodies | Full request and response, including conversation history | Off, the most sensitive |
| Identity fields | Email and account IDs included when available | Log, with access controls |
Steps
- Decide the questions you need to answer. Who ran an agent against this repository? Which servers connected? What did it run when something broke?
- Turn on metrics and event export to your own backend, so you control retention and access.
- Leave content logging off by default. The documentation says prompts are redacted by default and the settings for tool details, tool content and raw bodies are separate opt-ins.
- If you must capture commands, enable tool details for specific groups and restrict who can read the logs.
- Control who can enable export. The documentation says project-level settings cannot turn on the exporter variables. Only managed settings, the shell or user settings can, so deploy the configuration through managed settings.
- Treat identity fields as personal data. Apply your retention and access rules.
- Alert on patterns, such as a new MCP server connecting from many machines or a spike in rejected tool decisions.
- Test redaction. Run a session with a fake secret in the prompt and confirm it does not appear.
What logs cannot do
Logs record what happened. They do not prevent it, and an agent's own report of its actions should be checked against these records. Pair logging with permissions and approvals.
Quick check
Should we log full prompts for investigations?
Only if you accept holding sensitive content. Many teams log decisions and tool names and enable richer capture temporarily during an incident.
Who should read agent logs?
Security and platform owners, with access controls. Developers can see their own sessions if you wish.
Do other agents log the same fields?
No. Use this table as a checklist and check what your tool exports.
Where Safeguard fits
Safeguard offers asset discovery, agent identity and compliance evidence automation, which help turn agent activity records into audit evidence. You can start with a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
