What should security teams audit in an agent stack with a model router?

What to audit on the router path

The audit trail should let you reconstruct one request end to end, not just prove that a request happened. For an agent stack with a model router, the most important record set is the caller identity, the tools exposed to that turn, the tools actually invoked, and the model selected for the request. That combination shows whether the failure sits in routing, authorisation, or context handling.

A useful audit record also needs stable correlation across the router, the agent runtime, and downstream tool calls. Without that, teams can see an action was taken but cannot tell whether the router chose the wrong model, the policy layer exposed the wrong capability, or the agent executed a permitted tool in the wrong context.

When you review logs, treat the exposed tool list as part of the security decision, not just telemetry. If the visible tool set does not match the allowed scope for that turn, the problem is often policy drift or context bleed, even if the final tool call itself looks legitimate.

How to separate routing failures from authorisation failures

Routing and authorisation can fail in different ways, and the audit records should make that distinction obvious. A routing failure usually shows the wrong model chosen for the task, the wrong policy branch taken, or an unexpected handoff between models. An authorisation failure shows a caller or agent reaching a tool or action that should have been denied, limited, or scoped more tightly.

Tool exposure matters because it is the boundary between intent and capability. If a turn advertises tools that the caller should not see, then the stack may be leaking capability before any invocation occurs. If the tool list is correct but the invoked tool set is not, the issue is usually in enforcement, delegation, or request binding rather than in discovery.

Model choice should be logged with enough context to explain why that model was selected. In practice, that means the routing reason, the policy inputs, and the request attributes that influenced the decision. Otherwise, teams cannot tell whether the router made a legitimate selection or silently shifted the request into a model with broader reach or weaker guardrails.

What evidence makes the audit trail actually useful

Audit records only help if they support reconstruction and review. The record set should make it possible to answer four questions: who asked, what capabilities were made available, what was actually used, and why that model path was chosen. If any of those is missing, incident response becomes guesswork rather than analysis.

For agent stacks, the best records are the ones that preserve the request boundary, not just the output. That means capturing the state at the point of decision, including the caller, the policy decision, the selected model, and the tool invocation sequence. If the agent can change context mid-turn, log the context transitions as well, because that is where prompt injection, mis-scoping, and cross-turn leakage often show up.

For AI agent observability and incident response, the practical goal is attribution with enough fidelity to support containment and rollback, not just dashboards. AI Agent Observability, Audit and Incident Response Guide is a useful companion when you need to turn these records into an investigation workflow. AI Agent Authorisation Guide is the better reference when the issue is deciding which tools and actions should have been available in the first place. Zero Trust for AI Agents helps anchor the expectation that every request should be checked against principal, request, and privilege rather than trusted by default.

Risk and Threat Considerations

Agent stacks fail in ways that are easy to miss in normal application logging. If routing, policy, and execution are not logged separately, a compromised caller can blend into an apparently valid model choice, or a mis-scoped tool can be exposed without leaving a clear enforcement failure. That makes later compromise harder to prove and harder to contain.

Failure mechanism: The stack collapses distinct control points into a single event stream, so an attacker, misconfiguration, or buggy router can change the model, broaden tool exposure, or invoke an unintended capability without a clear audit boundary.

Impact: Security teams lose the ability to prove what was authorised, what was merely exposed, and what was actually executed, which weakens incident response, forensics, and policy enforcement.

Practitioner Guidance

What to verify: Confirm that every request has a durable request ID linking caller identity, router decision, exposed tools, tool invocations, and model selection. If those elements cannot be joined reliably, the stack is not auditable enough for investigation or control review.

Decision rule: If the logs can show the final response but cannot show the decision path, treat that as a control gap, not a logging gap. The audit objective is to explain why the system behaved as it did, not merely to preserve an output transcript.

Practitioner takeaway: The best audit trail in an agent stack is one that separates decision, permission, and execution, because that is what lets you prove whether the failure was in routing, authorisation, or context handling.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?