TL;DR:
- AI agents are moving from answering questions to taking autonomous actions across enterprise systems, and Gartner projects 33% of enterprise apps will have agentic AI built in by 2028.
- Traditional IAM was built for humans and static applications, not for autonomous agents that call multiple tools and other agents on their own.
- Access (what an agent can do) and identity (which specific agent is doing it, on whose authority) are two different things – and most enterprises only govern the first.
- In practice, identity breaks down through shared credentials, long-lived API keys, over-permissioned agents, unscoped agent-to-agent delegation, and audit logs that show accounts but not the full chain of action.
- A secure model requires unique per-agent identity, short-lived scoped credentials, least privilege, clear delegation chains, external policy enforcement, and identity-aware audit trails – summarized as Agent Identity = Actor + Authority + Scope + Context + Lifetime.
Introduction
AI agents are no longer just answering questions. They are booking meetings, writing code, querying databases, moving money, and calling other agents to get work done.
Gartner projects that by 2028, 33% of enterprise software applications will have agentic AI built in. That’s up from less than 1% in 2024. Gartner also expects at least 15% of day-to-day work decisions to be made autonomously through agentic AI by the same year. This kind of shift is exactly what SmartDev’s AI Powered Software Development practice was built around: agents are moving from novelty to infrastructure fast, and most security teams have not caught up.
That shift changes how we need to think about security. Once an agent gains access to enterprise systems, granting that access is no longer the hard part. The hard part is knowing, with confidence, who – or what – is behind every action it takes.
This leads to a question most organizations haven’t answered yet: Can you prove which agent acted, on whose behalf, and with what authority?
If the honest answer is “not really,” you don’t have an access problem. You have an identity problem. And the consequences already show up in the numbers. Gartner forecasts that 25% of enterprise generative AI applications will suffer at least five minor security incidents a year by 2028, up from 9% in 2025.
Why Traditional Access Control Is Not Enough for AI Agents
Most identity and access management (IAM) systems were built for two kinds of actors: humans logging in with credentials, and applications authenticating with static service accounts. Both models assume a predictable actor behind every request. That actor authenticates, receives a token, and stays accountable when something goes wrong.
AI agents break that assumption. An agent can:
- Act autonomously, without a human clicking “approve” at every step
- Execute dozens of API calls and touch hundreds of records within a single task. CockroachDB’s engineering team describes production agents that can make 40 API calls in 30 seconds and access 500 customer records to complete one job
- Call other agents, which may call still more agents, to complete a workflow – often with no human approving each hop
Traditional IAM answers one question: “Can this credential do X?” It was never built to answer a harder one: “Which autonomous process, acting on whose behalf, just did X – and should it have been allowed to?”
The scale of the problem is easy to underestimate. Non-human identities already outnumber human identities inside the average enterprise. This category includes service accounts, API keys, OAuth tokens, and now AI agents. Every serious 2026 estimate puts that ratio in the tens or hundreds to one.
Palo Alto Networks’ 2026 Identity Security Landscape report surveyed nearly 3,000 security decision-makers. It puts the ratio at 109 machine identities for every human one, up from 82-to-1 just a year earlier. AI agents alone now account for roughly 79 of those 109 machine identities. KPMG’s Cybersecurity Considerations 2026 report lands on a similar order of magnitude, at roughly 80 machine identities per human.
The exact multiple varies by source. The direction does not. Enterprises are adding agents far faster than they are building the identity governance to track them.
Giving an agent permission to access a system only tells you what’s technically possible. It says nothing about accountability. Permission and accountability are not the same thing. Treating them as interchangeable is where most agent security gaps begin – a gap that shows up just as often in regulated workflows, which is why SmartDev’s write-up on when AI gets compliance wrong covers a closely related failure mode.
Access vs. Identity: The Missing Distinction
Three concepts get collapsed into one far too often. It helps to separate them clearly:
| Concept | Core question | What it tells you |
| Access | What can the agent do? | Which systems, actions, and data are reachable |
| Identity | Which agent is doing it? | Whether this is a specific, distinguishable actor |
| Authority | Whose permission is it using? | Whether it acts for a user, a team, another agent, or itself |
Many current setups let agents share API keys or ride on generic service accounts. That configuration provides access – the agent can call whatever systems it needs. But it hides identity and authority.
CockroachDB’s security team makes this concrete. When ten agents run under the same service account, the audit log shows only what the account did. It cannot show which specific agent touched which record, in what order, or why.
This isn’t a hypothetical edge case. Cloud Security Alliance’s Non-Human Identity working group estimates the median machine-to-human identity ratio at roughly 45-to-1 across industries. Just over half of the CISOs it surveyed said they could confidently enumerate fewer than half of the machine identities actually running in their environment. You cannot govern authority for an actor you cannot even count.
Access answers “what’s possible.” Identity and authority answer “who is responsible.” Enterprises have gotten good at the first question. Most have barely started on the second.
Where Agent Identity Breaks in Practice
The gap between access and identity isn’t theoretical. It shows up in predictable, recurring failure points.
- Multiple agents sharing one credential
A single API key or service account gets used across several agents. No individual agent stands out in logs or policy. CockroachDB documents a real case: a customer support agent ran for three months under a service account with read access to the entire customer database. A security review finally caught it. But the audit trail couldn’t reconstruct which records the agent had actually touched, or whether any response had ever surfaced data outside a given support request.
- Long-lived API keys and exposed secrets
Static credentials sit in config files, environment variables, and code repositories without ever expiring. This isn’t a marginal issue. GitGuardian’s State of Secrets Sprawl 2026 report found 28.65 million hardcoded secrets exposed on public GitHub in 2025 alone – a 34% year-over-year jump. AI-related secret leaks specifically surged 81% as AI coding assistants spread. The same research found that internal, “private” repositories are actually six times more likely to contain hardcoded secrets than public ones. The exposure many teams assume is contained often runs larger behind the firewall.
- Agents inheriting excessive permissions
Teams provision agents with broad, human-level access “just in case” during development. Nobody narrows those permissions before the agent reaches production.
- Agent-to-agent delegation without clear boundaries
One agent invokes another, which invokes a third. No enforced limit governs what authority actually passes down the chain. When an orchestrator with broad permissions hands work to a narrower sub-agent without explicitly scoping that handoff, you get a “confused deputy.” SC World traces this class of privilege-escalation problem to computer scientist Norman Hardy’s original description in 1988, and it maps directly onto how multi-agent systems delegate work today.
A related risk sits inside the agent’s own context window. Credentials passed directly into a model’s prompt can leak through tool outputs, verbose logs, or a prompt injection attack that tricks the agent into revealing them. OWASP’s Top 10 for Large Language Model Applications catalogs this risk formally as LLM01.
- Audit logs showing accounts, but not the full chain of action
Logs record “service account X called API Y.” They can’t reconstruct which agent session initiated the task, which agent it delegated to, under which user’s authority, or which records it ultimately touched. This gap has real consequences, not just operational inconvenience. Verizon’s Data Breach Investigations Report found that 31% of identity-related breaches in its 2026 cohort traced back to a non-human credential nobody on the current team could even identify as their own. It’s the same underlying gap SmartDev explores in how NORA makes every AI decision regulatorily defensible – an audit log is only as useful as its ability to attribute an action to a specific, identifiable actor.
Each of these failure points looks like a minor operational shortcut on its own. Together, they mean an incident response team may not be able to answer the most basic question when something goes wrong: which agent did this, and why was it allowed to?
What a Secure AI Agent Identity Model Should Look Like
A mature identity model treats each agent as a distinct, accountable actor. It does not treat the agent as an extension of a shared credential. That model needs six things:
- Unique identity for each agent
Every agent instance is individually identifiable, not indistinguishable from its peers. CockroachDB’s engineering guidance describes this as a per-session, per-agent identity issued at instantiation and expired when the session ends, rather than a static, standing credential.
- Short-lived, scoped credentials
A token service issues access at task time. Each credential stays narrow enough that a leak has a contained blast radius, and expires automatically so rotation doesn’t require manual coordination.
- Least-privilege access
Agents receive only the permissions their current task requires – read access where writes aren’t needed, scoped to specific tables or data, with no runtime privilege elevation available.
- Clear delegation chains
When one agent acts on behalf of another (or on behalf of a user), that relationship stays explicit and gets recorded: who delegated to whom, what permissions were active at that moment, and whether the sub-agent’s permissions were narrowed rather than simply inherited.
- External policy enforcement
A system outside the agent itself makes and enforces authorization decisions – for example, at the database or API-gateway layer. This stops the agent from reasoning its way into more authority than it was granted, even if it generates a broader request than its task requires.
- Identity-aware audit trails
Logs capture which agent session acted, which user instantiated it, which model version ran it, what delegation chain it followed, which records it accessed, and at what cost. This produces a structured execution record, not a simple access log – the same principle behind compliance audit trails that make every AI-assisted decision regulatorily defensible.
These six pieces combine into one working principle:
Agent Identity = Actor + Authority + Scope + Context + Lifetime
- Actor: which specific agent.
- Authority: on whose behalf it’s acting.
- Scope: what it’s allowed to touch.
- Context: the task and conditions under which it’s acting.
- Lifetime: how long that authority remains valid. Miss any one of these, and you have access without accountability.
FAQ
What is AI agent identity, exactly?
AI agent identity is a unique, individually traceable identity assigned to a specific agent session – distinct from the shared service accounts or static API keys many teams rely on today. It lets you tie every action back to a specific actor, not just a generic credential.
Isn’t scoping permissions the same thing as giving an agent identity?
No. Scoping permissions defines what an agent is allowed to do – that’s access. Identity defines which specific agent did something and under whose authority. A narrowly scoped shared credential still can’t tell you which of ten agents using it actually took a given action.
What’s the biggest risk of letting multiple agents share one credential?
Loss of attribution. When agents share a credential, the audit log shows what the account did but not which agent did it, in what order, or why. That makes incident investigation, compliance reporting, and root-cause analysis extremely difficult – a problem covered in more depth in SmartDev’s guide to AI compliance audit trails.
How does agent-to-agent delegation increase risk?
When an orchestrator agent with broad permissions delegates work to a sub-agent without narrowing those permissions, the sub-agent can end up exercising authority it was never meant to have – a classic “confused deputy” problem. Delegation chains need explicit scoping at every hop, not inherited access by default.
Where should organizations start if they want to fix this?
Start by inventorying which agents currently share credentials, then move toward short-lived, scoped tokens issued per session, enforced outside the agent itself (at the database or API-gateway layer). SmartDev’s AI Consulting Services team works with enterprises on exactly this kind of identity and governance assessment before agents reach production.
Conclusion – From Access Control to Agent Governance
AI agents are not applications that can safely share a password. They are not humans who can be trusted to self-limit their own behavior. They are autonomous digital actors, operating at a scale and speed that keeps accelerating. Gartner expects agentic AI to reshape a third of enterprise software within a few years. Enterprises need to govern agents accordingly.
That means shifting the central question. “What can this agent access?” is no longer enough. The question that actually matters is: Who is acting, under whose authority, and can we prove it?
An AI agent with broad access but no clear identity isn’t a secure system with a minor gap. It’s an autonomous system operating with borrowed keys. And borrowed keys, by definition, can’t tell you who’s really at the door.
Building or scaling AI agents in your organization? SmartDev helps enterprises design secure, production-ready agentic AI systems – from identity and access architecture to full-stack agent development through AI Development Services and Generative AI Development Services. Talk to SmartDev’s team to assess your AI agent identity posture before your next deployment.
