An employee with excessive access may make a mistake. An AI agent with excessive access can potentially execute a large number of actions quickly, across multiple systems, without waiting for a person to intervene.
That changes the potential blast radius of a permission.
Key Takeaways
- The risk of an AI agent is determined not only by what it can access, but by what it can do with that access.
- Broad inherited permissions can make agent activity difficult to constrain and investigate.
- Delegation and task-scoped access provide a more precise way to govern agent authority.
- Runtime policy can help prevent an otherwise valid identity from performing an inappropriate action.
Access is not the same as authority
An agent may need access to an application without needing every permission available within that application.
This distinction is easy to lose when agents inherit permissions from the people they represent.
Imagine an employee has broad access to customer operations because of their role.
The employee asks an AI assistant to prepare a customer report.
If the agent simply inherits the employee's full permissions, the agent may technically be able to do much more than the task requires.
The problem is not necessarily a compromised agent.
The problem is that the architecture granted more authority than the task required in the first place.
Delegation should narrow authority
A better model starts with the task.
What is the agent being asked to do?
Which information does it need?
Which action does it need to perform?
How long does it need that access?
Does the action involve a sensitive resource or an irreversible change?
These questions allow authority to be scoped around purpose.
Ping's current guidance describes this as delegated access rather than impersonation: an agent should receive limited authority to act on behalf of a principal rather than simply inherit that principal's credentials and permissions.
This is particularly important when agents delegate work to other agents or tools.
Authority should not automatically expand simply because the workflow becomes more complex.
The delegation chain matters
Consider a simple workflow:
A sales employee asks an agent to prepare a customer renewal.
The agent retrieves customer information.
It sends selected information to another specialised agent.
That agent calls a pricing service.
The pricing service returns a recommendation.
There are several actors in this chain.
If each step simply inherits the permissions of the previous step, the original authority can expand as the workflow progresses.
A more controlled approach passes only the authority required for the next step.
The principle is straightforward:
Delegation should preserve intent, not multiply privilege.
Ping's recent guidance similarly describes scoped, time-bound delegation and the use of token exchange to narrow authority as work moves through an agent chain.
Static permissions become problematic at machine speed
Traditional access governance often works through provisioning and periodic review.
Those controls remain important.
But an autonomous agent may make hundreds or thousands of decisions between reviews.
This does not make periodic governance irrelevant. It means it needs to be complemented by controls that operate at the time an action occurs.
Runtime identity moves authorisation closer to execution, allowing policy to consider the current request, context, delegated authority and resource rather than relying entirely on permissions established earlier.
For sensitive actions, the organisation may also require human approval.
That creates a graduated model of autonomy rather than treating every agent action as equally trusted.
Least privilege should include time
There is another dimension to consider.
An agent may need access for a task but not indefinitely.
Long-lived credentials and standing permissions increase the opportunity for misuse and make it harder to understand whether an access right is still justified.
Short-lived credentials, task-specific scopes and just-in-time access can reduce that exposure.
Again, the underlying principle is familiar.
Identity security has long sought to minimise standing privilege.
Agentic systems make that principle more urgent because the actor can continue operating long after the person who initiated the workflow has stopped paying attention.
The governance question is about blast radius
When evaluating an agent, organisations should therefore look beyond:
“Is this agent trusted?”
and ask:
“If this agent were compromised or behaved outside its intended purpose, what could it do?”
That question produces a much more useful risk assessment.
An agent with access to a single read-only data set has a very different risk profile from an agent that can modify customer records, initiate payments and invoke additional agents.
The answer should influence the level of control applied.
Designing for constrained autonomy
The goal of least privilege is not to make agents ineffective.
It is to give them enough authority to complete their intended work without giving them unnecessary authority to do everything else.
That requires a combination of:
- distinct agent identities;
- explicit delegation;
- narrowly scoped permissions;
- time-bound access where appropriate;
- runtime authorisation;
- human approval for high-impact actions; and
- audit records that preserve the chain of authority.
These controls are not unique to AI.
They are established identity and security practices adapted to a new class of actor.
The difference is that agentic systems make the consequences of getting privilege wrong much faster.
The safest agent is not necessarily the one with the fewest permissions. It is the one whose permissions are precise enough that its autonomy remains bounded by the purpose for which it was created.
From Breach to Board-Ready: A Governance Playbook for Agentic AI
Discover how identity-first governance can help organisations secure AI agents, enforce least privilege and strengthen enterprise oversight.
