(This article originally appeared in CDO Magazine’s Trend Report, Generative + Agentic AI: Moving From Experimentation to Enterprise Scale.)

Identity programs running in an enterprise today assume that something predictable sits behind each credential: either a person logging in or a service account doing the same narrow job it was built for, day after day.

Agentic AI doesn’t behave that way.

An autonomous agent can decide in the moment what to touch next. It might query a CRM, then a file store, and finally a third-party API, based on reasoning that happened seconds earlier and that nobody scripted in advance. It can spin up other agents to help finish the job, which is the point of building agents this way. Plugging these agents into an identity framework designed for humans and static machines creates exposure that chief data officers (CDOs) and their security counterparts may not have fully priced in yet.

Why AI Agent Identities Create a New Kind of Risk 

A stolen password is a known problem with known playbooks. An agent identity is harder, because the danger isn’t always that the credential got stolen. The bigger concern is that the credential may be used exactly as designed, by the system it was issued to, to do something nobody would have approved if they’d seen it coming.

Here’s what worries me most: an agent doesn’t need to be hacked to cause damage; it just needs the wrong input. A manipulated document, poisoned API response, or a prompt injection buried in the data can steer an agent into actions that look completely legitimate in the logs, because they are legitimate. Traditional intrusion detection was built to catch an outsider misusing stolen credentials, not a properly authenticated system talked into misusing its own.

This kind of scenario isn’t hypothetical. In one widely reported 2026 incident, a research AI model was evaluated inside an isolated sandbox. The model found a flaw in a software proxy it used to install dependencies, broke out of the sandbox, and reached the open internet. It located publicly exposed credentials and used them as part of a chain of actions that ultimately compromised third-party systems. The model carried out thousands of actions over several days before the activity was fully detected and contained. Nobody stole a password from a vault; the model found access sitting out in the open and used it with the speed of an automated system rather than a person.

Another challenge that is often underestimated is the volume of identities an agentic system can create. A top-level agent working through a complex task can break the task into pieces and instantiate a separate agent for each piece. Sometimes a sub-agent spins up another agent, layers deep before anyone’s watching.

That kind of recursive spawning is one of the reasons non-human identity counts are climbing as fast as they are: Palo Alto Networks’ 2026 Identity Security Landscape report puts the overall machine-to-human identity ratio at 109 to 1, up from 82 to 1 the year before. When nobody designs how a child agent gets its own credentials, the easy default is for the child to inherit whatever access its parent already has. That’s how ten agents end up sharing one identity, with no way to say afterward which one did what.

Rethinking Identity and Authorization for AI Agents 

Securing agent identities starts with refusing to let an agent borrow a human’s login or a shared service account just to get a pilot working faster. As a default, every agent and every sub-agent it spawns should get its own identity from day one, tied to a named human accountable for its actions.

That default can flex for narrow, low-risk cases; a batch of short-lived workers doing identical, read-only fan-out work might reasonably share one tightly scoped identity, with the orchestrator that spawned them carrying accountability for the batch. But anything that writes, deletes, or touches money, legal exposure, or customer data needs its own identity, full stop, because that’s exactly where “which agent did this” stops being a nice-to-have and becomes the question that matters.

Authentication has to establish more than who is logging in; it has to confirm which specific agent is acting, not a shared account or a borrowed human credential. Authorization then has to evaluate something authentication can’t: whether the action the agent is attempting right now actually fits the task it was assigned. In practice, that’s where a simple test helps more than another policy document. Before letting an agent take an action, four questions should get answered, not once at login, but at the moment of the action itself:

• Who is acting? Not a shared account, not a human’s borrowed credential, a specific agent identity tied to a named owner.
• Why this action? Does it fit the goal the agent was given, or has it drifted into something adjacent nobody approved?
• How much access does it need, right now? Not what it was granted at setup, but what this exact step requires.
• What happens if this is wrong? Anything touching money, legal exposure, or customer data should trigger a checkpoint before it executes.

Get an agent through those four honestly, and incidents like those described above become far harder to carry out, because the access that made them possible was never granted in the first place.

Least Privilege Must Move as Fast as the Agent Does

Least privilege for a human role gets set once and reviewed on a schedule because human access needs change slowly. Agents blow that assumption up. An agent handling a single customer inquiry might legitimately need account data for thirty seconds and never need it again. If that access doesn’t disappear the moment the task is done, you’re carrying risk for no reason.

For agentic systems, least privilege can’t operate only at the role level. Access needs to shrink and expand at the level of the individual action:

• An agent moving from a broad research step into a narrow write action should lose the broader read access the instant it commits to the narrower one.
• Anything an agent hasn’t used within a defined window should get pulled back automatically, not left standing on the theory it might come in handy later.
• Permission boundaries should be re-evaluated at every step of a task, not assigned once at the start.

The old lesson of least privilege is one that agentic AI is about to teach again, at a much bigger scale. A well-documented breach at a major financial institution in 2019 makes the point cleanly: a cloud role tied to a web application carried far more permission than its job required, and an attacker used that excess to reach data across hundreds of storage buckets in one move. The access was just sitting there, and nothing narrowed it automatically. Agents reproduce that failure mode unless the system tightens access as the task narrows.

Managing Agent Credentials and Traceability at Scale 

Once an organization has more machine identities than human ones, credential management can’t run on a spreadsheet and good intentions. Manual processes can’t keep pace with agents created and retired within a single workflow. A few things become non-negotiable at that scale:

• Automate the full credential lifecycle: Credential issuance, rotation, and revocation should run without a person in the loop for routine cases, with human review reserved for anomalies.
• Log the decision, not just the action: Traceability needs to capture why an agent acted, what goal it was pursuing, and what upstream trigger set the chain in motion. If a customer service agent flags a charge as fraud and spins up a sub-agent to freeze the account, the log should tie the freeze back to the parent’s identity, the customer message that triggered the flag, the goal it handed down, and the sub-agent’s own identity and permissions at that moment. Without that chain, an investigator later sees only that an account got frozen, with no way to tell why or on whose authority.
• Keep a live inventory: Each agent identity, owner, permissions, and expiration should be visible in one consolidated view, not pieced together after an incident.
• Assign accountability at creation: Every agent identity should be born with a named human owner, not traced backward after something’s gone wrong.

Moving Agentic AI From Pilot to Production 

Pilots get a pass on rigorous AI governance because the exposure feels small. That’s the trap. Shortcuts taken during a pilot can become part of the default architecture as the system succeeds and scales, because nobody wants to go back and fix something that already looks like it’s working.

Before letting an agentic deployment grow past a pilot, I’d want honest answers to a few questions:

• Does every agent have its own identity, or is one still running on a shared account from testing?
• Are credentials scoped and time-bound by default?
• Can authorization deny or pause a specific action in real time, or does the architecture assume login approval covers everything downstream?
• Can the organization reconstruct quickly and easily which agent did what and who’s accountable?

A weak answer to any of those means fixing that specific gap now, while it’s cheap, before scale makes it expensive. Start with the highest-consequence gap. For example, fix the missing identity on a payment-touching agent before fixing the missing identity on a read-only one, and set a deadline for it to be fixed. The goal is closing gaps faster than the deployment is growing, not having every answer perfect before taking the next step.

An agent that acts on its own only has value if people can rely on what it did and why, without having to reconstruct its reasoning after something’s gone sideways. That confidence comes from knowing exactly who took an action, under what authority, and with what access, every time.

Organizations building those controls in now will be better prepared to scale agentic AI. The rest will scale too; they’ll just be finding out what their agents did after the fact.