Author: Itamar Apelblat, CEO and Co-Founder, Token Security

Not long ago, AI deployments inside the enterprise meant copilots drafting emails or summarizing documents. Today, AI agents are provisioning infrastructure, answering customer support tickets, triaging alerts, approving transactions, writing production code, and so much more. They are no longer passive assistants. They are operators within the enterprise.

For CISOs, this shift creates a familiar but amplified problem: access.

Every AI agent authenticates to systems and services. It uses API keys, OAuth tokens, cloud roles, or service accounts. It reads data, writes configurations, and calls downstream tools. In other words, it behaves exactly like an identity, because it is one.

Yet in many organizations, AI agents are not governed as first-class identities. They inherit the privileges of their creators. They operate under over-scoped service accounts. They are granted broad access just to make sure things work. Once deployed, they often evolve faster than the controls around them.

This is the emerging blind spot in AI security.

The first step toward closing it is what we call identity-first security for AI: recognizing that every autonomous agent must be governed, audited, and attested just like a human user or machine workload. That means unique identities, defined roles, clear ownership, lifecycle management, access control, and auditability.

But here’s the hard truth: identity alone is no longer sufficient.

Traditional identity and access management (IAM) answers a straightforward question: Who is requesting access? In a human-driven world, that was often enough. Users had roles and job functions. Services had defined scopes. Workflows were relatively predictable.

AI agents change that equation.

They are dynamic by design. They interpret inputs, plan actions, and call tools based on context. An AI agent that begins with the mission to generate a quarterly report might, if prompted or misdirected, attempt to access systems unrelated to reporting. An infrastructure agent designed to remediate vulnerabilities might pivot to modifying configurations in ways that exceed its original scope.

When that happens, identity-based controls don’t necessarily stop it from happening.

Traditional IAM assumes determinism. A role is granted because a user or service performs a defined function. The scope of action is predictable.

AI agents break that assumption. Their objective may be fixed, but the path they take to achieve it is fluid. They reason, chain tools together, and explore alternative actions.

Static roles were never designed for actors that decide how to act in real time. If the agent’s role allows the action, access is granted, even if the action no longer aligns with the reason the agent was deployed in the first place.

This is where intent-based permissioning becomes essential.

If identity answers who, intent answers why.

Intent-based permissions evaluate whether an agent’s declared mission and runtime context justify activating its privileges at that moment. Access is no longer just a static mapping between identity and role. It becomes conditional on purpose.

Consider an AI agent responsible for deploying code. In a traditional model, it may have standing permissions to modify infrastructure. In an intent-aware model, those privileges activate only when the deployment is tied to an approved pipeline event and change request. If the same agent attempts to modify production systems outside that context, the privileges do not activate that access.

The identity hasn’t changed, but the intent, and therefore the authorization, has.

This combination addresses two of the most common failure modes we’re seeing in AI deployments.

First, privilege inheritance. Developers often test agents using their own elevated credentials. Those privileges persist in production environments, creating unnecessary exposure. Treating agents as distinct identities can help eliminate this bleed-through.

Second, mission drift. AI agents can pivot mid-run based on prompts, integrations, or adversarial input. Intent-based controls prevent that pivot from turning into unauthorized access.

For CISOs, the value isn’t just tighter control. It’s governance that scales.

AI agents interact with thousands of APIs, SaaS platforms, and cloud resources. Trying to manage risk by enumerating every permissible action quickly becomes unmanageable. Policy sprawl increases complexity, and complexity erodes assurance.

An intent-based model simplifies oversight. Governance shifts from managing thousands of discrete action rules to managing defined identity profiles and approved intent boundaries.

Policy reviews focus on whether an agent’s mission is appropriate, not whether every individual API call is accounted for in isolation.

Audit trails become more meaningful as well. When an incident occurs, security teams can determine not only which agent performed an action, but what intent profile was active and whether the action aligned with its approved mission.

That level of traceability is increasingly critical for regulatory scrutiny and board-level accountability.

The broader issue is this: AI agents are accelerating faster than traditional access control models were designed to handle. They operate at machine speed, adapt to context, and orchestrate across systems in ways that blur the lines between application, user, and automation.

CISOs cannot afford to treat them as just another workload.

The shift to agentic AI systems requires a shift in security thinking. Every AI agent must be treated as an accountable identity. And that identity must be constrained not only by static roles, but by declared purpose and operational context.

The path forward is clear. Inventory your AI agents. Assign them unique, lifecycle-managed identities. Define and document their approved missions. And enforce controls that activate privileges only when identity, intent, and context align.

Autonomy without governance is a massive risk. Identity without intent is incomplete.

In the agentic era, understanding who is acting is necessary. Ensuring they are acting for the right reason is what makes agentic AI secure.

If you’re securing agentic AI we’d love to show you a technical demo of Token and hear more about what you’re working on.

Sponsored and written by Token Security.