Table of Contents
Why Most AI Agent Deployments Are One Token Away From Disaster
AI agents are catching up quickly – even quicker than the models of security that organizations constructed to enable the usage of humans. And the cracks are showing.
Ask any security team operating an agentic workflow, and the story will be the same: an agent is running on an agentic token that is cloned, a shared service account which is shared across dev, staging, prod, and which includes a static API key that is not expired and owned by no one. These aren’t edge cases. As the OWASP top 10 lists of Agentic Applications 2026, over-privileged machine identities, and long-lived shared secrets, lie at the base of most agentic risk exposures – including the goal hijacking risk to the rogue agent behavior risk.
The least privilege principle of AI agents is not a novel idea. However, using it correctly, with limited permissions, agent identities, limited access based on time, and a clearly defined blast radius is where most teams continue to go on a case-by-case basis.
This article dissects the way it works, the anti-pattern appearance, and what is good in the entire stack look-like.
The Anti-Patterns Killing Agentic Security Right Now
Agents Borrowing Human Admin Tokens
It is how I believe the most frequent error I have witnessed in the actual deployments. One of the developers ends up spinning up an agent, whose operations require it to invoke an internal API, and with which he or she supplies his or her own OAuth token or a long-lived teammate administrator credential. It takes effect instantly – and that is the trouble.
Permissions that are assigned to human admin tokens are tied to the entire role of a person, rather than an operation. Upon an agent taking one, it acquires read/write access to things that it has no interest in touching. When such an agent might be manipulated later in time, such by a prompt injection, through a tool that is compromised, or through a corrupted memory state, such an agent may do something inconsistent with the intent of any individual.
Shared Service Accounts Across Environments
One of the most evident indicators of a failed privilege model is the non-human identification as was discussed in the OWASP NHI Top 10 flags. In cases where the same service account authenticates agents in dev, staging and production, a violation in one environment is a violation in the other two environments. Cascade failures are not theoretical, it is the rational outcome of the operation of credential reuse.
Static Keys With No Expiry
The agentic counterpart of locking your front door with an unlocked front door is the use of long lived API keys and non-rotating statical secrets. The FINOS AI Governance Framework MI-18 control specifically states that the existence of non-expiring and non-changing credentials is a structural risk that undercuts all other controls downstream.
I had a chance to practice that even teams that are otherwise strong in IAM habits of treating human users heedlessly neglect key rotation of machine identities – merely because there is no process to drive it.
Per-Agent Identities: Every Agent Needs Its Own “Persona”
What a Per-Agent Identity Actually Means
The fix begins prior to the running of a single task by an agent. This is to be registered under each agent, with a distinct client/app registration, service principal, or service account, a principal who has a known owner, and a purpose for which that registration was created.
This isn’t just bureaucracy. It forms the basis of all other features: scoped permissions, audit trail, revocation, and rotation. In its absence, you end up entering the service-account-shared-01 called the payments API, rather than invoice-processing-agent called the payments API, triggered by workflow X, on behalf of user Y.
It is well explained in the Apono blog on agentic AI security that the existing models of statical privilege models designed to serve human users fail utterly in agentic contexts since agents do not act as human beings. They are running, burst-calling APIs, multi-session operating, and do not have a natural log off point.
Ownership and Purpose as Security Controls
At registration, every agent identity must respond to two questions, namely, who owns this identity, and what is the purpose? Ownership brings accountability because, in the case of rotating credentials, reviewing access, and decommissioning the identity, someone is held responsible when an agent retires. Purpose imposes the restriction that renders least privilege design to be a tractable problem.
A more general problem of managing non-human identities at scale, in terms of their provisioning, monitoring, and revocation, is an area that I explored in a more detail in the Identity Crisis – Securing Non-Human Identities for AI Agents, in which I describe the NHI governance layer that lies beneath all of the following in this document.
Scope Design: Permissions That Match the Task, Not the Team
Task-Scoped Permissions
The purpose of the scope design is straightforward: an agent must have the access to the APIs and access resources that are needed by the particular workflow. Nothing hereditary, nothing adopted, nothing in case.
This on the ground translates to workflow and not agent-based permissions. An agent of document summarization must have a read access into a document store. It does not require write access, delete access or access to neighbouring services. I observed that this degree of granularity is generally initially resisted by most teams as it seems like overhead, but the overhead substantially decreases as soon as you have settled into a common pattern of scoping at workflow design time as opposed to debugging some access problems in production.
Cerbos comes in handy in this case: policy permissions are policies on actions, not a policy on identities. The identity of the agent then makes a request to do a particular act in a particular environment and the policy level responds to the request by granting or denying one. It emails out the issue of who this agent is and what this agent is permitted to do at this point in time.
Environment-Scoped Access
The Dev domain, staging and Production domains are treated as different permission domains, as there are no shared credentials. This might seem self-evident, but the advice provided by Cloud Security Alliance regarding the containment of blast radius reminds how frequently the limits to environments are violated in practice – most of the time someone has to do something fast and cross a boundary with a credential, once only.
The environment-scoped access is such that an agent in a dev environment could be completely compromised, and still the attacker will have nothing useful in production. The isolation of the environments is at the identity layer and not only the network layer.
Time-Bound and Just-in-Time Access: Stop Trusting Long-Lived Tokens
Short-Lived Tokens as a Default
One of the changes that can be made maximum leverage by an organization is the shift of long-lived to short-lived tokens. Something that goes out of business in 15 minutes will have a much different risk profile compared to something that lasts the year. The intervention period is narrow even within the context that it is stolen or abused.
Self-service tokens are also short in time, causing an operational positioning that is healthy. When your agent cannot operate without re-fresh of its credentials, then you have to start the workflow with integrating appropriate credential management, instead of embedding a secret key and forgetting about that secret.
Just-in-Time Elevation via PAM
A standing permission is not the right model to use in sensitive operations, especially when writing to production databases, calling financial APIs, modifying infrastructure, etc. It improves just-in-time (JIT) by using Privileged Access Management (PAM) system.
JIT elevation implies that the agent demands elevated access during the time of need, when PAM system issues time-limited role to that specific action, and the elevated access is automatically withdrawn after closing the window. Strata.io analysis of least privilege in agentic AI Technically, the argument is that JIT access is the only model to scale gracefully to an agent becoming more autonomous since it decouples the identity a base of the agent is given in any given time and authorization that may be temporarily conferred on the agent and the audit trail is kept clean.
My Experience has demonstrated that latency is the primary contribution point in this situation – JIT flows introduce a round trip. The practical way out is to model the workflows in such a manner that sensitive elevated operations are batched or pre-authenticated in a specification session window, instead of having a new JIT request with each API call.
Blast Radius Control: What Happens When Something Goes Wrong
Mapping OWASP Agentic Risks to Scope Controls
According to the OWASP Top 10 of Agentic apologetic, 2026 newcomers there are number of categorizations of risks where least privilege is a direct control measure:
ASI01 — Goal Hijacking: This occurs when an agent is tricked into the achievement of unwanted goals (through its prompt injection or misleading context) scope restrictions control the extent of its harm. Even when the agents objectives have been redefined, an agent with read-only capability on a given document store cannot steal data outside of a database to which it has no access.
ASI02 Tool Misuse: A compromised agent who can access wide tool sets is more hazardous. Task-scoped permissions imply the access to the tools of the agent only to the extent they are required by the legitimate workflow on which the agent should operate – lowering the attack surface to potentially be exploited by the tools.
ASI03 Identity and Privilege Abuse: Per-agent identities that are owned or documented are a much harder target, since they are much less prone to abuse without being detected as anomalous. The shared ones cannot be seen in the audit logs whereas dedicated agent identities can be.
ASI10 – Rogue Agent Behavior: Time-bound tokens come in handy in this case. An agent that is not expected to be used in its workflow will expire its credential and be unable to perform any work, and serve as a natural circuit breaker restricting autonomous operation out of bounds.
The Blast Radius Formula
Blast radius in agentic systems is the question of three variables, including widths of permissions that an identity has, the duration of those permissions, and environments to which an identity may access. This is encapsulated in the Lumos model of blast radius in cybersecurity whereby all units that narrow the scope, reduce the token lifetime, or distance environments directly lowers the blast radius of a particular compromise.
The math is straightforward. a long and cross-environment, long-lived, and administration (admin) credential has a blast radius which covers the whole organization. The blast radius of an agent with 15minute and task-scoped tokens that is confined to staging is determined by a handful of API endpoints. That’s the design goal.
What “Good” Actually Looks Like: A Practical Checklist
Forming a list of teams building or auditing the agentic privilege models, this is a working reference:
Identity Layer
- Every agent possesses a service account, or services principal or client registration.
- Each identity is owned by somebody and there is a purpose documented.
- Cross-agent or cross-environments credentials are forbidden.
Scope Layer
- The permissions are set at the workflow level as opposed to the agent level.
- Each task has set APIs and resources plus actions of which only a subset are accessible.
- The domains of dev, staging and production are independent permission domains with no credential cross-over.
Temporal Layer
- The default token TTL is 15-60 minutes based on the sensitivity of workflow.
- Exception and frequent review is necessary of tokens that are long lived.
- JIT elevation is used in sensitive operations via a PAM system where the expiry is automatic.
Monitoring Layer
All agent API calls are recorded under a particular agent identity and not a common account.
Anomaly detection is adjusted to patterns of behavior of the agent and not the human session.
The monitored and alerted events include credential expiry and rotation.
My Take: Least Privilege Isn’t a One-Time Configuration
The greatest myth I have experienced is the mistake of viewing least privilege as a configuration activity – one that you develop at deployment and forget once complete. It is a continuous discipline of operations in agentic systems.
Agents evolve. Workflows change. New tools get added. With every change comes the possibility of scope creep, drift in credentials or a new anti-pattern creeping in. Organizations which find it right will consider privilege review through the agent lifecycle, not as a checkbox when deploying agents.
The Obsidian Security summary of AI agent security repeats a point that should be reiterated, namely that the threat model of AI agents is not the same as that of human users and the controls must be indicated to reflect this. Time-based access, agent identities, task-specific permissions, intentional sentence of blast radius design are not optional hardening measures. They’re the baseline.
I’m a technology writer with a passion for AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and curious. and encourage participation I continue to research innovation and technology. Let’s connect and talk technology!
