For every agent tool call, log who the agent acted for, which agent acted, which tool and arguments, what approval applied, and what came back. The MCP specification asks clients to log tool usage for audit, and its security notes show how blurred identities make investigation hard.
Why the logs matter
When an agent does something wrong, the questions come fast. Who asked for it? Which agent did it? Was it approved? What data moved? If the log cannot answer, you are guessing.
The MCP tools specification says clients should log tool usage for audit purposes. The security best practices go further, noting that when downstream logs show requests from a different source or identity, incident investigation, controls and auditing get more difficult. The scope guidance recommends logging elevation events with the requested scope, the granted subset and correlation IDs.
The fields
Group them by the question each answers.
Who:
- The end user the agent acted for, from the validated token.
- The agent identity, kept separate from the user. If you use delegation tokens, record both.
- The client application and version.
What:
- The tool name and server.
- The arguments, with sensitive values redacted or hashed.
- The result status, an error flag if any, and a short result summary, not the full content.
Under what authority:
- The scopes in the token and any elevation that occurred.
- The approval record: who approved, when, and what they saw.
- The policy decision, if a policy engine allowed or blocked the call.
How to join it up:
- A correlation ID shared across the user request, the agent steps and the downstream calls.
- A session ID, logged beside the user so a mismatch shows up.
- Timestamps in one time standard.
What not to log
Do not log access tokens, refresh tokens or full secrets. The authorization specification warns that tokens cached or logged on the server are a theft route. Keep full prompts and results out of general logs when they may hold personal data, or store them in a restricted place with a short retention period.
Protect the log
Store logs where the agent and the tool server cannot edit them. An attacker who controls an agent will try to hide the trail. Send events to a separate system with append only behavior and limited access.
Useful alerts
- The first use of a tool by an agent that has never called it.
- A scope elevation.
- A denied call followed by a similar call using different arguments.
- A call volume spike for one agent.
- Approval granted in under a second, which often means reflex clicking.
A test of your logging
Pick one action your agent took last week. Using only the logs, answer who, which agent, which tool, what approval, and what result. If any answer is missing, you have found the next field to add.
Where Safeguard fits
Safeguard includes agent identity and compliance evidence automation, which are aimed at keeping a record of agent activity and turning it into evidence. Your own tool servers still need to emit good logs.
Quick check
Should I log full tool arguments?
Log what you need to reconstruct the action, and redact or hash sensitive values. Full copies of personal data in logs create a second exposure.
Sources
- MCP tools specification, security considerations
- MCP security best practices
- MCP authorization specification
Last reviewed: 19 October 2026.
