State what each log records (user, agent, tool, time, outcome), where it is stored, how long it is kept, who can read it, and what is deliberately left out, such as full prompt text or credentials. If logging has gaps, name them and give a date instead of saying "full audit trail".
Why "full audit trail" backfires
Reviewers have seen the phrase on many forms. They follow it with "show me an example entry". If your logs record that an agent connected but not which tool it called, the claim falls apart. Specific scope is safer than a grand label.
The MCP tools specification suggests clients log tool usage for audit purposes. It leaves the details to you, so a reviewer will probe the details.
The fields worth recording
- Who: the human user and the agent identity acting for them.
- What: the server, the tool name and a reference to the arguments.
- When: timestamp with a consistent time source.
- Result: success, error or denial, and the reason for a denial.
- Where from: client application and session reference.
Be careful about arguments. They can contain customer data or secrets. Many teams log a hash or a redacted form and keep the full text only in a restricted store. Whatever you choose, say it.
Four questions that follow
- Retention. How many days, and is it set by policy or by default storage limits?
- Access. Who can read the logs, and is that access itself logged?
- Integrity. Can an administrator edit or delete entries, and would you notice?
- Use. Does anyone actually review them, and what triggers an alert?
The fourth question separates a log from a control. If nobody reviews them, say that logs support investigation after an incident, and describe what you have planned for alerting.
Sample wording
"Tool calls made by agents through approved MCP servers are logged with user, agent identity, server, tool, timestamp and outcome. Argument values are redacted before storage. Logs are kept for a period set by our retention policy and are readable by the security team. Deletion requires a second approver. Alerting covers repeated denials and calls to destructive tools; broader anomaly review is planned."
Check each clause against how your system really works, then date the answer.
What the log should not contain
Passwords, tokens and keys. If a token appears in a log, treat it as exposed and rotate it. The MCP security guidance lists log leakage as one way an attacker can obtain a broad token, which is a good reason to keep credentials out of log lines in the first place. See also what MCP says about audit logging and what is left to you.
Evidence
A sanitised sample entry, the retention setting and the access list. Safeguard supports this with agent identity, which ties actions to a named agent, and compliance and evidence automation for keeping records ready.
Quick check
Do we log the full prompt?
Only if you have decided to and protected it. Full prompts may include customer data, so many teams store metadata and keep prompts under tighter access.
Is application logging from the vendor enough?
Ask what the vendor logs and whether you can export it. If you cannot see it, you cannot answer for it, so state the dependency.
Sources
Last reviewed: 19 October 2026.
