Most AI agent deployments produce plenty of telemetry, yet the records an investigator needs after an incident are often the ones nobody captured. Model traces show prompts and token counts; the identity provider shows a service account signing in; the SaaS audit log shows a file being shared. What links them, which tool was called with which arguments, on whose behalf, after reading what, is frequently missing. This list ranks ten blind spots by how often they stop an investigation, with the specification evidence behind each and the control page that closes it. It is for SOC leads, detection engineers and agent platform owners who already run agent monitoring and want to find its gaps. For the monitoring programme itself, see the Agent Controls and Monitoring Guide; for the record format, see the AI Agent Audit Log Schema Template.
The Top 10 at a glance
The table lists each blind spot, what the gap looks like during an investigation and the first fix. Each is explained below.
| # | Blind spot | What you cannot answer | First fix |
|---|---|---|---|
| 1 | Tool-call arguments and results | What exactly the agent asked the tool to do | Capture arguments to a restricted store, reference them from the span |
| 2 | Delegated identity collapsed to the agent | Which human the action was for | Record subject and actor separately on every action |
| 3 | MCP proxy and server hops | Which client and server sat between agent and API | Audience-bound tokens and a shared correlation ID per hop |
| 4 | Memory writes | When a persistent instruction entered memory, and from where | Log every write with source and content hash |
| 5 | Tool definition changes | Whether a tool's description changed before the incident | Hash and diff tool lists on every refresh |
| 6 | Untrusted content provenance | Which document or page preceded the bad action | Log retrieval sources against the step that used them |
| 7 | Approval decisions | Who approved, and what they were shown | Log approver, displayed arguments and decision |
| 8 | Scope elevation and token issuance | When the agent gained broader rights | Log requested versus granted scopes with correlation IDs |
| 9 | Sub-agent and agent-to-agent calls | Which agent started the chain | Propagate trace context and a parent agent ID |
| 10 | Local MCP servers and stdio processes | What ran on the developer laptop | Inventory local servers and log process launches |
1. Tool-call arguments and results
The blind spot: traces show that a tool ran but not what it was asked to do. The OpenTelemetry GenAI semantic conventions (status: Development) say instrumentations "SHOULD NOT capture" instructions, inputs and outputs "by default", and the default pattern is not to record them. The execute_tool span carries gen_ai.tool.name and gen_ai.tool.call.id; the arguments sit inside the opt-in gen_ai.input.messages content.
Why it matters: "the agent called send_email" and "the agent emailed the customer database to an outside address" look the same without arguments. The MCP tools specification says clients SHOULD "Log tool usage for audit purposes" and show tool inputs to the user before calling the server.
What closes it: follow the convention's production pattern of storing content externally and recording references on spans, so security can read arguments under separate access control while operations teams see metadata only. Redact secrets and personal data at write time. See the Agent Observability vs Audit Logging.
2. Delegated identity collapsed to the agent
The blind spot: downstream logs show the agent's service account or workload identity, not the user the agent acted for. When five people share one agent, every action looks like the agent's own.
Why it matters: RFC 8693 defines the act claim to express "that delegation has occurred" and identify the acting party, with nested act claims recording prior actors. It also says a token consumer must consider only the top-level claims and the current actor, so the history is informational: if you do not log it at issuance, it is lost for investigation.
What closes it: use token exchange so access tokens carry the user as subject and the agent as actor, and write both, plus the full chain, into the audit record. See the OAuth Token Exchange and Delegation Guide and Delegation Chains and Attenuated Authority for AI Agents.
3. MCP proxy and server hops
The blind spot: an agent reaches a SaaS API through an MCP client, possibly a gateway, and an MCP server acting as an OAuth client. Each layer logs its own view and none shares an identifier.
Why it matters: the MCP security best practices list "Accountability and Audit Trail Issues" as a risk of token passthrough: the server cannot distinguish clients, and downstream logs "may show requests that appear to come from a different source with a different identity". Token passthrough is forbidden: MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server."
What closes it: enforce audience-bound tokens at every hop, route remote servers through a gateway that stamps a correlation ID, and require servers to log the client ID that called them. See the MCP Gateway and MCP Server Governance Guide and the MCP Authorisation Specification Guide.
4. Memory writes
The blind spot: long-term memory and stored summaries change silently. MITRE ATLAS lists AML.T0080.000 AI Agent Context Poisoning: Memory, where an injected instruction persists across sessions.
Why it matters: the harmful action may happen days after the write, in a session with no suspicious input at all. Without a write log you cannot find the origin or the other sessions it affected.
What closes it: log every memory write with session, source content reference, writer (agent or user) and a content hash, and alert on writes containing imperative instructions or URLs. See the AI Agent Memory Poisoning Guide.
5. Tool definition changes
The blind spot: tool descriptions are read by the model as instructions, yet few teams keep their history. The MCP tools specification lets servers send notifications/tools/list_changed and says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers."
Why it matters: ATLAS AML.T0110 AI Agent Tool Poisoning covers malicious content in tool metadata. A description that changed after approval explains behaviour that no prompt log will.
What closes it: hash each tool's name, description and inputSchema on every tools/list, store the history and alert on change to an approved tool. See MCP Tool Poisoning Detection.
6. Untrusted content provenance
The blind spot: the log shows the agent's action but not the email, web page, ticket or retrieved chunk it read just before. ATT&CK T1698 Indirect Prompt Injection describes instructions planted in content the agent processes.
Why it matters: investigators need to know which input changed the plan and which other agents ingested the same content.
What closes it: record a source identifier and trust label for each retrieval or fetch, linked to the step ID of the next tool call; alert when a high-impact action follows untrusted input in the same step. See the MITRE ATT&CK T1698 Indirect Prompt Injection.
7. Approval decisions
The blind spot: a human-in-the-loop prompt is recorded as "approved" with no approver, no timestamp and no copy of what was displayed. The MCP tools specification says there SHOULD always be a human able to deny tool invocations.
Why it matters: if the approver saw a summary rather than the real arguments, the control did not work, and you cannot prove either way. Rubber-stamp patterns (approval in under two seconds, 100% approval rates) stay invisible.
What closes it: log approver identity, the exact arguments shown, decision and latency. See the Human-in-the-Loop for AI Agents Guide.
8. Scope elevation and token issuance
The blind spot: the agent starts with read scopes and gains write or admin rights mid-session, but only the original grant was reviewed. The MCP guidance on scope minimisation tells servers to "Log elevation events (scope requested, granted subset) with correlation IDs" and lists "Audit noise: single omnibus scope masks user intent per operation" as a risk.
What closes it: log token issuance and every step-up from the authorisation server, alert on first use of a privileged scope by an agent, and ban omnibus scopes. See the Agent Identity and Access Guide.
9. Sub-agent and agent-to-agent calls
The blind spot: an orchestrator spawns sub-agents or calls another team's agent, and each starts a fresh trace. The OpenTelemetry conventions define gen_ai.conversation.id to correlate messages, but it is only populated "when available".
What closes it: propagate W3C trace context and a parent agent ID across every agent boundary, and reject inter-agent calls that arrive without them. See the Multi-Agent and A2A Security Guide.
10. Local MCP servers and stdio processes
The blind spot: coding agents launch local MCP servers on laptops through configuration files. The MCP security best practices list "No visibility" among the risks, since users "have no insight into what commands are being executed", and advise proxies to "Log all stdio transport usage for security monitoring".
What closes it: inventory MCP client configurations through endpoint management, alert on new server launch commands through EDR process telemetry and keep an approved server list. See How to audit MCP servers on developer laptops and the Local MCP Server Security Guide.
Mapping to OWASP
OWASP LLM06:2025 Excessive Agency advises teams to "Log and monitor the activity of LLM extensions and downstream systems". The table maps each blind spot to the OWASP Top 10 for LLM Applications 2025, MITRE ATLAS or ATT&CK, and NIST SP 800-53 Rev. 5 audit controls.
| Blind spot | OWASP LLM 2025 | ATLAS / ATT&CK | NIST SP 800-53 |
|---|---|---|---|
| 1. Tool-call arguments | LLM06 Excessive Agency | AML.T0086 Exfiltration via AI Agent Tool Invocation | AU-3, AU-12 |
| 2. Delegated identity | LLM06 | T1078.004 Valid Accounts: Cloud Accounts | AU-3, AU-10 |
| 3. MCP hops | LLM06 | AML.T0053 AI Agent Tool Invocation | AU-6, AU-10 |
| 4. Memory writes | LLM04 Data and Model Poisoning | AML.T0080.000 Memory | AU-2, AU-12 |
| 5. Tool definitions | LLM03 Supply Chain | AML.T0110 AI Agent Tool Poisoning | AU-2 |
| 6. Content provenance | LLM01 Prompt Injection | T1698 Indirect Prompt Injection, AML.T0051 | AU-3 |
| 7. Approvals | LLM06 | AML.T0053 | AU-10 |
| 8. Scope elevation | LLM06 | T1078.004 | AU-2, AU-6 |
| 9. Sub-agent calls | LLM06 | AML.T0053 | AU-6 |
| 10. Local MCP servers | LLM03 | AML.T0081 Modify AI Agent Configuration | AU-12 |
In NIST CSF 2.0 terms these gaps sit under PR.PS-04 (log records generated and available for continuous monitoring), DE.CM-09 (runtime environments monitored) and DE.AE-03 (information correlated from multiple sources).
Where to start
- Pick your three highest-impact agents and replay one past action end to end. Every question you cannot answer from logs is a blind spot from this list.
- Close blind spots 1 and 2 first: arguments and the acting human are what every investigation asks for.
- Add a correlation ID that survives MCP hops and sub-agent calls (blind spots 3 and 9), so the other records can be joined.
- Then add the change logs that explain delayed effects: memory writes, tool definitions and scope elevation (4, 5 and 8).
Track four numbers monthly: share of agent actions with arguments retrievable (target 100% for high-impact tools), share with both subject and actor recorded, share of tool calls joinable to a parent trace, and median time to reconstruct an agent action during exercises. For incident handling once the data exists, see the AI Agent Observability and Incident Response Guide.
Standards and references
- Model Context Protocol: Security Best Practices
- Model Context Protocol: Tools specification
- OpenTelemetry: Semantic conventions for generative AI spans
- IETF: RFC 8693 OAuth 2.0 Token Exchange
- OWASP: Top 10 for LLM Applications 2025
- MITRE ATLAS: AI Agent Context Poisoning
- MITRE ATT&CK: T1698 Indirect Prompt Injection
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Agent Controls and Monitoring Guide · Agent Observability vs Audit Logging · AI Agent Audit Log Schema Template · MCP Security Guide