Your identity stack was built for two kinds of actor. Agents are a third.
An engineer ships an agent to production this week. It needs to call an internal API, so it uses the key already sitting in the engineer’s environment. The agent runs. It also now holds every permission that engineer holds.
That is the default state of most agent deployments today. The agent has no identity of its own, so it borrows one. It works on day one, which is exactly why the problem ships unnoticed. A non-human process is now carrying a human’s full access, and nothing in your audit log can tell the two apart.
This is not a configuration mistake. It is a structural gap. Identity and access management assumes an actor is one of two things: a person, or a long-lived service account with a static permission set. Both are stable. Both do roughly the same thing every day. Your controls, your audit model, and your provisioning flows are all built on that stability.
Agents are neither. They act on behalf of people, so they are not service accounts. They spin up and tear down on their own schedule, so they are not people. They sit in the gap your IAM stack has no category for, and the gap is where the credential gets borrowed.
Why you cannot just patch this
The reason existing IAM cannot simply absorb agents is non-determinism. A service account calls the same endpoints at the same cadence every time. Give two agents the same permissions and the same goal, and they can take different actions, because each one picks its tool chain at runtime based on its prompt, its context, and the output of whatever called it.
The set of actions an agent will actually take is not knowable when you grant its permissions. That turns design-time least privilege into a design-time answer to a runtime problem. You are deciding in advance what an actor may do, when the actor decides what to do only once it is running.
That single fact is the spine of this series. It is why borrowed credentials fail, why scope has to be narrow, why a delegation chain has to stay inspectable, and why authorization cannot be a one-time grant. The question that matters is not “who is this actor.” It is “what is this actor authorized to do right now, for this task.”
If you do nothing else this week
Before the series goes deep, three checks you can run today against any agent already in production.
Look for human API keys being used by non-human processes. If an agent authenticates as the person who deployed it, you have privilege inheritance in production right now.
Check whether your audit logs can separate agent actions from human actions. If they cannot, your incident response and your compliance story both break at the same moment.
Confirm you can shut one agent off without rotating a human’s credential or breaking three other things. If revocation means collateral damage, you do not have an off switch. You have a hostage situation.
None of these is the full fix. They are the floor. Finding where they fail tells you where to start.
What solving this actually looks like
The rest of the series builds the answer in layers, each one resting on the one below it.
It starts with giving the agent a stable, verifiable runtime principal you can authorize against, attribute actions to, and revoke on its own. Then it has to survive contact with reality: agents call tools, tools call other agents, and identity has to stay intact across every hop so you can still answer who originally asked and which actor is making this specific call. The credential the agent uses to make those calls has to stay out of the model itself, where a single prompt injection could read it and send it anywhere. Above that sits the question of where the rules live, and who decides what an agent may do the moment it acts somewhere its own platform does not reach. Underneath all of it runs the lifecycle: an identity you provision, scope, revoke, and re-evaluate while the agent runs, not a record you write once and forget.
Identity is the foundation the rest depends on. Authorization, governance, and observability all sit on top of it. Get identity wrong and nothing above it holds.
Where DataRobot fits
The agent platform from DataRobot treats agent identity as first-class infrastructure, not an afterthought bolted on at deploy time. The direction is the one this series argues for: give each agent its own scoped identity, keep the delegation chain intact and auditable when agents call tools and other agents, govern that identity in one control plane, and federate trust outward to the identity providers and workload identity systems an enterprise already runs.
What is coming
Part one takes apart the borrowed credential. Why inheriting a human’s key is privilege escalation by default, and why the fix is authority decided at runtime, not a passport stamped once at the border.
Part two defines what a first-class agent identity actually is: a distinct principal, scoped permissions, a clear owner, and a kill switch. It also shows how you make that principal trustworthy through attestation, then engages the question a good engineer is already asking. Is this just workload identity? It depends on three invariants, and where they break is where most real fleets live.
Part three follows identity through a delegation chain. RFC 8693 token exchange, the confused deputy you create when you flatten that chain, and the two protocol surfaces where it is preserved or destroyed in practice: MCP and A2A.
Part four keeps the secret out of the model. An agent’s context is attackable, so a prompt injection can read anything in it. That is why the raw credential should never reach the agent’s process. A broker holds it and injects auth at the boundary, and the agent only ever gets a scoped capability.
Part five is about where authorization and governance sit. Govern natively, federate outward, size controls to blast radius, and the frontier nobody has cleanly solved: what happens when an agent acts across trust domains its issuing platform does not control.
Part six treats identity as a lifecycle. Just-in-time, task-scoped credentials, no standing privilege, and continuous runtime authorization. It closes the loop back to non-determinism and leaves you with a six-question audit to run against one real agent.
Part one publishes next. If you want a head start, go find one agent in your environment right now and check whose credentials it is using. That answer is where the series begins.
The post Your identity stack was built for two kinds of actor. Agents are a third. appeared first on DataRobot.