Keep access tokens, passwords, keys, connection strings, session identifiers and sensitive personal data out of AI agent logs, or mask, hash or encrypt them before writing. Log who, what, when and the outcome of each action, not the secret the agent used to do it.
Why agent logs are riskier than most
An agent's prompts, tool arguments and tool results often contain whatever the agent was working on. That can include customer records, source code, and credentials pasted into a conversation. Write all of it to a log and you have created a second copy of your most sensitive data, usually with weaker access control than the original.
OWASP's logging guidance lists what should usually not be recorded directly and should instead be removed, masked, sanitized, hashed or encrypted: application source code, session identification values, access tokens, sensitive personal data, authentication passwords, database connection strings, encryption keys and other primary secrets, and payment data. Every item on that list can appear in an agent's input or output.
A practical keep and drop table
| Item | Log it? | How |
|---|---|---|
| Agent identity | Yes | As is |
| Tool name and action type | Yes | As is |
| Target resource ID | Yes | As is, if not itself sensitive |
| Timestamp and outcome | Yes | As is |
| Approval decision and approver | Yes | As is |
| Access tokens and keys | No | Never store; log a token ID or hash if needed |
| Full prompt text | Careful | Short retention, redact secrets |
| Tool arguments with personal data | Careful | Mask fields, log field names |
| Full file contents read by the agent | No | Log path and size instead |
| Session IDs | Careful | Hash if you need to correlate |
Steps to set it up
- Define a log schema for tool calls with fixed fields, so engineers do not dump raw objects.
- Add a redaction step before the logger, with patterns for tokens, keys and common personal data fields.
- Replace secrets with references. A log line that says credential id 4821 was used is far safer than one that shows the credential.
- Log content at a separate, shorter retention tier if you need it for debugging, with tighter access.
- Test with fake secrets. Send a dummy token through the agent and grep the logs for it.
- Review access to logs periodically. OWASP advises restricting read privileges and reviewing them.
Watch for log injection
Agents read untrusted text, and untrusted text can end up in your logs. OWASP points to log injection and CWE-117 as attacks on logs. Treat anything the model or a tool returns as untrusted data: encode it, and never let it forge a new log line.
The conflict with debugging
Developers want full traces. Security wants less. A workable compromise is a debug mode that is off by default, switches on per agent for a limited time, writes to a restricted store, and expires. Make the switch itself a logged event.
What about the legal side
Some data should not be collected at all. OWASP notes that logging certain communications, monitoring employees, or collecting data without consent can be illegal. Ask your privacy team before you start capturing full conversations with people.
Safeguard's policies and guardrails help control what agents can reach, which reduces what ends up in their logs, and a free scan is available at https://gold.safeguard.sh/scan.
Quick check
Is it fine to log the full prompt for debugging?
Only with redaction, a short retention period and restricted access. Prefer logging metadata by default.
How do I prove a secret is not in my logs?
Pass a fake token through the agent in a test and search the logs for it. Repeat after each logging change.
Sources
Last reviewed: 19 October 2026.
