Intent-based security for AI agents: why identity now breaks

At a glance

What this is: This is a blog post arguing that AI agent security must move from static permissions to intent-based control because agent behaviour is goal-driven and runtime-adaptive.

Why it matters: It matters because IAM, PAM, and NHI programmes cannot govern autonomous access reliably if they only model who can authenticate and not what the actor is trying to achieve.

Context

AI agent identity governance fails when security assumes access can be described once at provisioning time and remain stable. AI agents do not behave like deterministic workloads, and they do not fit neatly into human-era permission models because they adapt their actions at runtime.

The governance gap is not just more access. It is that the control plane has to understand identity, intent, and lifecycle together. In practice, that means teams need to decide whether the subject is a human, a service account, or an autonomous actor before they can enforce the right guardrails.

Token Security frames the issue as an identity problem because agents interact through credentials, roles, keys, and tokens. That framing is accurate, but the deeper problem is that runtime behaviour can exceed the assumptions embedded in static access policies.

Key questions

Q: What breaks when AI agents are managed like ordinary machine identities?

A: What breaks is the assumption that access scope can be fully understood from provisioning data and quarterly review. Ordinary machine identities are repeatable; agents are not. If teams only review entitlements, they miss context shifts, delegated actions, and credential creation inside the session.

Q: Why do AI agents make least privilege harder to enforce?

A: AI agents can move across multiple services, make autonomous decisions, and trigger several machine-to-machine actions in one task. That creates more opportunities for privilege creep, overuse, and lateral movement. Least privilege is harder when the system must authorise not only who is acting, but what the agent is doing right now.

Q: How can organisations tell whether an AI agent is acting outside its intended scope?

A: Organisations should look for behaviour that crosses expected tool boundaries, generates unusual credentials, or chains actions across systems that are not part of the original task. The signal is not simply high activity. It is a change in action pattern, delegation, or downstream access context.

Q: Should organisations treat AI coding agents as part of IAM and PAM governance?

A: Yes, when those agents can act on code, data, or tools in ways that affect production risk. Their permissions should be scoped, reviewed, and audited like other privileged systems, especially when they interact with sensitive routes, secrets, or regulated data. The governance question is who can let the agent act, and under what policy.

Technical breakdown

Why static permissions fail for AI agents

Traditional IAM assumes an identity’s required access is knowable in advance and remains relatively stable. AI agents do not follow that pattern. They take objectives, break them into sub-tasks, and choose actions at runtime based on context, which means two agents with the same nominal permissions can exercise those permissions very differently. That breaks the comfort of role design built around predictable application behaviour. A role is no longer a complete description of safe access when the same credential can be used to inspect logs, alter infrastructure, create tickets, or call downstream automation. For agentic systems, authorization has to account for purpose, not just entitlement.

Practical implication: Reassess whether role design is expressive enough to bound agent behaviour or whether runtime intent controls are required.

Identity as the control plane for agent access

AI agents operate through service accounts, cloud IAM roles, API keys, and tokens, so the enforcement point naturally sits at the identity layer. That does not mean identity alone solves the problem. It means every agent action inherits the risk posture of the credential it uses, and broad credentials become broad behavioural authority. When access is inherited from creator accounts or copied from automation patterns, the result is often privilege drift. The article’s core point is that access control cannot be bolted onto an agent after the fact. The identity used by the agent is the mechanism through which all system interaction occurs, so governance has to start there.

Practical implication: Inventory every credential an agent can use and tie each one to a named owner, purpose, and lifecycle state.

Intent-based security changes what 'least privilege' means

Least privilege for AI agents is not just a smaller permission set. It is access scoped to a declared objective and evaluated against that objective while the agent runs. In a human context, an access review can ask whether a user still needs an entitlement. In an agentic context, the more relevant question is whether the current action sequence still matches the intended task. That is why intent becomes a security signal, not a documentation exercise. Once an agent’s behaviour drifts outside its declared purpose, the issue is no longer only excess privilege. It is that authorization and purpose have become misaligned in real time.

Practical implication: Define the intended task before issuance and use that intent to constrain which actions remain acceptable during execution.

Threat narrative

Attacker objective: The objective is to gain or abuse machine-speed access that can modify infrastructure, automate actions, or create persistence under legitimate-looking identity authority.

1. Entry occurs when an AI agent receives working credentials such as a service account, cloud IAM role, API key, or token that can touch enterprise systems.
2. Credential exposure becomes privilege exposure when those credentials carry broad permissions copied from human or automation patterns rather than task-scoped access.
3. Escalation happens when the agent chains system interactions across logs, configuration, tickets, and automation pipelines beyond the original purpose of the task.
4. Impact is governance collapse, where security teams can no longer explain who owns the agent, what it can do, or whether its actions still match its intended purpose.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static IAM assumptions collapse when the actor is goal-driven. Traditional access models presume that an identity’s purpose can be translated into a stable permission set at provisioning time. AI agents violate that premise because they decide how to pursue an objective at runtime, not just whether to invoke a pre-scripted workflow. The implication is that policy has to move from entitlement-only logic to behaviour-aware governance.

Identity, not prompt filtering, is the real enforcement boundary. Prompt moderation can shape language, but it cannot bound what an agent is allowed to do once credentials exist. That means the decisive control point is the identity layer where service accounts, API keys, and tokens authorize downstream action. Practitioners should treat every agent credential as a potential action surface, not a mere authentication artifact.

Intent-based security creates the missing bridge between least privilege and runtime behaviour. The article correctly identifies that the question is not only what an agent can access, but what it should be doing for its current objective. This is a material shift for identity governance because it turns purpose into a control input, not just an approval note. Teams should expect their access model to become task-scoped rather than role-stable.

AI agent lifecycle governance is already an identity governance problem. Agents are easy to create, copy, and forget, which means privilege accumulation can happen silently over time. That is the same governance failure pattern identity teams know from unmanaged accounts, but with faster drift and less human visibility. The practical conclusion is that lifecycle controls now matter as much as runtime controls for autonomous access.

Runtime access drift: Agentic systems invalidate the assumption that authorization decisions remain meaningful if access is static. Once the actor can alter its action path mid-session, the governance model has to account for changing intent, not just assigned permissions. Practitioners should treat this as a category shift in identity governance, not an incremental policy tweak.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: AI Agent Authorisation Guide

What this signals

Intent-based security becomes the practical answer to runtime autonomy. Access reviews assume stable privileges that can be certified after the fact, but AI agents can acquire, use, and vary access while they are still working. That makes issuance-time constraints more important than periodic attestations, and it shifts the governance burden toward purpose-bound access design.

Risk scales when agent access is broader than human access for the same job. According to the 2026 Infrastructure Identity Survey, systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, and organisations failing to scope AI access properly are 4.5x more likely to experience a security incident. That gap is exactly why runtime scope control belongs in the identity programme, not in a chatbot policy layer.

For practitioners

• Define agent purpose before access is issued Record the specific objective, allowed system scope, and prohibited actions for each AI agent before credentials are created or granted.
• Bind agent credentials to named ownership Assign a human owner for every service account, token, or role an agent can use, and require that owner to remain accountable across changes.
• Replace broad roles with task-scoped permissions Break agent access into narrow privileges aligned to the job the agent is actually performing, then remove any inherited creator-level access.
• Review lifecycle drift continuously Track when an agent’s permissions, integrations, and task scope expand beyond the original use case so dormant experiments do not become unmanaged production identities.
• Alert on intent mismatch in runtime actions Treat attempts to modify infrastructure, access sensitive data, or trigger automation outside the declared objective as governance failures, not just anomalies.

Key takeaways

• AI agent security breaks the assumption that access can be defined once and treated as stable through the life of the identity.
• The control problem is not just authentication, but aligning identity, intent, and lifecycle with behaviour that changes at runtime.
• Organisations that fail to scope AI access properly face materially higher incident risk, so task-scoped governance is now a core identity requirement.

Key terms

• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• Intent-based security: Intent-based security governs access by combining what an AI agent can do with what it is supposed to achieve. The model uses purpose, context, and runtime behaviour to decide whether an action remains within bounds. It is especially useful when agents adapt their plans during execution.
• Runtime behaviour: Runtime behaviour is what an agent actually does after access has been granted, including tool use, data access, sequencing, and response to untrusted inputs. In agentic systems it is often the real security signal, because harm can occur without any authorization failure.
• Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.