On July 16, Hugging Face published a postmortem on an intrusion into its production infrastructure. The interesting part isn't that they got hit. It's how it moved:

The intrusion started where AI platforms are uniquely exposed: the data-processing pipeline. A malicious dataset abused two code-execution paths in our dataset processing... From there, the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.

Code execution on one worker. Then credentials. Then everything else. The campaign was run by an autonomous agent framework executing "many thousands of individual actions across a swarm of short-lived sandboxes" — over 17,000 recorded events, across a weekend, while nobody was watching.

That shape should bother you, because the first step is the hard one and the rest is just harvest. What made the blast radius large wasn't the exploit. It was that once the attacker was on a box, the credentials sitting there were good for more than that box.

Now go look at your own setup. If you're like most small teams running agents in production, there is a .env file somewhere with an API key in it that belongs to a human, or a service account named something like automation-prod that has write access to seven systems because that was faster than making seven accounts. Every agent you've deployed uses it.

This post is about fixing that specifically — not about security posture in the abstract.

What agent identity actually means

Agent identity means each AI agent has its own credential, its own permission scope, and its own audit trail — rather than borrowing a human's API key or sharing a blanket service account with every other agent you run.

The security world files this under non-human identity (NHI). A non-human identity is any principal that authenticates without a person present: a service account, a CI runner, a machine token, a bot. Agents are NHIs, but they're an unusually badly behaved kind. A CI runner does the same six things forever. An agent acquires permissions at runtime, decides what to call based on text it just read, spawns sub-agents, and chains actions across systems that were never designed to be chained.

That's the difference that matters. A leaked CI token gets you what CI could do. A leaked agent token gets you what the agent could have talked itself into doing.

The numbers say almost nobody has this handled

I'm quoting these because they're the rare case where survey data matches what we actually see in client environments.

The Cloud Security Alliance, in a study with Aembit released March 24, 2026 (228 IT and security professionals, surveyed January 2026):

• 68% cannot clearly distinguish AI agent activity from human activity in their logs.
• 85% are running AI agents in production.
• 33% don't know how often their agent credentials are rotated.
• 22% say access frameworks are applied "very consistently" to agents.

A follow-up CSA survey in April 2026 found 82% of enterprises have AI agents in their environments they don't know about. And a January CSA study with Oasis Security found 79% of IT professionals feel ill-equipped to prevent attacks that come through non-human identities.

Read the first one again: 68% can't tell an agent's actions from a person's. That's not a security gap, it's a forensics gap. It means that if something goes wrong, you cannot answer the question "what did this thing touch?" — which is the only question that matters in the first hour of an incident. Hugging Face could answer it. They ran analysis agents over the full attacker action log and reconstructed the timeline in hours. Most teams we walk into could not produce that log at all.

Five controls, in the order they pay off

You do not need an identity platform to fix this. At 3–30 people you need five things, and they're roughly ordered by payoff-per-hour.

1. One identity per agent. No sharing, ever.

Every agent gets its own credential. Not one per team, not one per environment — one per agent. If you run a support triage agent, a repo-monitoring agent, and a nightly reporting agent, that's three credentials.

This is the control that does the most work, because it's what converts "we were breached" into "the reporting agent was breached." Scope is what makes an incident survivable.

The immediate objection is that this is three times the management overhead. It isn't, if you provision through code. Terraform, a shell script, whatever — the point is that creating an agent identity should be a file change, not a click-path through a console someone has to remember.

2. Scope the permissions to what the agent actually uses — not what it might

Start from zero and add. Watch what the agent calls over a week in staging, grant exactly that, then let it fail loudly in production when it reaches for something new. A loud failure you investigate is a better outcome than a silent success you never audited.

This is where most teams quietly cheat. Granting broad access takes thirty seconds and granting narrow access takes an afternoon of figuring out which permissions the SDK actually needs. Do the afternoon. Cloudflare shipped resource-scoped API token permissions to GA in April 2026 alongside scannable tokens and better OAuth visibility, and most major providers have shipped something equivalent in the last two quarters. The tooling caught up. The habits haven't.

Pay particular attention to write and delete scopes. An agent that reads your CRM and drafts follow-ups does not need permission to delete contacts, and the day it gets prompt-injected you will be extremely glad it couldn't.

3. Short TTLs, so a stolen credential expires on its own

A short TTL means the credential is only valid for minutes or hours, so a stolen token stops working before an attacker finishes using it. This is the single highest-leverage change, because it works even when everything else fails — including your detection.

The Hugging Face attacker moved laterally over a weekend. Long-lived credentials are what make a weekend enough time.

For agent-to-server calls where no human is involved, the canonical pattern is the OAuth 2.1 client credentials grant: the agent authenticates with its own registered credentials and receives a short-lived, scoped access token. There's no user to delegate from, so don't invent one. The MCP specification requires OAuth 2.1 for remote server authentication, which means if you're running remote MCP servers you already have the primitive available — you may just not be using its scoping properly. (If you run MCP servers, also read our stateless migration checklist — the July 28 spec revision changes auth handling alongside everything else.)

Where a human is delegating to the agent, use token exchange and keep the human as the delegating subject — Microsoft's Entra Agent ID on-behalf-of flow is the reference implementation, and AWS and Google shipped comparable patterns in the same window. The property you want: the log shows both the agent and the person it acted for.

If you can only do one thing from this whole post, replace your longest-lived agent credential with a short-TTL token today.

4. Tag every agent action so it's distinguishable in the logs

This is the 68% problem, and it's cheap to fix in advance and expensive to fix retroactively.

Every request an agent makes should carry something that identifies it: a distinct principal, a header, a user-agent string, a request ID prefix — whatever your stack supports. The bar is that you can run one query and get every action a specific agent took in a time window, without guessing.

Test it now, not during an incident. Pick an agent, and try to answer: what did it touch in the last 24 hours? If that takes more than a few minutes, you've found real work.

5. Keep an inventory, and make revocation a single action

An agent inventory is a list of every agent you run, what credential it holds, what that credential can reach, who owns it, and how to kill it. Five columns. A markdown table is fine.

This is the control that addresses the 82% number — the unknown agents. You cannot revoke what you haven't written down, and agents accumulate faster than anyone expects because spinning one up now takes an afternoon. The prototype somebody built in March is still running with a token from March.

We keep this in the Operator Vault alongside the rest of the operator knowledge base, because it needs to be a living document that agents and humans both read, not a spreadsheet somebody exports quarterly. The format matters less than the discipline: when an agent is retired, its credential is revoked in the same commit.

And rehearse the revocation. Time yourself killing one agent's access completely. If the answer is "I'd have to go look," that's your next hour of work.

The SMB version of this problem

If you're not building agents but you're buying tools that embed them — and in 2026 that's every CRM, help desk, and phone system — the same problem arrives through a different door.

Your vendors' agents are authenticating into your systems, usually via an OAuth grant somebody clicked through during onboarding. The questions to ask, in order:

1. What does each connected app actually have permission to do? Go into the OAuth app consent list in your Google Workspace or Microsoft 365 admin console and read it. Most people have never opened this screen. There will be things on it you don't recognize.
2. What happens to those grants when an employee leaves? Many are tied to an individual user's authorization. Offboarding that only disables the human account can leave the agent running — or break it silently at 2am, which is its own problem.
3. Does the vendor log agent actions separately from user actions? Ask directly, in writing, before renewal. The answers are getting better because customers started asking.
4. What's the revocation path if the vendor is breached? You want to know before, not during.

This is a standard part of what we map in a Workflow Audit — it consistently turns up connected apps nobody remembers approving, holding scopes nobody would grant today.

What this doesn't fix

Being straight about the limits, because the vendor content in this space usually isn't.

Agent identity is containment, not prevention. Scoped, short-lived, well-logged credentials do not stop prompt injection — they cap what a successful injection can reach. An agent with narrowly correct permissions can still be talked into doing something harmful within those permissions. That's a different problem, and we wrote about the shape of it in the lethal trifecta.

It also doesn't fix your transport layer. If your MCP setup has an injection path, per-agent credentials limit the damage but the path is still open — see MCP security for small teams.

And it doesn't help if you can't detect anything. Hugging Face's own stated fix was that "a high-severity signal pages a responder in minutes, any day of the week." Identity gives you the forensic trail. Somebody still has to be watching it. Their other hard-won lesson is worth repeating for anyone running agents: they couldn't use hosted frontier models for the forensic analysis, because submitting real attack payloads tripped the providers' safety guardrails. They ran it on an open-weight model on their own infrastructure instead. Have a capable local model vetted before you need it — both to avoid guardrail lockout and to keep attacker data and credentials inside your environment. That's the same argument we make for private on-prem deployments generally, arriving from an unexpected direction.

The one-week version

If you want to actually do this rather than think about it, here's the sequence we run:

1. Day 1 — Inventory. List every agent, every credential it holds, and the age of that credential. Include the prototypes. Include the cron jobs. Expect to find two or three you'd forgotten.
2. Day 2 — Find the worst one. Sort by blast radius: which single credential, if leaked, reaches the most systems? That's your starting point, not the newest agent.
3. Day 3 — Split it. Give that agent its own identity, scoped to what it actually calls. Then do the same for the next two.
4. Day 4 — Shorten TTLs and rotate. Move to short-lived tokens where the provider supports it. Rotate everything that's older than 90 days regardless.
5. Day 5 — Tag and test. Make agent actions distinguishable in your logs, then verify by answering "what did agent X touch yesterday?" with a single query.
6. Ongoing — Wire it into the workflow. New agent means new identity in the same commit. Retired agent means revoked credential in the same commit. If it isn't in the deploy path, it will not survive contact with a busy month.

Week one gets you from "we'd be guessing" to "we could answer." That's the whole goal.

Where this fits in an operator stack

We've written before about operator stacks — memory, vault, coordination. Identity is the fourth layer, and it's the one teams add last, usually after something scares them.

The argument for adding it early is the same as for the other three: retrofitting coherence costs more than building it in. If agent identity is part of how you provision agents from the start, every agent you add inherits it. If it isn't, you eventually run a migration across a dozen agents you no longer fully remember building — and you run it under time pressure, because something already happened.

FAQ

What is AI agent identity? AI agent identity means each AI agent has its own credential, its own permission scope, and its own audit trail, instead of sharing a human's API key or a blanket service account. It lets you scope what a single agent can reach, revoke it independently, and tell that agent's actions apart from a person's in your logs.

What is a non-human identity (NHI)? A non-human identity is any principal that authenticates without a person present — a service account, CI runner, machine token, or AI agent. Agents are the hardest kind to govern because they acquire permissions at runtime, spawn sub-agents, and chain actions across systems based on text they just read, which makes a compromised agent credential far more dangerous than a compromised static service account.

Should each AI agent have its own credential? Yes. One identity per agent, not one per team or environment. Shared credentials mean any single compromise reaches everything every agent could reach. Per-agent credentials turn "we were breached" into "one specific agent was breached," which is the difference between a contained incident and a full rebuild.

How do you authenticate an AI agent with OAuth? For agent-to-server calls with no human present, use the OAuth 2.1 client credentials grant: the agent authenticates with its own registered credentials and gets a short-lived, scoped access token. The MCP specification requires OAuth 2.1 for remote server authentication. Where a human delegates to the agent, use token exchange so the log records both the agent and the person it acted for.

How often should AI agent credentials be rotated? Prefer short-lived tokens measured in minutes or hours over rotation schedules — an expiring credential protects you even when detection fails. Where you must use long-lived credentials, rotate on a fixed schedule of 90 days or less, and revoke immediately when an agent is retired. A March 2026 CSA study found 33% of organizations don't know how often their agent credentials are rotated at all.

Can small teams do agent identity without an identity platform? Yes. At 3–30 people you need five things: one credential per agent, permissions scoped to actual usage, short TTLs, agent-tagged log entries, and a written inventory with a one-step revocation path. That's a markdown table and some provisioning code, not a six-figure IAM deployment.

Does agent identity stop prompt injection? No. It contains it. Scoped, short-lived credentials cap what a successful injection can reach, but an agent can still be manipulated into harmful actions within its granted permissions. Identity is a blast-radius control, and it needs to sit alongside input handling, tool-call review, and monitoring.

If you want help with this

Two ways we work on this.

If you don't know what you're running — which is the common case, and not an embarrassing one — start with a Workflow Audit. We map the agents, the credentials, the connected apps, and the scopes, and hand back the inventory plus a prioritized fix list. Most of the value is in the first document: seeing it written down changes what people prioritize.

If you already know and need it implemented, that's a Last Mile hardening sprint — per-agent identity, scoped permissions, short-lived tokens, and log tagging wired into your deploy path so it stays true after we leave. It's also the substrate DFNDR is being built on.

Either way, the first move is the inventory. Go write down every agent you're running and how old its credentials are. That list is usually persuasive enough on its own.