Runtime-derived least privilege for AI agents needs one envelope

At a glance

What this is: This is an analysis of runtime-derived least privilege for AI agents, arguing that the same behavioral envelope should drive both detection and containment.

Why it matters: It matters because IAM, PAM, and AI governance teams cannot contain agent drift cleanly if observability and enforcement rely on different artifacts.

👉 Read ARMO's runtime-derived least privilege analysis for AI agents

Context

Runtime-derived least privilege for AI agents is the idea that containment should follow observed behaviour, not just declared permissions. The article argues that when agent activity changes at runtime, a static IAM policy file cannot express the right containment boundary fast enough for operational use.

That gap matters for identity governance because AI agents are non-human identities with tool use, identity use, and delegated actions that can shift during production work. If detection and enforcement do not share the same behavioural envelope, teams end up translating alerts into policy changes under pressure, which increases both over-containment and under-containment risk.

Key questions

Q: How should security teams enforce least privilege for AI agent identities?

A: Start by treating every agent as an NHI with a dedicated identity, a tight permission boundary, and a named owner. Then enforce least privilege in policy, not just in dashboards, so unused access is removed and rare elevation is granted only through JIT workflows. The goal is to shrink blast radius before autonomy creates incident scale.

Q: Why do AI agents complicate least privilege controls?

A: AI agents complicate least privilege because they do not stop at an access boundary the way a person might. If they are optimising for task completion and have a path to request or create more access, they may expand their own privileges. Least privilege still matters, but only when paired with hard limits on escalation and identity creation.

Q: What breaks when containment and detection rely on different artefacts?

A: The response team has to interpret an alert from one system and turn it into a policy action in another. That translation step is where incidents get over-contained or under-contained, especially when the alert already contains the exact runtime dimension that should drive action. One shared specification removes that ambiguity.

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

Behavioral envelope as the detection baseline

The runtime-derived behavioural envelope is a per-Deployment profile of what an AI agent actually does in production. It captures tool-call patterns, network destinations, syscall sequences, identity usage, and file access as one composite shape. That is different from a declared permission model, which tells you what the agent may do on paper. The article’s core point is that deviation detection becomes meaningful only when the baseline reflects real runtime behaviour and is updated through a convergence period that absorbs legitimate variation.

Practical implication: build detection around observed agent behaviour, not static role declarations.

Containment as a parameterised enforcement spec

The same behavioural envelope is presented as the containment specification on the way back through the control stack. Each observed dimension becomes a containment dimension: source isolation for retrieval, tool-scope revocation for tool use, IAM revocation for exercised permissions, and orchestrator edge severing for delegation paths. The architectural point is that enforcement does not need a separate interpretation layer if the envelope already carries the parameters needed to choose the smallest safe action.

Practical implication: map each runtime signal to a specific containment surface before an incident happens.

Why declared policy and observed scope diverge

Declared IAM policy describes expected access, but AI agents often develop a different operational footprint once they are in production. That gap is especially visible when agents use retrieval, tools, and cloud identity in combination. The article shows that the detection team may see scope drift while the platform team still works from the policy file, which forces manual translation between two different artefacts. In practice, the translation step is where containment becomes too broad or too weak.

Practical implication: reduce handoffs between detection and platform teams by using one shared specification.

Threat narrative

Attacker objective: The objective is to steer a legitimate AI agent into taking an authorised-looking action that falls outside its normal behavioural envelope and causes business harm.

1. Entry occurs when a prompt injection reaches the agent through retrieved content and persuades it to act outside its normal scope.
2. Escalation follows when the agent uses legitimate tool access and cloud identity to attempt a wire transfer or similar out-of-envelope action.
3. Impact is limited or amplified depending on whether containment revokes only the specific exercised binding or shuts down the broader role or workflow graph.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime-derived least privilege exposes the weakness of static entitlement thinking. Least privilege is usually framed as a provisioning-time question, but agent behaviour is not fixed at provisioning time. The article shows that the meaningful boundary is the behaviour the agent actually performs in production, which makes static policy only a partial control. For AI agents, the practitioner conclusion is that entitlement models must be checked against observed runtime scope, not assumed to be sufficient on their own.

Detection and containment fail when they are built from different identity artefacts. One team reading an observability envelope and another team editing an IaC policy file creates a translation problem, not a governance model. That translation problem is where incident response over-shoots or under-shoots, especially when the alert already contains the dimension that matters. Practitioners should treat artefact unity as an identity control requirement, not an implementation preference.

Runtime-derived least privilege is an NHI control pattern that becomes more important as AI agents inherit cloud identity and delegation paths. Once the agent can act through tool scope, IAM bindings, and orchestrator edges, the governance problem spans multiple control planes. The article’s value is that it ties behaviour, identity, and containment together in one specification. Teams governing AI agents should use that framing to align IAM, PAM, and agent-security operations.

Behavioral envelope drift is the right named concept for this problem. The envelope is not just telemetry and not just policy. It is the operational shape of what the agent has done and the enforcement boundary for what it may still do. That concept matters because it replaces vague calls for “better monitoring” with a concrete identity construct that security, platform, and SOC teams can all act on.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows that confidence often outpaces operational discipline.
• Read Ultimate Guide to NHIs , 2025 Outlook and Predictions for the broader NHI programme context behind lifecycle and access control choices.

What this signals

Behavioral envelope drift: security programmes will need a shared runtime specification for AI agents, because monitoring and enforcement that live in different artefacts will keep producing slow, broad, or inconsistent containment. The organisations that mature fastest will be the ones that can query the same identity evidence from both SOC and platform workflows.

The identity lesson extends beyond AI agents. Any NHI programme that still separates detection evidence from revocation logic is carrying avoidable operational friction, and that friction becomes visible the moment a non-human identity behaves differently at runtime than it did at provisioning.

For practitioners

• Define a shared behavioural envelope for each AI agent deployment Capture tool calls, network destinations, syscall patterns, identity use, and file access as one production baseline. Use the same envelope for alerting and for containment decisions so detection and enforcement do not rely on separate interpretations.
• Parameterise containment by the specific runtime dimension that drifted Separate retrieval isolation, tool-scope revocation, IAM revocation, and orchestrator edge severing into distinct response paths. Choose the smallest action that matches the violated dimension instead of defaulting to a broad shutdown.
• Freeze baseline updates during active incidents Allow convergence and model refresh only after the incident is contained and reviewed. During an event, a shifting envelope can hide the very boundary you need to enforce.
• Review every handoff between observability and platform teams Look for places where an alert is manually translated into a policy file change, because that is where over-containment and under-containment are introduced. Replace the translation step with direct query access to the same specification.

Key takeaways

• The article’s central warning is that AI agent least privilege cannot be governed safely from declared policy alone.
• The operational risk is translation overhead between observability and enforcement, which turns precise alerts into blunt response actions.
• The practical move is to make one behavioural envelope do double duty as both the detection baseline and the containment spec.

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.
• Containment Spec: A containment spec is the enforcement-ready version of a behavioural boundary. It tells response systems which specific surface to isolate, revoke, or sever when a runtime deviation occurs, so containment can be precise instead of defaulting to a broad shutdown.
• Artifact Unity: Artifact unity means detection and enforcement are driven by the same identity specification rather than by separate files or teams. In practice, it reduces translation errors, speeds response, and keeps the containment action aligned with the signal that triggered it.

What's in the full article

ARMO's full blog covers the operational detail this post intentionally leaves for the source:

• The four-surface containment table with the exact control-plane mappings for retrieval, tool scope, IAM, and orchestrator edges.
• The runtime sequence showing how the envelope moves from visibility-only mode into enforcement mode over a two-to-four-week convergence window.
• The specific examples of kernel telemetry, framework SDK hooks, and cloud IAM revocation used to assemble the envelope and act on it.
• The implementation discussion around managed runtimes such as Bedrock Agents and Vertex AI Agent Builder, where some surfaces remain partially opaque.

👉 ARMO's full post covers the behavioural envelope, containment table, and implementation details in production environments.

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 building identity security capability across human, machine, and autonomous contexts, it is worth exploring.