TL;DR: AI agents now execute multi-step workflows across production systems, and the article argues that governable design depends on least agency and strong observability, according to WorkOS and the OWASP Top 10 for Agentic Applications. The practical lesson is that autonomy must be constrained before it is expanded, or review and audit become too weak to control real runtime behaviour.
At a glance
What this is: The article argues that governable AI agents require least agency plus strong observability, not least privilege alone.
Why it matters: That matters because IAM, PAM, and NHI programmes must control what agents can do, how they decide, and how every action is attributed across human, machine, and autonomous identity flows.
By the numbers:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
👉 Read WorkOS' blog post on governable AI agents and runtime observability
Context
AI agent governance starts with a simple definition: an agent is a software identity that can choose actions, tools, and timing at runtime rather than following a fixed script. In that model, least privilege alone is not enough, because the core issue is not just access but discretionary behaviour across a live workflow.
The article frames governability as a design problem, not a monitoring afterthought. For identity teams, that means the control plane must describe who authorised the action, what scope was granted, and what the agent was allowed to decide without checking back, which is the boundary where NHI governance begins to look more like runtime policy than static entitlement management.
Key questions
Q: How should security teams govern AI agents that can chain actions across tools?
A: Treat the agent as a runtime identity with bounded agency, not as a user session with extra automation. Define which tools it can call, what actions require approval, and which steps must be reversible. Then make every tool invocation trace back to the authorising identity, the workflow step, and the exact scope granted.
Q: Why do AI agents create different identity risk than traditional automation?
A: Traditional automation follows predetermined rules, while an AI agent can choose actions, sequence them, and adapt mid-session. That changes the control problem from workflow correctness to runtime discretion. Identity teams must govern not only access, but also the agent's freedom to decide how to use that access.
Q: What do teams get wrong about least privilege for AI agents?
A: They often stop at permission scope and ignore behavioural scope. An agent can have narrow access and still be risky if it can independently select targets, chain tool calls, and trigger irreversible actions. Least privilege is necessary, but it does not describe the agent's freedom to act.
Q: What should identity teams review when an AI agent is allowed to delegate?
A: Review the full delegation chain, not only the first identity that was authorised. Each hop should inherit a smaller permission set, a clear purpose, and a traceable authority link. If that attenuation is missing, delegated access can expand faster than the original approval ever intended.
Technical breakdown
Least agency vs least privilege in agentic systems
Least privilege limits what an identity can reach. Least agency limits how much freedom the agent has to decide, sequence, and execute actions once access exists. That distinction matters because an agent can have narrow permissions and still create high risk if it can chain decisions, choose targets, and trigger irreversible actions without review. In practice, agency is shaped by tool breadth, planning depth, delegation rights, and action reversibility. A single broad tool can become a de facto control failure even when the role looks small on paper.
Practical implication: scope the agent's decision space, not just its permissions.
Strong observability for AI agents is identity-layer tracing
Strong observability is not just log retention. For agentic systems, it means reconstructing what the agent did, why it did it, and on whose authority it acted. That requires linking decision steps, tool calls, user sessions, scoped credentials, and any delegation chain into one queryable record. Without those joins, a security team sees events but cannot prove authorization boundaries or detect scope drift. The article's architecture treats observability as a live control, not an audit archive.
Practical implication: require every action to resolve back to a specific authorisation chain.
Permission attenuation and tool-level boundaries
Permission attenuation is the principle that delegated authority should shrink as it moves down the chain. If a user authorises Agent A, and Agent A delegates to Agent B, B should inherit a subset of A's authority, not a fresh trust relationship. The same logic applies to tool design: narrow functions are safer than arbitrary APIs because they remove unexpected parameter space. OAuth 2.1, sender-constrained tokens, and resource-scoped authorization are the infrastructure patterns that make attenuation enforceable instead of aspirational.
Practical implication: enforce scoped delegation at the authorization layer, not in prompt text.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Least agency is the missing control concept for agentic AI governance. Least privilege answers what an identity can access, but not how much runtime discretion it has once access is granted. That leaves a structural gap in programmes that still assume policy boundaries are enough. In agentic environments, the control problem is decision freedom, not just entitlement breadth, and practitioners should treat agency as a first-class governance dimension.
Strong observability becomes a governance requirement when AI agents can chain actions autonomously. The article is right to separate logging from observability, because audit trails that cannot connect decision, action, and authority are not enough to prove control. This is especially important for NHI programmes that already struggle to attribute machine actions cleanly. The practical implication is that identity teams need traceability that survives delegation, not just retention of raw events.
Identity blast radius: When an agent can plan, delegate, and act across multiple tools, the real risk is no longer one credential or one API call. It is the accumulated scope of everything the identity can touch before a human ever reviews the result. That is a different governance problem from classic secret exposure, and it pushes teams to measure how far an agent can move, not only whether it was authenticated correctly.
Access review cadences are designed for stable identities, not fast-moving agent sessions. The assumption behind periodic certification is that privileged state persists long enough to be observed and attested. That assumption weakens when an agent can acquire, use, and finish work inside a single workflow window. The implication is not simply more review. It is that review-based governance may arrive after the relevant access state has already disappeared.
The market is converging on runtime control for AI agents because static IAM models do not express agent behaviour well enough. The article reflects a broader category shift: security teams are moving from coarse permissions to granular action boundaries, traceable authorization, and delegated identity control. That signals that agent governance will sit at the intersection of NHI, PAM, and AI risk management rather than in a standalone tool silo.
From our research:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
- For a governance lens that extends beyond a single control point, see NHI Lifecycle Management Guide for lifecycle controls that help constrain agent identity over time.
What this signals
The governance signal for practitioners is clear: agent programmes now need runtime controls that sit alongside IAM, not inside traditional user-centric review cycles. With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, the control gap is already architectural, not theoretical.
Identity blast radius: the practical test is no longer whether the agent authenticated successfully, but how far it could move before a human could understand the session. That means teams should measure action scope, delegation depth, and traceability together, because isolated controls hide the actual exposure pattern.
The next maturity step is to connect agent authorisation with reviewable evidence. If the programme cannot answer who approved the action, what the agent was allowed to decide, and which tool invocation followed, the environment is observable in name only. For deeper framework context, the OWASP Agentic AI Top 10 is the right external reference point.
For practitioners
- Define agency boundaries before expanding autonomy Document which tools, data sets, and irreversible actions the agent may use, then remove any capability that is not required for the current task scope.
- Instrument identity-layer observability for every action Require each tool call to carry the agent ID, user ID, workflow ID, plan step, authorization decision, and delegation context so you can reconstruct authority later.
- Replace broad tools with narrow functions Break arbitrary APIs into specific actions such as lookup, retrieve, or update so the agent cannot improvise new request shapes outside the approved boundary.
- Bind credentials to the task and the client Issue time-bound, client-bound credentials for agent workflows and revoke them when the task ends so replay and lateral reuse are harder.
- Enforce attenuation across delegated agents Make sure any sub-agent receives a smaller permission set than the authorising agent, and prevent delegation paths from creating fresh trust by default.
Key takeaways
- AI agent governance fails when teams equate least privilege with least agency, because access scope does not describe runtime decision freedom.
- Observability only works when it links decision, action, and authority, otherwise the security team can see events but cannot prove control.
- Practitioners should constrain tools, attenuate delegation, and bind credentials to tasks before expanding agent autonomy in production.
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 address the attack and risk surface, while NIST AI RMF 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 | ASI01 | Goal hijacking and tool misuse align with agent decision and scope control. |
| NIST AI RMF | GV.1 | Governance is needed for autonomous agent authority and accountability. |
| NIST Zero Trust (SP 800-207) | AC-4 | Policy enforcement and scoped access support least agency in runtime workflows. |
Apply resource-specific access controls and verify each agent action before execution.
Key terms
- Least Agency: Least agency is the principle of limiting how much runtime freedom an agent has to choose, chain, and execute actions. It goes beyond least privilege by focusing on behavioural discretion, not only permission scope. For autonomous systems, it is the control that keeps decision-making inside a reviewable boundary.
- Strong Observability: Strong observability is the ability to reconstruct what an agent did, why it did it, and on whose authority it acted. In practice, that means correlating decision steps, tool calls, identity context, and delegation history into one traceable record. Logs alone are not enough because they rarely prove authority.
- Permission Attenuation: Permission attenuation means delegated access must narrow as it moves down a chain of identities. Each sub-agent or downstream actor should receive only the authority needed for its own step, not a duplicate of the upstream grant. This prevents delegated trust from expanding beyond the original approval.
- Identity Blast Radius: Identity blast radius is the total amount of data, tools, and actions an identity can reach before control intervenes. For AI agents, it includes planning depth, delegation rights, and irreversible actions, not just the raw permissions attached to a token. Smaller blast radius means easier audit and containment.
Deepen your knowledge
AI agent governance, least agency, and strong observability are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic workflows with similar runtime risk, it is worth exploring.
This post draws on content published by WorkOS: The architecture of governable AI agents. Read the original.
Published by the NHIMG editorial team on 2026-03-31.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org