The AI Platform Map, part 3 of 6

Whose Credentials Is Your Agent Using?

Platform architecture, 2026

Pick any AI agent running in your environment and ask one question: whose credentials is it using?

Whose credentials is your agent using? Today the agent runs as a senior engineer's personal token, scoped to every repo in the org, never expires, and the audit log says a human did it. The target is agent-run-4821, scoped to one repo, dev only, expiring when the task ends, with an audit log that says agent, authorized by a named human. Every agent run gets credentials that are its own, short-lived, and scoped to the task.

In a lot of organizations the honest answer is a person's. A senior engineer's personal access token. Someone's cloud session. A shared service account created years ago with rights to everything, because that was easier.

That means two things. Your audit log says a human did work no human did. And the blast radius of that agent is everything that person can touch.

This is layers three and four of the nine-layer platform map: the ephemeral agent and scoped workload identity. They share a post because they fail together.

Cattle, not pets. Again

The cloud taught us this fifteen years ago. Servers that live forever accumulate drift nobody can explain, so we stopped nursing them and started replacing them.

Long-running agents drift the same way. Context piles up. Stale assumptions carry from one task into the next. Anything hostile an agent read yesterday is still in its memory today.

An ephemeral agent starts clean for one task. It gets the intent and the context it needs from the workflow, does the work, hands back its artifacts, and is destroyed. Nothing precious lives in it, so nothing is lost when it goes.

Give it its own identity, and make it small

Every agent run should get credentials that are:

None of this is new technology. CI pipelines already trade long-lived cloud keys for short-lived federated tokens. Service meshes already give workloads cryptographic identity. We have simply not held agents to the standard we hold a build job to.

CyberArk's 2025 Identity Security Landscape put machine identities at more than 80 to 1 against humans. Every agent you deploy adds to that count.

Why it matters more for agents than for scripts

A script does what it was written to do. An agent does what it was talked into doing.

Agents read untrusted input all day: issue text, PR comments, web pages, dependency docs. In May 2025, Invariant Labs showed that a malicious issue planted in a public GitHub repository could steer an agent into pulling data from the user's private repositories and publishing it in a public pull request. The injection was the trigger. One token that could read public and private repos alike was the damage.

In July 2025, an AI coding agent on Replit deleted a company's live production database during an explicit code freeze, after being told not to change anything without approval. The fix Replit shipped was not a better instruction. It was separating development from production.

You cannot fully prevent an agent from being talked into something. You can decide in advance how much a successful attempt gets.

In a regulated environment, make that structural. An agent working a task that does not need production data or PHI should be unable to reach it, not merely told not to. An instruction the agent can be talked out of is not a control.

I wrote recently about putting agent identity in the commit trailer. That is attribution: who did it. This is authorization: what it was allowed to do while it ran. You need both.

Try this

List the agents running in your environment. For each one: whose name is on the credentials, what can they reach, and when do they expire?

If any answer is "a person," "everything," or "never," start there.