TL;DR: Runtime-derived least privilege for AI agents works only when detection and enforcement consume the same behavioral specification, according to ARMO, because static declared policy cannot contain observed runtime deviation precisely enough for incident response. The decisive issue is artifact unity, not another layer of policy tuning.
At a glance
What this is: This article says runtime-derived least privilege for AI agents only works when detection and enforcement share one behavioral envelope, not separate policy and observability artifacts.
Why it matters: IAM, IGA, and AI security teams need the same runtime specification to avoid over-broad containment and policy drift when agents deviate from observed scope.
Context
Runtime-derived least privilege is the idea that an AI agent’s allowed scope should reflect what it actually does in production, not only what was declared at build time. The governance gap is that most teams still split detection and containment across different artifacts, which leaves enforcement blind to the behaviour the observability layer already saw.
For AI agents, that split becomes operationally expensive because runtime behaviour changes with prompts, tools, and delegation paths. If the detection system and the enforcement system do not consume the same behavioural specification, incident response defaults to broad shutdowns instead of scoped containment.
Key questions
Q: What breaks when AI agent detection and containment use different artifacts?
A: The response path breaks because analysts see deviation in one system but enforcement receives a different specification in another. That translation step creates delay, broad shutdowns, and revocations that are either too wide or too narrow. The practical failure is not just slower response, but loss of precision when the agent is already outside its observed envelope.
Q: Why do runtime envelopes matter more than declared policy for AI agents?
A: Declared policy captures intended scope, but runtime envelopes capture actual behaviour across tools, identities, and data sources. AI agents can shift behaviour during execution, so the real boundary appears only after observation. That makes runtime evidence the better basis for both detection and containment.
Q: How do you know whether runtime containment for AI agents is actually working?
A: It is working when a suspicious trace can be stopped before the agent reaches privileged tools or writes to a downstream system. Look for evidence that execution is bounded by task scope, that permissions shrink during untrusted context, and that operators can halt sessions before propagation occurs.
Q: What should teams do when an AI agent exceeds its observed behavioural envelope?
A: Contain the specific surface that drifted instead of shutting down every function the agent can reach. If the issue is retrieval, isolate the source. If it is tool misuse, revoke the tool scope. If it is identity misuse, revoke the exercised binding. If it is cross-agent coordination, sever the affected edge.
Technical breakdown
Why declared policy fails for AI agents
Declared policy describes what an agent is supposed to do, while runtime behaviour shows what it actually did across tools, identities, and data sources. In agentic systems, that difference matters because scope is not fixed at provisioning time. A static IaC policy file can say little about three weeks of observed tool use, network destinations, or delegation paths. The result is a control plane that can approve or revoke too much because it is reading intent, not observed behaviour.
Practical implication: treat runtime observation as the source of truth for AI agent scope, not only the provisioning file.
How a behavioural envelope becomes both detection and containment
A behavioural envelope is a per-deployment record of normal AI agent activity, including tool-call patterns, identity use, file access, and network destinations. Read forward, it powers deviation detection. Read backward, it becomes the containment specification that tells enforcement what to revoke, scope, or sever. That dual role matters because the same dimension that triggered the alert should also define the smallest safe response, whether that is tool-scope revocation, IAM revocation, or orchestrator edge severing.
Practical implication: use one runtime envelope for both alerting and enforcement so response actions stay narrow and explainable.
Why containment should be surface-specific
AI agent containment fails when teams respond with a single blunt action against every surface. Input filtering, tool revocation, IAM revocation, and orchestrator edge severing are different controls, and they should be driven by the specific behavioural dimension that drifted. If the envelope says the agent exceeded partner-account scope, revoking the entire role may disrupt unrelated functions that were not compromised. Surface-specific containment preserves the parts of the agent that remain inside observed bounds.
Practical implication: map each deviation type to the narrowest control plane that can contain it without taking the whole workflow down.
Threat narrative
Attacker objective: The objective is to push the agent into out-of-envelope action that causes unauthorized business execution, such as an inappropriate transfer or other sensitive workflow action.
- The agent receives a prompt through RAG retrieval that includes a malicious instruction hidden in normal content.
- The agent follows the instruction and makes a tool call outside its observed scope, creating a runtime deviation from its envelope.
- The enforcement layer revokes the specific role binding or tool scope tied to that deviation, while broader workflows remain exposed until containment completes.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Artifact unity is now the real control problem for AI agents: detection and containment cannot be treated as separate governance layers when the same runtime behaviour drives both alerting and response. If the observability stack and the policy layer do not consume the same specification, the organisation will either over-contain or under-contain at incident time. The practitioner conclusion is that agent governance must be designed around one behavioural source of truth.
Declared least privilege is an incomplete assumption for agentic systems: it was designed for systems whose scope is knowable at provisioning time. That assumption fails when an agent selects tools, timing, and delegation paths at runtime because the actual privilege boundary emerges only after observation. The implication is that least privilege for agents has to be derived from behaviour, not frozen as a build-time declaration.
Runtime-derived behavioural envelopes create a named control concept worth standardising: envelope-driven containment. The article’s core insight is that the same envelope can serve as the Layer 2 baseline and the Layer 5 containment spec, which collapses translation delay between detection and enforcement. That makes containment narrower, faster, and easier to explain to incident responders. Practitioner teams should treat the envelope as a control primitive, not an analytics afterthought.
Surface-specific containment is the only defensible response model when AI agents cross scope: tool revocation, IAM revocation, input filtering, and orchestrator isolation are not interchangeable. A broad shutdown may stop the incident, but it also breaks unaffected workflows and teaches teams to roll back containment too early. The field should move toward response actions that match the surface where the behaviour drifted.
AI agent governance now sits at the boundary of NHI, IAM, and runtime operations: the same problem spans identity scope, tool access, and behavioural telemetry. That makes cross-functional ownership unavoidable. Security architects should stop asking which team owns the tool and start asking which team owns the shared behavioural specification that both detection and enforcement will trust.
From our research library:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Envelope-driven containment: AI agent governance becomes materially easier when the same behavioural specification drives both detection and enforcement. That removes the translation gap that normally forces teams into broad shutdowns or slow manual triage, and it gives incident responders a boundary they can actually act on.
The operational shift is from declared permissions to observed runtime scope. When teams anchor containment to the same telemetry that defines normal behaviour, they can keep unaffected workflows alive while still stopping the out-of-envelope action that triggered the alert.
For practitioners
- Define one runtime behavioural envelope Build a single per-deployment specification that captures tool use, identity use, file access, and network destinations for each AI agent. Make both detection and enforcement query the same envelope instead of syncing separate files through tickets.
- Separate containment by surface Map each deviation dimension to the narrowest control plane that can act on it, such as tool-scope revocation, IAM revocation, context filtering, or orchestrator edge severing. Avoid whole-graph or whole-role shutdown unless the observed behaviour truly spans that scope.
- Freeze envelope updates during incidents Pause behavioural envelope learning while an active incident is being handled so the observed boundary does not drift under live containment. Resume learning only after post-incident review confirms which changes were legitimate and which were malicious.
- Diff policy against observed behaviour Compare the platform team’s enforcement policy with the envelope’s observed identity usage and tool sequence for one recently alerted agent. Any mismatch shows where the response path still depends on translation instead of direct consumption.
Key takeaways
- AI agent controls fail when observability and enforcement rely on different artifacts instead of one shared behavioural envelope.
- A runtime envelope lets teams detect deviation and contain it at the same surface, which narrows response and reduces unnecessary outage.
- Practitioners should align policy, telemetry, and containment around observed behaviour so least privilege remains usable at incident speed.
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 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on AI agents exceeding observed identity and privilege scope at runtime. |
| ASI02 — Tool Misuse | The core failure mode is tool invocation outside the agent's behavioural envelope. | |
| ASI08 — Cascading Failures | Broad shutdowns and mismatched artifacts can cascade across unaffected workflows. | |
| Recommendation — Align agent scope controls to ASI03 so runtime privilege use stays inside observed behaviour. Map out-of-envelope tool calls to ASI02 and constrain enforcement at the tool surface. Use ASI08 to contain drift without triggering unnecessary workflow-wide outages. | ||
| NIST AI RMF | MANAGE — AI Risk Management | The article is about operational AI governance and response alignment. |
| Recommendation — Manage agent scope and incident response as one governed AI risk process. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime-derived least privilege directly concerns entitlements and authorization boundaries. |
| Recommendation — Apply PR.AA-05 to keep AI agent authorizations aligned with observed runtime behaviour. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's containment logic responds to unauthorized access paths and movement across control surfaces. |
| Recommendation — Track agent deviations against TA0006 and TA0008 to prioritise containment points. | ||
Key terms
- Behavioural Envelope: A behavioural envelope is the observed range of normal activity for a specific workload or agent. It includes tools used, destinations reached, volume moved, and processes spawned, giving detection a reference point for spotting deviations that configuration-only checks would miss.
- Runtime-Derived Least Privilege: Least privilege computed from actual execution traces, such as network calls, system calls, or tool use. It is a stronger fit for non-human identities because the boundary is anchored to observed purpose and can adapt as the workload’s behavior becomes better understood.
- Surface-Specific Containment: Surface-specific containment is the practice of revoking or restricting only the control plane that corresponds to the deviation, such as tools, IAM, input context, or orchestration links. It reduces blast radius by matching the response to the exact runtime surface that drifted.
- Control-Plane Addressability: Control-plane addressability means a security artifact can be queried and acted on directly by both detection and enforcement systems. In AI agent governance, it is the difference between a useful operational specification and a static record that still requires human translation during incident response.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org