Seeing that an agent acted is not the same as proving it was allowed. Security observability for AI agents starts before the tool call executes — not after.
A security engineer gets a production alert on Friday afternoon. An AI agent has opened a pull request, updated a deployment ticket, and triggered a build during a change freeze. The first logs look normal. The agent used a valid token. The Git action was completed. The deployment system accepted the request. The APM trace shows latency, tool selection, and a successful response. But the real security question is still unanswered: Was that tool call allowed under the active policy?
That is the gap this article addresses. AI agent security observability is not just about seeing that an agent acted. It is about proving whether the action was authorized before it happened, which policy allowed it, which credential was used, and which human or workflow caused it.
What External Observability Misses
APM, Tracing, and LLM Observability Tools Capture Operations, Not Security
AI adoption is already moving fast. Stanford's 2025 AI Index reports that 78% of organizations used AI in 2024, up from 55% in 2023. GenAI use in at least one business function more than doubled, from 33% to 71%. Reported AI incidents have grown alongside it: the AI Incidents Database recorded 233 incidents in 2024, up 56.4% from 2023. As agents move from chat to action, this becomes a security problem, not only an observability problem.
Most observability tools are built to answer operational questions. Did the agent run? Did the tool respond? How long did the request take? Did the workflow fail? These are important questions. But they are not enough for security. Security teams need different answers. They need to know whether the tool call should have been allowed. Also, they need to know which policy was active and which rule matched. They need to know which credential was used and whether it was limited to that action. This is where traditional monitoring breaks down.
OpenTelemetry's MCP semantic conventions, currently in development, support tracing of MCP operations and tool execution spans. They help teams describe MCP activity in a standard way. But this telemetry is still mainly operational. The conventions define attributes for tool name, call ID, agent ID, session ID, and duration. They do not define attributes for policy decision, matched rule, policy version, credential scope, or allow/deny reason. The result: even a fully OTel-instrumented MCP deployment cannot, on its own, produce a security authorization record.
A trace can show that an agent called a tool. It usually cannot prove why that call was permitted. That difference matters during an incident. A valid token does not mean the action was safe. A successful API call does not mean the action matches business policy. A completed deployment does not mean the agent should have been able to trigger it. External observability sees the action after it has moved through the system. The authorization context existed earlier. It existed before the tool call was executed.
Operational monitoring answers whether an agent ran. Security observability answers whether it should have been allowed to.
MCP Server Logs Are Fragmented by Design
MCP gives AI agents a standard way to connect to tools and data sources. This is valuable because it simplifies agent-tool integration. It also creates a new security challenge. The MCP authorization specification provides transport-level authorization for HTTP-based transports. It allows MCP clients to make requests to restricted MCP servers on behalf of resource owners. That is useful, but transport authorization is not the same as per-tool-call policy enforcement. A server can show that a request arrived. It can show which method was called and whether the request succeeded. But it may not know the full scope of the agent task, the user intent, or the policy version. It may also not know whether this exact call is because of a change freeze, a sensitive repository, or a restricted environment.
The problem becomes clearer in multi-step workflows. One agent reads a ticket. Another agent writes code. A third tool opens a pull request. And a deployment tool starts a build. Each system logs only its own piece. The security team then has to reconstruct the story manually. That is slow and also incomplete. The team may prove that a tool was called. They may not be able to prove that the call was evaluated against the correct policy before execution.
Agent Frameworks Do Not Persist Security-Relevant State
Many agent frameworks can show conversation history, tool selection, and debug traces. This helps developers understand agent behavior. But debug output is not an audit trail. A useful audit trail must survive beyond one session. It must connect the agent, user, task, tool, policy, credential, and final decision. It must also be reliable enough for a security review.
This is important when several agents use the same service account or a broad OAuth grant. In that case, the provider log may show only the shared account. It may not show which agent made the decision or which user triggered the action. This is not a small logging issue. It is an identity and authorization issue. The security record must be created at the point of decision.
What Only the Enforcement Layer Captures
The enforcement layer is the point where the system still has full context. It sees the agent's identity and the requested tool. It also sees the arguments, the task context, the policy, the credential decision, and the final allow-or-deny result. After the call is forwarded, much of that context disappears. The downstream API sees a valid request. The tool server sees a valid call. The SIEM may receive both events. But none of them can recreate the exact authorization decision if it was never recorded.
A mature policy system shows why this matters. Open Policy Agent decision logs contain events that describe policy queries. These events include the queried policy, the input, bundle metadata, and other details used for auditing and offline debugging. The same idea applies to AI agents. A normal log says: the action happened. A policy decision record says: this action was evaluated, this policy was active, this rule matched, this decision was made, and this credential was used. That is the difference between activity logging and AI agent security observability.
The enforcement layer is the only point where agent identity, tool arguments, policy version, and credential decision all exist together. Once the call is forwarded, that context is gone.
What a Complete Per-Tool-Call Security Record Requires
What Goes into the Record
A complete security record should be created for every tool call before execution. It should identify the agent and agent version. This matters because several versions may run simultaneously. Also, identify the principal. This may be a human user, a workflow, or another agent. Without this field, non-repudiation becomes weak.
Next, it should preserve the delegation chain. If one agent calls another agent, and that agent calls a tool, the record must show that lineage. Also include the task or session ID. A tool call must be tied back to the business task that caused it. It should show the tool name and tool server. This helps detect tool substitution, tool misuse, or unexpected tool routing.
But also, it is supposed to include the policy version and the matched rule. This is one of the most important parts of the record. Security teams need to know which policy was active at the time of the decision. It should record the decision and the reason code. Allow events matter. Deny events matter too. Denied calls may reveal prompt injection, misuse, or broken workflow design.
And it should include the credential ID, scope, and time-to-live. This proves that access was limited to the action instead of relying on a standing broad token. It requires preserved arguments with sensitive data redacted. Arguments often carry the real risk. Reading a file and deleting a production branch may both appear as tool calls, but their impacts are not the same.
A complete per-tool-call security record captures eight categories of context — from agent identity to credential scope — that no downstream monitoring tool can reconstruct after execution.
Where Standardization Is Heading
An individual 2026 IETF Internet-Draft on Agent Audit Trail describes a JSON-based audit format for autonomous AI systems. It defines fields for agent identity, action classification, outcome tracking, and trust level. It also specifies hash chaining via canonical JSON (RFC 8785) and optional ECDSA P-256 signatures for non-repudiation. The draft has not been adopted by an IETF working group and has no formal standing in the IETF standards process, but it is the first concrete public attempt to standardize per-action audit records for AI agents.
Regulation and Compliance
For organizations subject to the EU AI Act, this is no longer optional. Article 12 of Regulation (EU) 2024/1689 requires high-risk AI systems to maintain automatic, traceable event logs over the system lifetime. Article 19 requires providers to retain those logs for at least six months. These obligations apply as of August 2, 2026, to high-risk AI systems defined in Annex III. Many enterprise AI agents will fall under this category, particularly those used in employment decisions, critical infrastructure operations, access to essential services, or law enforcement contexts. The per-tool-call record fields described above directly support that obligation.
Beyond the EU AI Act, the same record requirements map cleanly onto several widely used frameworks. PCI DSS v4.0.1 requirement 10 mandates audit trails of all access to system components, including event details, integrity protection, and twelve months of retention. SOC 2 Common Criteria CC7.2 and CC7.3 require monitoring telemetry sufficient to identify and respond to security events. NIST AI RMF 1.0 and its Generative AI Profile (NIST AI 600-1) require traceability of AI system decisions. ISO/IEC 42001:2023, clause 9.1, requires the maintenance of monitoring, measurement, and evaluation records throughout the AI management system lifecycle. A per-tool-call audit record satisfies the technical core of all four.
In Practice
For security teams, the practical lesson is simple. A tool call without a decision record is hard to defend later. Credential risk is already a major security problem. Verizon's 2025 Data Breach Investigations Report found that credential abuse was an initial access vector in 22% of breaches reviewed in the report. AI agents can make this problem worse if access is not controlled at runtime. An agent may hold a broad token. Several agents may share one service account. A workflow may continue after the original user interaction ends. A tool call may happen hours after the first instruction.
In these cases, the question is not only "was the token valid?" The better question is: Was this credential created for this agent, task, tool, and policy decision? If the answer is no, the audit trail is weak.
How AgntID Generates the Record That External Tools Cannot
AgntID uses a customer-hosted runtime with an embedded MCP proxy. The proxy intercepts MCP tool calls, applies policy, derives scoped credentials, and enforces access at execution time. AgntID is present when the agent, task, tool, policy, arguments, and credential decision all come together. That allows it to create a security record that external monitoring tools cannot generate later. Its product features include per-tool execution reporting, a complete tool-call timeline, a step-by-step policy-decision trace, visibility into credential derivation, and deterministic execution records.
AgntID also generates records outside of production. Its policy simulation runs scenarios through the same enforcement engine that handles live traffic, producing the same deterministic record format for each tool call. Teams can review and refine a policy against the audit pipeline before any agent goes live. These controls map directly to risks identified in recent OWASP guidance for agentic systems.
AgntID does not replace the Security Information and Event Management (SIEM) platform. It gives the SIEM stronger evidence. The SIEM can still correlate, alert on, and retain events. But AgntID produces enforcement-layer telemetry indicating whether the action was allowed and, if not, why. Monitoring tools show activity. AgntID shows authorization.
Agent tool calls may contain sensitive data. They may include repository names, infrastructure details, database queries, customer records, or internal business logic. Many enterprises do not want that data to leave their environment before enforcement. AgntID's product model separates the cloud control plane from customer-hosted execution. Policy configuration can be managed centrally, while tool execution, policy evaluation, scoped credential handling, and auditing occur within the customer environment.
They do not need to replace every MCP server or rebuild IAM. But also, they do not need to abandon existing monitoring tools.
AgntID produces enforcement-layer telemetry — policy decision, credential scope, allow/deny reason — that feeds directly into existing SIEM infrastructure. Monitoring tools show activity. AgntID shows authorization.
FAQ
Can't I just connect Datadog or Splunk to my MCP servers and get the same visibility?
No. Datadog or Splunk can collect MCP logs and show that a tool was called, but they cannot recreate the policy decision, matched rule, credential scope, or allow/deny reason that existed before execution.
What is the difference between a log and a policy decision record?
A log shows what happened. A policy decision record shows why the action was allowed or denied, under which policy, by which rule, and with which credential.
Does this require replacing our existing SIEM or log infrastructure?
No. AgntID creates enforcement-layer security telemetry that can be sent into your existing SIEM, log platform, or monitoring stack.
How does AgntID handle multi-agent delegation chains where one agent calls another?
AgntID records the delegation chain at runtime. This means the final tool call can be traced back to the original agent, the intermediate agents, the triggering task, the policy decision, and the scoped credential.