Safeguard
AI Security•

What should you log when an AI agent acts on your systems?

Log who asked, what the agent saw, which tool it called, with what arguments, and what came back. Keep logs tamper resistant and tied to a human identity.

Safeguard Security Team
5 min read

When an AI agent acts on your systems, log the human or service it acted for, the instruction, each tool call with its arguments and result, any approval, and the model and version in use. Store the records away from the agent, so a compromised agent cannot edit its own history.

Why is a normal application log not enough?

A traditional service runs code you wrote. An agent chooses its next step at run time, based on text it reads. OWASP calls the resulting risk Excessive Agency: damaging actions taken in response to unexpected, ambiguous or manipulated model output. The triggers it lists include hallucination, prompt injection from a user or from content the agent fetched, and a compromised peer agent in a multi-agent setup.

That changes what you need from a log. "The API received a DELETE" is not enough. You need to know why the agent sent it, whose authority it used, and what it had read just before.

What fields belong in each record?

Think in terms of one request and its chain of steps.

  • Identity. The end user or service the agent acted on behalf of, the agent's own identity, and the session. OWASP advises running extensions in the user's context, with the minimum scope, so the downstream system already sees the real identity. Log it on your side as well.
  • Input. The user prompt, plus references to retrieved documents or web content the agent used. Store hashes or pointers if the content is sensitive.
  • Decision. The tool the agent chose, and the arguments it passed. This is the most useful field when you investigate.
  • Result. What the tool returned, or an error, with a status and a size.
  • Approval. Whether a person approved the step, who, and when. OWASP lists human approval for high impact actions as a control.
  • Version. Model name and version, prompt template version, and tool definitions. Behavior shifts when any of these change.
  • Time and ordering. Synchronized timestamps and a sequence number, so you can rebuild the order.

How do you keep the logs trustworthy?

Logging that the agent itself can write to, or delete, is weak evidence. Ship records to a store the agent has no rights to modify. Append-only storage, or a log service with write-once retention, is the usual answer. NIST SP 800-92, the guide to computer security log management, covers the general practice: define what you log, protect it, and set retention that matches your needs.

Watch for secrets. Prompts and tool arguments can contain credentials or personal data. Redact before storage, or you will have created a second sensitive data store with weaker controls.

OWASP is direct about the limit: logging and monitoring do not prevent excessive agency, they limit the damage and speed up response. The prevention work is still least privilege, narrow tools, and approval for risky actions. Treat logs as the second line.

Is there a legal angle?

For some systems, yes. Article 12 of the EU AI Act says high-risk AI systems must technically allow for the automatic recording of events over the lifetime of the system, to support traceability. Whether your system counts as high-risk is a legal question. Check it with counsel rather than assuming.

How does this apply to MCP and tool access?

If agents reach your systems through MCP servers, the tool call is the natural logging point. Safeguard's MCP server at mcp.safeguard.sh acts with the permissions of the signed-in user and only exposes the tools a workspace administrator has switched on, which keeps the call surface small and the actor clear. Whatever server you use, log on the server side too, not only in the agent client.

What to do

  1. Inventory every agent and every tool it can call. Remove tools it does not need.
  2. Define the record schema above and apply it in one place, a gateway or server, not in each agent.
  3. Run tool calls under the end user's identity wherever possible.
  4. Send records to storage the agent cannot write to or delete.
  5. Redact credentials and personal data before they are stored.
  6. Require and record human approval for destructive or external actions.
  7. Alert on unusual patterns, such as a sudden jump in tool calls or a tool never used before.
  8. Test it. Pick a recent agent action and see whether you can explain it from the logs alone.

Quick check

Should I log full prompts?

Usually log them, with redaction and access controls. Prompts explain why an agent acted. If they contain sensitive data, store a reference or a hash and keep the original in a restricted store.

Do logs stop a prompt injection attack?

No. They help you detect and investigate one. Prevention comes from least privilege, narrow tools, approval for high impact steps and checks in the downstream system.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.