AI agent governance needs task-scoped identity controls

At a glance

What this is: This blog argues that AI agents need dedicated identity governance because their speed, tool use, and delegated access break human-centric controls.

Why it matters: It matters because practitioners must govern agent access, data scope, and accountability without assuming that human review models, NHI practices, or traditional automation controls will hold.

By the numbers:

• 96% of technology professionals identified AI agents as a threat.
• 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.

👉 Read SailPoint's analysis of how to govern AI agents securely

Context

AI agent governance is the discipline of deciding who can use an agent, what it can touch, and how its actions are observed and bounded. The problem is that many enterprises are treating agents like faster software rather than as identities with their own access and accountability requirements. In an AI agent security context, that mistake creates a gap between delegation and control.

The source article frames agents as neither purely human nor purely machine, which is the right starting point for practitioners. They can operate on behalf of a user, call tools, or trigger downstream actions with machine accounts, so the identity model changes as soon as the agent is allowed to act at runtime. That makes visibility, ownership, and task-scoped access the core governance questions.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: Treat the agent as a governed identity with its own owner, policy, audit trail, and revocation path. Delegated access should be scoped to the task, time-limited, and tied to specific data and tools. If the agent can act beyond the immediate request, the identity model must control that expansion before it becomes normal behaviour.

Q: Why do AI agents create more identity risk than ordinary automation?

A: Ordinary automation usually follows a fixed path, but AI agents can decide how to reach an outcome and which tools to use along the way. That makes their effective privilege dynamic. The risk is not only what they are allowed to do at setup, but what they can combine or infer during execution.

Q: What breaks when human approval is the main control for AI agents?

A: Approval gates break down when the actor can request actions continuously and at machine speed. Reviewers will either delay work or start rubber-stamping requests. That turns human oversight into a formality instead of a control, especially when the agent is acting all day across multiple tools and data sets.

Q: When should organisations use just-in-time access for AI agents?

A: Use just-in-time access whenever the agent needs delegated permissions to touch sensitive data, call high-risk tools, or act on behalf of a user. Persistent credentials expand blast radius unnecessarily. The access should expire quickly and be narrow enough that the same token cannot support a different task later.

Technical breakdown

Why AI agents need identity governance, not just automation controls

AI agents differ from ordinary automation because they can reason, choose tools, and act within a runtime context that shifts as the task unfolds. That means the identity layer must govern both the agent itself and the delegated permissions it uses on behalf of a person or machine account. Access control alone is not enough if the agent can chain tool calls, access new data, or delegate again without a fresh governance decision. In practice, agents behave like identities with variable scope, not like fixed workflows with predictable paths.

Practical implication: define the agent as a governed identity object, not just an application, and attach ownership, policy, and auditability to it.

Task-based just-in-time access for agents and secrets

Task-based just-in-time access scopes an agent’s privileges to a specific request, then removes them quickly after the task completes. This is different from giving an agent a broad token or standing machine account because the agent’s next action is not guaranteed to match the original intent. For sensitive data, this matters even more because agents can surface, transform, or forward information faster than a human can review it. Zero-standing privilege becomes the safer default for high-value data and high-risk actions.

Practical implication: replace persistent delegated access with narrowly scoped, fast-expiring grants for each agent task and data domain.

Observability and centralized control planes for agent behaviour

Agent governance depends on more than logs. Security teams need to see which agent acted, what data it accessed, what tools it used, and whether the action sequence matched approved intent. A central control plane matters because detection without enforcement leaves teams with forensic evidence but no practical containment path. Once an agent begins to drift, the control problem is to stop the agent, revoke its access, or block the next step in the chain before the action becomes irreversible.

Practical implication: centralise logging, decision records, and kill-switch controls so high-risk agents can be contained without waiting for manual investigation.

Threat narrative

Attacker objective: The objective is to turn delegated agent access into unauthorized reach, data exposure, and workflow abuse faster than human governance can intervene.

1. Entry occurs when a user or system grants an AI agent delegated access through a token, machine account, or tool connection that was broader than the immediate task required.
2. Escalation happens when the agent uses reasoning and tool chaining to reach systems, data, or actions beyond the user’s original intent and the approval boundary is no longer meaningful.
3. Impact follows when the agent reveals credentials, shares sensitive data, or performs unauthorised actions at machine speed before a human can review or correct the path.

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

AI agents expose an identity problem, not just an automation problem. Once an agent can reason over tools and act on delegated permissions, the programme is no longer managing a script. It is managing a runtime identity whose effective privileges change with context, task, and downstream delegation. That moves the centre of gravity from workflow design to identity governance, and practitioners should treat agent access as a governed identity lifecycle.

Task-based just-in-time access is the right concept, but only because standing delegation is too coarse for agent behaviour. The article is correct that permanent permissions make little sense when an agent can pursue a task in multiple ways. The larger lesson is that least-standing privilege becomes a boundary condition for agent governance, not an optimisation. Security teams should read this as a requirement to rethink how access is granted, observed, and revoked for runtime identities.

Human approval gates do not scale as the primary control plane for agent security. The article notes that constant approvals will be ignored, and that is a governance failure, not a user-experience issue. A control model built for occasional human review collapses when the actor can request actions all day and all night. The implication is that agent governance must rely on pre-bound policy, ownership, and enforceable limits rather than hope that manual review will absorb machine-speed behaviour.

Named concept: identity blast radius. AI agents make blast radius a function of tools, delegated permissions, and data visibility rather than account type alone. If an agent can call multiple systems, surface secrets, and delegate further, the damage boundary expands dynamically during execution. Practitioners should think in terms of how far one agent decision can propagate before containment becomes impossible.

Visibility without ownership creates orphaned autonomy. An agent directory can show what exists, but that does not tell you who is accountable when behaviour changes or access must be withdrawn. The article’s emphasis on succession planning is important because agent ownership is part of the control surface, not a support detail. Governance teams should ensure every agent has a responsible owner and a clear escalation path before deployment accelerates.

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.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a compliance and investigation blind spot.
• That pattern is why practitioners should also review OWASP Agentic AI Top 10 alongside their agent access model.

What this signals

Identity blast radius: agent risk is no longer defined by account type alone, but by how far a delegated action can propagate through tools, data, and downstream delegation. With 92% of practitioners saying governing agents is critical and only 44% reporting policies in place, the operating model is already behind the adoption curve. Teams should expect agent governance to become a board-level identity issue, not a niche AI control topic.

The near-term programme signal is that approval-based guardrails will not carry the load by themselves. As agents multiply, security teams need ownership, observability, and revocation paths that work at machine speed. That also means aligning policy with NIST AI Risk Management Framework principles where accountability and governance are explicit, not implied.

The practical next step is to separate harmless assistant behaviour from true delegated execution. Not every AI feature is autonomous, but every feature that can call tools, access secrets, or forward data should be treated as an identity control problem. The organisations that build that distinction into their IAM and PAM programmes early will have a cleaner path to scale than those that rely on review queues after deployment.

For practitioners

• Classify each agent as a governed identity object Assign an owner, an access boundary, and an audit record to every agent, including shadow agents and tools embedded in development workflows.
• Scope delegated access to the task, not the agent Issue short-lived permissions that match the request context, then remove them after completion so the same access cannot be reused for a different objective.
• Centralise agent logging and containment Record which tools were called, what data was touched, and whether the action chain stayed within policy, then connect that telemetry to a control plane that can revoke access quickly.
• Reserve human approval for genuinely exceptional actions Use manual approval only for rare high-risk steps, because repeated prompts will be ignored and create the illusion of control rather than real governance.
• Build risk profiles from tool reach and data scope Prioritise the agents with the largest permission sets, the broadest data exposure, or the most downstream delegation paths for tighter review and monitoring.

Key takeaways

• AI agents turn identity governance into a runtime control problem because their permissions can expand as they reason, call tools, and delegate further.
• SailPoint’s survey shows the issue is already live in production, with 80% of organisations seeing agents act beyond intended scope.
• Task-scoped access, ownership, observability, and fast revocation are the practical controls that matter most for agent security.

Key terms

• AI Agent Identity: An AI agent identity is the set of credentials, permissions, ownership, and audit trails that allow an agent to act in an environment. Unlike a static service account, the agent may choose tools and sequence actions at runtime, so governance must account for changing behaviour and delegated scope.
• Task-based Just-in-Time Access: Task-based just-in-time access grants permissions only for the specific action an agent needs, then removes them quickly after use. It limits exposure when the agent is acting on behalf of a person or another system, and it reduces the chance that one successful task becomes reusable access.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it is abused or behaves unexpectedly. For AI agents, the blast radius depends on tool reach, data access, and delegation paths, not just on whether the account is human or machine-owned.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 governance in your organisation, it is worth exploring.

This post draws on content published by SailPoint: Securing AI agents: How to govern your ‘Cyborg Teenagers’. Read the original.