Notifications
Clear all
Topic starter
19/08/2026 4:45 pm
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.
NHIMG editorial — based on content published by ARMO: Runtime-Derived Least Privilege for AI Agents: From Observed Behavior to Enforcement
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Freeze baseline updates during active incidents Allow convergence and model refresh only after the incident is contained and reviewed.
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.
👉 Read ARMO's runtime-derived least privilege analysis for AI agents →
Runtime-derived least privilege for AI agents: are your controls aligned?
Explore further
19/08/2026 4:45 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime-derived least privilege for AI agents needs one envelope
