The agent your team just shipped to external users has the ability to read customer records, execute transactions, and call external APIs. In most deployments today, it’s running under a shared service account (the same non-human identity used by multiple applications or agents) with permissions far broader than any individual task requires, no formal identity of its own, and no audit trail that can answer what it actually accessed or why.
Your security team spent years building access controls designed for a different actor. Roles, permission scopes, MFA, and audit logs built to track what humans do and what they touched. None of it was designed for a software process that might make 40 API calls in 30 seconds, access 500 customer records to complete a single task, and delegate work to other agents without a human approving each step.
This is the gap at many enterprises shipping agentic systems, and it’s one of the fastest paths from a working deployment to a compliance failure. Identity is becoming a foundational requirement for securing production AI agents. As organizations move agents into customer-facing and business-critical workflows, weak identity controls increase the risk of unauthorized data access, failed audits, operational disruption, and loss of customer trust. Solving identity early reduces both technical risk and the cost of operating AI systems at scale.
Why doesn't traditional IAM work for AI agents?
Traditional identity and access management (IAM) is built around one foundational assumption: Humans are the actors.
A human authenticates, receives a token, and is accountable when something goes wrong. The entire IAM system including the roles, permission scopes, audit logs, and compliance reports are all designed to answer two questions: “What can this human do, and what did this human do?”
AI agents break every part of that model.
An agent isn't a human. It's an autonomous software process that takes actions on behalf of a human, but with a scope and speed no human would reach. It might call 40 APIs in 30 seconds, and access 500 customer records to complete a single task. It might delegate part of its work to another agent, which delegates to another, creating a chain of actions that no human directly approves at each step.
When that agent has a production incident, and most non-trivial deployments will, investigating what happened becomes far more difficult than it would in a traditional application. Most deployments simply lack the identity model needed to reconstruct an agent's actions afterward.
When an agent runs under a shared service account with no formal identity, the audit trail that answers "what happened and why" breaks down. T The service account only shows what it accessed and not which agent acted, which records it touched, in what order, or why it made those requests.
That's not a theoretical gap. That's a compliance failure and a security incident packaged together.
Related
Webinar: “The Future of Databases for AI Agents” – Cockroach Labs CEO Spencer Kimball and Technical Evangelist Rob Reid discuss why AI agents represent a fundamentally new class of database user, one that removes the natural traffic ceiling set by human actors, and what that shift demands from identity, governance, and infrastructure.
How does AI agent identity break in production?
There are four specific failure patterns I see consistently when I talk to teams preparing agents for external production. Each one sounds manageable in isolation, but together they're how a well-intentioned deployment becomes a serious problem.
1 of 4: Why is a shared service account dangerous for agents?
The easiest path is giving the agent a service account. It works immediately, the agent can do what it needs to do, and the shipping deadline is met.
The problem is that service accounts are designed to be shared, static, and broadly privileged. When you have ten agents running under the same service account, you can't tell from your audit logs which agent touched which data. When the account's credentials need to be rotated, you have to coordinate across every agent that uses them. And when the account has read access to your entire customer database because someone decided it was simpler than scoping individual permissions, you've created an identity with a blast radius far beyond any individual user.
Most teams know this is wrong and do it anyway, because the alternative requires architectural work they haven't scoped yet. Earlier this year, a team I spoke with found this exact problem during a routine security review:
Their customer support agent had been running for three months under a service account with read access to their entire customer database.
The account had been configured that way in development, for convenience, and nobody had narrowed the permissions before go-live.
The security team identified the exposure.
But the audit trail could not answer what the agent had actually accessed during those three months: which records, in what context, or whether any response had ever surfaced data outside what a given support request required. The logs told them what the service account had done, but they had no way to know what the agent had done.
2 of 4: Why can't agents use credentials passed through the context window?
Some teams try to solve this by passing credentials dynamically into the agent's session, so the agent gets what it needs for the current task.
The problem is that credentials passed into a context window are exposed to the model. The model can include them in tool outputs, intermediate reasoning steps, or verbose logging. More concerning, a prompt injection attack, where malicious content in the environment includes hidden instructions, can exfiltrate credentials through the agent's own outputs. This attack vector is documented as LLM01 in the OWASP Top 10 for LLM Applications (owasp.org/www-project-top-10-for-large-language-model-applications).
You can't store secrets in a context window and expect them to stay secret. That's not a configuration problem, it's structural. The fix is short-lived, scoped credentials that are issued at task time by a token service, and never stored in the context at all. The credential is held by the tool-execution layer between the model and the API, so the model triggers the call without the secret ever entering its context. The agent requests what it needs, uses it, and the credential expires.
3 of 4: How does delegation create a privilege escalation risk?
When an orchestrating agent delegates a task to a specialized sub-agent, whose identity governs what the sub-agent can do?
If the orchestrator has broad permissions and the sub-agent inherits them, you've created a confused deputy, a security problem formally described by Norman Hardy in 1988 and a standard delegation exploit in any system where authority is not explicitly bounded at each handoff. A lower-trust component can now exercise higher-trust privileges simply by being invoked by a higher-trust one.
In a multi-agent system with three or four hops of delegation, tracing what permissions were active at each step, and proving no step exceeded its authorized scope, becomes nearly impossible without intentional architecture from the start.
4 of 4: Why don't standard audit logs work for agents?
When a traditional system logs "user_id 42891 executed SELECT from customers WHERE region = US-West," that's useful. You know who, what, and when.
When an agent takes an action, the useful audit trail looks completely different. You need to know:
which agent session
instantiated by which user
running which model version
acting on which tool call
based on what input
under what delegation chain
accessed which records
at what cost
producing what output
That's not a traditional audit log, it's a structured execution record. Many teams stop at logging database activity, when what they actually need is a complete record of the agent's identity, context, permissions, and actions.
Related
The State of AI Infrastructure 2026 — 83% of engineering leaders expect AI-driven demand to push their infrastructure to failure within two years. This report quantifies the broader infrastructure stress that makes identity governance urgent, not optional.
What does production-grade AI agent identity require?
The teams shipping agents responsibly to external users have built something that looks less like traditional IAM and more like a combination of dynamic credential management, database-layer enforcement, and structured audit artifacts.
Here’s what each layer requires in practice:
How should each AI agent session be identified?
Not as a shared service account or a static credential. Instead, each agent session should be identified as a per-session, per-agent identity issued at instantiation, scoped to exactly what that agent needs to complete its current task, and expired when the session ends.
This requires a token service that issues short-lived, scoped credentials based on the task type and user context:
The agent requests credentials when it needs them.
The credentials are narrow enough that if they leak, the blast radius is contained.
The credentials expire automatically, so rotation isn't a coordination problem.
This solves the service account problem and the context window problem at the same time. The agent never holds credentials long-term, and because each credential is scoped narrowly to a single task, any breach is contained. There's no standing access to exploit.
Where is AI agent identity actually enforced?
Identity enforcement in an agent system runs across three layers, and none of them is sufficient on its own.
The token service handles the credential surface. Short-lived, scoped credentials issued per session prevent an agent from accumulating standing access over time. This is an infrastructure concern that operates above the database layer, not a database feature.
Agent roles define what operations are permitted. Applying the principle of least privilege means each role is scoped to the minimum operations the current task requires.
Least privilege does more than reduce security exposure. It limits the operational impact of mistakes, simplifies compliance reviews, and helps organizations deploy AI agents with greater confidence because every agent receives only the access required for the work it has been assigned.
In practice, that means every agent role should be designed with guardrails like these:
read access where writes are not needed
scoped to specific tables or schemas
no privilege elevation available at runtime
sub-agents should not inherit broader permissions than the task they were delegated to perform.
The database enforces what data the role can reach. Even if an agent generates a broader query than its task requires, RBAC at the database layer limits what the execution returns. Row-level security extends this to the record level. The detailed architecture for row-level security and schema isolation in multi-tenant agent systems will be covered later in this series.
Together these layers cover the whole surface described at the beginning of this article. The token service bounds which external APIs and transactions the agent can reach, the roles bound what it can do, and the database bounds which records it can touch. The audit artifact then records all three, so the API calls and transactions are accounted for, not only the data access.
Related
What Breaks When Agentic AI Reaches Production? – Learn the broader infrastructure challenges that determine whether agentic AI ships to external production, with sections on state management, thundering herd, blast radius, and observability.
How should permissions work across a delegation chain?
Every time an orchestrating agent passes work to a sub-agent, that delegation should be recorded explicitly:
who delegated to whom
what permissions were active at delegation time
whether the sub-agent received narrowed or preserved permissions
The principle is simple. Each hop in a delegation chain should narrow permissions, never preserve them. An orchestrator with broad access should delegate tasks with only the permissions that specific task requires. If your architecture doesn't enforce this explicitly, you're one confused deputy away from a privilege escalation incident that your audit logs won't be able to explain.
How does AI agent identity enable audit trails?
An audit log tells you what happened. What agent governance requires is the ability to answer:
which session
under which delegation chain
accessed which records
under whose authority
That answer is only possible because of identity. Without per-session identity, there is no session to attribute. Without recorded delegation chains, there is no authority to verify. Without scoped credentials tied to a specific task, there is no scope to confirm that the agent stayed within.
Identity is what makes audit traceable. How to build the full audit record, including the two-layer tamper-evidence design and the schema for immutable agent execution logs, will be covered in an upcoming article in this series. More broadly, identity provides the accountability layer that production AI systems require: When every action can be traced to a specific agent session, organizations can investigate incidents faster, demonstrate regulatory compliance, and build greater confidence in autonomous systems operating at scale.
Related
The Architect's Playbook for Building AI-Ready Systems — Practical architectures and design patterns for building AI-ready systems on distributed SQL, including IAM, metadata management, and vector search patterns.
What should you confirm before deploying AI agents?
Before deploying AI agents, confirm that your identity architecture, credential management, authorization model, and audit capabilities are production-ready. Retrofitting identity governance into a live system, while it's handling real user requests, is significantly more painful than building it in from the start.
These are not optional architecture concerns. They are the questions security engineers and platform architects must answer before an agent system can be deployed to external users with confidence.
Identity failures are also how agents break in production. An agent running under a shared service account with no audit trail does not fail dramatically. Instead, it fails quietly: wrong data returned, scope exceeded, or a compliance gap that goes undetected until a review surfaces it. Other articles in this series focus on failures that immediately disrupt live systems. This article focuses on a different kind of failure: one that often doesn't appear until an auditor asks, "Who accessed this data, and why?"
Agents are going to take actions in your name. The question is whether you build the identity and governance architecture before or after something goes wrong.
Props: Thank you to Cockroach Labs' David Bressler for technical review of this article.
Learn how CockroachDB helps organizations build secure, auditable AI agent systems with database-level authorization and row-level security. Speak with an expert.
AI Scale Starts with the Right Data Architecture
Discover why legacy databases fail under AI workloads — and how modern data infrastructure enables resilience, elasticity, and always-on performance.
Quentin Packard is VP of Americas Sales at Cockroach Labs, where he works with engineering and infrastructure leaders building production-grade agentic AI systems. He previously helped build Splunk’s observability business and has worked across infrastructure automation, secrets management, and real-time data governance at HashiCorp and early stage startups. His writing draws on direct conversations with enterprise teams navigating AI and data architecture in production.
