They are working when investigators can reconstruct each session, see tool use and action sequencing, and verify that unsafe behaviour was blocked before sensitive data was exposed. If teams can only say an agent was active, the controls are too shallow. Effective governance produces evidence of containment, not just activity logs.
What “working” looks like in an agentic runtime
Runtime controls are only meaningful if they change what the system can do, not just what it records after the fact. For agentic systems, that means the control plane has to shape each step the agent takes: which tools it may call, which identities or scopes it may use, and which requests are blocked or downgraded before an unsafe action reaches a sensitive boundary. The key question is whether the runtime is enforcing policy, not merely observing activity.
A practical test is whether reviewers can explain a session from start to finish without guesswork. If the logs show the agent’s inputs, the decision points, the tool call sequence, the policy outcome, and the reason a risky action was stopped, then the control is doing real governance work. If the record only says the agent was “active,” the control is too shallow to trust.
That distinction matters because agentic risk is often cumulative. A single allowed step may look harmless in isolation, but a chain of tool calls, context reuse, or delegated authority can create the real exposure. AI Agent Observability, Audit and Incident Response Guide is useful here because it focuses on attribution, session reconstruction, and kill-switch evidence rather than generic telemetry.
How teams verify containment instead of just activity
Verification starts by asking whether the runtime control can prove an unsafe path was interrupted. That proof usually comes from correlated evidence: the triggering condition, the policy decision, the blocked tool invocation, and the absence of downstream data exposure. In other words, teams need evidence that the control acted before the agent crossed an unacceptable threshold.
Good validation also checks whether the control behaves consistently across sessions, tools, and users. An agent that is constrained in one workflow but unconstrained in another is not governed, it is selectively fenced. Zero Trust for AI Agents is a useful reference because it treats verification, per-action policy, and no-standing-privilege as runtime properties, which is closer to how teams should evaluate control effectiveness.
For teams building the control itself, the most useful question is not “did we log it?” but “could we reconstruct the decision and prove the policy boundary held?” That is why Agentic AI Security Guide matters: it frames controls around inputs, tools, orchestration, and identity as a layered system rather than as isolated alerts.
When the answer depends on sensitive content, the control should also demonstrate prevention at the point of use. If secret-bearing prompts, restricted files, or high-risk outputs can reach the model or tool layer before policy intervenes, the runtime is only partially effective. Strong governance shows containment in the chain of execution, not just post-hoc reviewability.
Which evidence convinces an investigator that the controls are effective?
Investigators usually need three forms of evidence: a traceable session record, a visible policy decision trail, and a verifiable block or containment event. Those three together show that the system can explain what happened, why it happened, and where it stopped. Without all three, teams may be seeing monitoring coverage, not enforcement.
The most persuasive evidence is often negative evidence, meaning proof that something risky did not occur because the runtime stopped it. Examples include a denied tool call, a suppressed action sequence, a revoked delegated permission, or a blocked attempt to access data outside the agent’s scope. That evidence is stronger than a dashboard full of agent actions because it shows boundary enforcement.
For agent teams, AI Agent Authorisation Guide is a strong companion because it ties effectiveness to per-action decisions, task-scoped access, and approval gates. When those concepts are working, the runtime should be able to show exactly why a request was permitted or denied, and what standing privilege was removed.
Teams should also verify that the evidence survives incident review. If analysts cannot replay the session, identify the tool chain, or distinguish allowed from blocked actions, the control is not operationally mature enough for high-risk workloads. In practice, that means treating auditability as part of the control, not as an optional reporting layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent runtime controls must prevent unsafe privilege and action use. |
| Recommendation — Enforce per-action authorization and remove standing privilege from agent sessions. | ||
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | Session reconstruction depends on audit records that capture tool use and policy decisions. |
| AC-6 — Least Privilege | Working runtime controls should constrain agent authority to the minimum required. | |
| IA-5 — Authenticator Management | Agent runtime governance depends on controlling and rotating the credentials that enable actions. | |
| Recommendation — Record tool calls, decisions, and outcomes needed to reconstruct each agent session. Limit agent permissions to the minimum scope needed for the task. Manage agent credentials so access can be revoked, rotated, and bounded quickly. | ||
| NIST Zero Trust (SP 800-207) | 2 — Logical Component Architecture | Zero trust evaluation fits agent sessions that need continuous verification per action. |
| Recommendation — Apply per-request policy checks instead of trusting an agent session by default. | ||
Practitioner Guidance
What to verify: Test the runtime against a deliberate unsafe workflow and confirm that the control blocks it before sensitive data is exposed, while still leaving a trace that explains the policy decision. A control that only produces logs after the fact has not yet proven containment.
What good looks like: The evidence set should let a reviewer reconstruct the session, see the agent’s tool sequence, identify the decision point, and confirm whether the risky action was denied, constrained, or downgraded. That is the practical difference between observability and governance.
Common mistake: Do not treat “we can see the agent ran” as proof of success. Visibility alone does not show that the agent was bounded, that delegation was limited, or that unsafe behaviour was interrupted before impact.
Practitioner takeaway: Runtime controls are working only when they change the outcome of the session and leave enough evidence to prove it, especially when the blocked path would have reached sensitive data or excessive privilege.
Related resources from NHI Mgmt Group
- How do security and fraud teams know whether agentic commerce controls are working?
- How should security teams govern machine identity credentials in agentic AI environments?
- How do teams know if identity security controls are actually working?
- How do security teams know whether privacy controls are actually working?