Agent Identity and Authentication: The Missing Infrastructure for Regulated AI

AI agents have started doing real work inside enterprises: pulling records, calling internal APIs, moving data between systems, and in some cases executing transactions. The awkward truth underneath that shift is that most of these agents do not have an identity of their own. They act by borrowing a human's login or a static service-account secret, and neither was designed for a piece of software that reasons, decides, and acts on someone else's behalf. In an ordinary consumer app this is sloppy. In a regulated industry, where every action must be attributable, least-privilege, and auditable, it is a structural gap. This is why agent identity is its own problem, what regulated AI needs from it, and why it is the infrastructure layer the enterprise AI wave is quietly missing.

Enterprises have spent two decades building identity around two assumptions: an actor is either a person or a service. AI agents violate both. An agent is not a person, so giving it a human's credentials means it inherits that person's full standing access and every action it takes is logged as if the human did it, which destroys attribution the moment anything goes wrong. An agent is also not a traditional service, because a service account is a static, long-lived secret that knows nothing about which user it is currently acting for or with what consent.

The clearest way to see the gap is to line up the three models side by side.

The pattern is that a borrowed identity is always either too much or too little: too much standing power, too little context about who authorized this specific action. Industry writeups of the problem, such as Atlan's explainer on what AI agent identity is and what IAM does not cover, land on the same conclusion, that agents are a third identity class that existing access management was never built to hold.

There is a specific failure mode that makes this urgent rather than theoretical: the confused deputy. When an agent holds broad credentials and takes instructions from multiple sources, it can be maneuvered into using its own privileges to do something the requester was never entitled to do. A support agent with read access to every customer record, prompted cleverly, becomes a data-exfiltration path. The agent is not malicious; it is confused about whose authority it is exercising.

In consumer software that is a bug to patch. In financial services, healthcare, or any field with real recordkeeping duties, it is a compliance event. Regulated firms have to answer, on demand, who did what, under whose authority, and with what data, and they have to enforce least privilege and produce an audit trail that a regulator will accept. An agent acting under a shared service account or a borrowed human login cannot satisfy any of those requirements cleanly. This is why the institutions with the most to gain from AI agents, the ones sitting on valuable regulated workflows, are also the ones that cannot deploy them at scale until the identity question is answered. It is the same tension that runs through what vertical AI is and why it beats horizontal AI in the enterprise: the value is in the regulated, domain-specific workflow, and so is the hard part.

Solving this means giving an agent a real identity with four properties that a borrowed credential lacks.

A distinct identity class. The agent is registered as its own kind of principal, separate from the humans it serves and the services it is often confused with. This is what makes the inventory question answerable: what agents exist, who owns each one, and what is each permitted to do.

A verifiable delegation chain. When an agent acts for a user, the authorization has to record that the user consented, to this agent, for this scope, so the action carries provenance back to a human decision. Emerging architectures describe several shapes of this, from an agent acting as the user with explicit consent, to an agent holding its own standing identity, to one agent delegating narrowly to another.

Short-lived, scoped credentials. Instead of a static secret, the agent receives narrow, time-bound tokens for the specific task, so a leaked credential expires quickly and a compromised agent cannot roam. Token-based approaches building on OAuth, workload identity, and certificate-based schemes are the common building blocks here.

Lifecycle management and revocation. An agent identity has to be created, owned, monitored, and revocable on its own, without disabling the human or breaking every other agent. The architectural test, in practice, is whether an agent's identity is tied into the enterprise's existing identity governance so it can be audited like any other privileged actor.

No single standard has won. The most authoritative signal that this is becoming real infrastructure is that the National Institute of Standards and Technology has opened a concept project on the problem, described in its NIST concept paper on accelerating the adoption of software and AI agent identity and authorization, which examines how zero-trust, access-control, and federated-identity frameworks apply to agentic systems. A useful plain-language read of what that initiative means for enterprise security is WorkOS's overview of the NIST AI agent standards initiative.

For now, most enterprises assemble their own approach from tokens with custom claims, mutual-TLS certificates from an internal certificate authority, and cloud-vendor managed identities. That fragmentation is exactly what tells you a category is early. The primitives exist; the accepted, regulated-grade way to combine them does not yet, and that space is where durable companies get built.

At gAI Ventures we co-found vertical AI companies in financial services, enterprise productivity, and commerce, and this is precisely the kind of unglamorous, load-bearing problem that decides whether a regulated AI product can ship at all. An agent that cannot prove who authorized its actions is an agent a bank's compliance team will not approve. So for a founder building in a regulated vertical, agent identity is not a feature to bolt on later; it is part of the product's license to operate, and getting it right early is a genuine source of trust and differentiation. That conviction, that the defensible AI companies are the ones solving the hard domain-specific problems rather than the generic ones, is the throughline of the gAI Ventures manifesto and shows up across our vertical AI investment theses.

It also connects to a broader point about where regulated AI creates value. A lending product that uses AI to underwrite, like the approach described in how AI credit intelligence finds the right borrowers for small-business lenders, only earns trust if every automated action is attributable and auditable. Identity is the substrate that makes the rest of the product credible. The companies we build alongside expert operators, visible across the gAI Ventures portfolio, live in exactly these regulated workflows, and the team behind that work is on the gAI Ventures team page. If you are an operator wrestling with this problem in your sector, it is the sort of thing worth building properly from day one, and a good place to start reading is the gAI Ventures blog and the broader case at gAI Ventures.