AI Agent Security Monitoring with Structured Events

AI agent security monitoring should begin where the application makes an enforceable decision: before a tool reads protected data, changes state, executes code, or calls an external system. The useful telemetry is not a copy of the prompt or tool payload. It is a bounded record of what action class was requested, which policy version evaluated it, whether it was allowed, denied, or routed to approval, and what terminal outcome followed.

Telemetry is an analysis surface for those structured decisions. It does not enforce authorization, sandbox tools, isolate tenants, manage secrets, or replace the system that preserves security evidence. Keep enforcement in the application and policy layer, then send only the approved dimensions needed to review behavior over time.

Start with a tool and risk inventory

Inventory each tool the agent can discover or invoke. Classify it by the effect it can have rather than by a friendly display name:

Action class	Example	Typical review question
`read_only`	search an approved public index	Can the result expose restricted data or cross a tenant boundary?
`local_state_change`	write a generated file in an isolated workspace	Is the destination scoped and recoverable?
`external_state_change`	update a ticket, database row, or cloud resource	Does the actor have authority for the exact target and operation?
`code_execution`	run a command or job	What isolation, allowlist, time limit, and resource limit apply?
`credential_use`	call a service with delegated credentials	Is the credential scoped to the user, resource, and requested action?

Risk classification is a product and security decision. Do not copy this example into production as policy. Define controlled values with the people who own authorization, incident response, privacy, and the affected systems.

The OWASP Top 10 for Large Language Model Applications treats risks such as prompt injection, insecure output handling, excessive agency, and sensitive-information disclosure as distinct problems. Monitoring an authorization decision can help investigate those boundaries, but a dashboard is not a mitigation by itself. The OWASP prompt-injection guidance also explains why untrusted content can influence model behavior even when the application did not intend it to act as an instruction.

Record the policy decision before execution

Use one agent_tool_authorization_decided event for each final policy decision. Its grain is one logical tool-call attempt, not one model response and not one full agent run. Suggested fields include:

event_id, timestamp_utc, run_id, and tool_call_id for identity and correlation;
workflow, tool_name, and action_class as bounded operational dimensions;
risk_level, decision, reason_code, and policy_version as controlled policy fields;
release, environment, and a privacy-safe account_id for change analysis.

The agent tool authorization event schema documents the complete starter contract. Keep decision limited to values such as allowed, denied, and approval_required. A reason such as scope_denied or human_approval_required is safer and more comparable than a free-form model explanation.

Do not include raw prompts, completions, tool arguments, tool results, retrieved documents, authorization headers, cookies, tokens, connection strings, or customer content. A tool name should be a stable identifier such as database_write, not a serialized function call.

Keep decision and execution outcomes separate

Authorization answers whether the action may proceed. It does not prove that execution succeeded or that the business outcome was safe. Emit a separate terminal event such as agent_tool_completed with the same run_id and tool_call_id.

Event	Grain	Useful outcome
`agent_tool_authorization_decided`	one final policy decision	allowed, denied, or approval required
`agent_approval_resolved`	one completed human review	approved, rejected, expired, or cancelled
`agent_tool_completed`	one terminal execution attempt	success, failed, timed out, or cancelled
`agent_run_completed`	one terminal agent run	task success, failure, or human handoff
`agent_policy_changed`	one published policy change	previous version, new version, owner, and rollout

Keeping these grains separate makes important cases visible: an allowed call can fail, an approval can expire without execution, and a technically successful tool call can still lead to a rejected agent outcome.

Apply authorization at the resource server

For Model Context Protocol deployments, follow the protocol's authorization and security guidance at the implementation boundary. The MCP authorization specification describes authorization responsibilities, while the MCP security best-practices guide covers threats and mitigations for deployed systems. The MCP tools specification treats tool annotations as hints rather than a trusted security boundary.

In practice:

Make the policy decision in code that owns the protected resource.
Validate the actor, tenant, target resource, operation, and delegated scope there.
Require human approval for the action classes your policy marks as consequential.
Emit the bounded decision only after evaluation is final.
Execute the tool only when the enforcement layer allows it.
Emit a separate terminal outcome after execution.

Never rely on the model to self-report that an action is authorized. Likewise, do not treat a tool description or annotation as proof that an operation is read-only or safe.

Review denials, approvals, and policy changes with SQL

The AI agent tool authorization SQL recipe groups decisions by tool and risk class. It keeps absolute counts beside denial rate so a tiny sample does not create false urgency.

A useful dashboard includes:

total decisions by tool, workflow, risk level, and release;
allowed, denied, and approval-required counts;
denial rate with a visible decision denominator;
approval queue age and resolution outcome;
allowed actions that later failed;
decision mix before and after a policy-version change.

Interpret these signals with care. An expected denial can show policy working. A fall in denial rate can reflect a safer agent release, a weaker policy, or a shift in traffic. A growing approval queue can be an ownership problem rather than an attack.

Build an investigation timeline

Correlate decision, approval, tool outcome, and run outcome with run_id and tool_call_id. For a reviewed incident window, reconstruct:

which workflow and release requested the action;
which policy version evaluated it;
the bounded decision and reason code;
whether a human approved or rejected it;
whether execution started and how it ended;
whether the agent run completed, failed, or handed off.

Keep detailed evidence in the system designed for its integrity, access, retention, and deletion requirements. General analytics can identify patterns and provide a reproducible timeline, but it should not be presented as a compliance archive without verified controls.

Validate failure paths before alerting

Exercise synthetic cases for allowed, denied, approval-required, approval-expired, execution-failed, and policy-version-change paths. Confirm that:

every consequential tool call receives exactly one final decision;
denied calls do not execute;
approval-required calls cannot bypass review;
correlation identifiers join only the intended grains;
prohibited content never reaches the event payload;
missing telemetry does not weaken enforcement;
alerts use reviewed thresholds, sufficient volume, and an explicit owner.

Start with the AI agent security use case for an implementation prompt or copy the AI agent security audit template. For cost, latency, retries, and tool reliability, use AI agent monitoring. For authentication and administrative actions outside the agent boundary, use the broader security audit analytics guide.

Use this doc with your coding agent