The agent identity problem: when "who did this?" has no good answer

Every examination, every incident post-mortem, every audit finding you've ever written comes back to one question: who did this? A person, a role, an accountable name. That question has quietly stopped having a good answer, and the reason is that the things acting on your data are increasingly not people. This is the governance problem underneath every other AI-agent story — and the one examiners are going to reach for, because it's the one they already know how to ask.

What happened

The security industry has a name for this now: non-human identity (NHI) — any credential that belongs to software rather than a person. Service accounts, API keys, OAuth tokens, cloud workload roles, certificates, and now AI agents (Palo Alto Networks). These identities have exploded. Industry surveys put non-human identities at roughly 45 to 1 over human identities on average — and far higher in cloud-native shops — with the count in a typical enterprise climbing from tens of thousands a few years ago into the hundreds of thousands (Security Boulevard, 2026; NHI tools survey, 2026).

In May 2026 the Cloud Security Alliance published a whitepaper calling non-human identity governance "the defining security gap of the agentic AI era" (CSA, May 2026). Its central point is the one that should land for a risk owner: the blast radius of an AI agent's credential cannot be fully determined at the time the credential is issued — because agents behave differently from the static service accounts we already struggled to govern.

Why it matters

For years, "machine identity" meant a service account that did one predictable thing. You could over-provision it, forget it, and mostly get away with it. AI agents break that in three ways the CSA paper lays out plainly:

• They acquire permissions at runtime. An agent can request new access mid-task through tool-calling and role assumption — expanding its own reach beyond whatever you provisioned on day one.
• They spawn other identities. A parent agent can create child agents, each with its own ephemeral identity and permissions that shift per invocation.
• They reason about what access they "need" and act to get it.

Stack that against the survey reality: only about 15% of organizations feel confident preventing NHI-based attacks; 51% report no clear ownership of AI identities; and 16% don't even track when new AI-related identities get created (CSA whitepaper). So the entity taking actions on your data is a credential that (a) nobody owns, (b) nothing tracked into existence, and (c) can quietly widen its own access. That is the "who did this?" problem in its purest form — and it's the through-line connecting the rest of this series: the A2A agent mesh, the computer-use action problem, and the MCP server you granted a token all resolve, in the end, to whose identity acted, and who is accountable for it.

Here's the part that should get a compliance officer's attention specifically: the CSA paper argues the major frameworks have a blind spot. SOC 2 audits typically center on human user access; ISO 27001 provisions were written for human principals; PCI DSS 4.0 left LLM-agent application ambiguous — and no regulatory framework was written with agentic credentials in mind. The result is a "compliance gray zone" where an organization can pass its audit while its entire population of agent credentials goes unexamined. Read that as a risk owner and it inverts into an opportunity: when the auditor doesn't ask, the pressure to govern this has to come from inside. The teams that build the answer before it's demanded will have it ready when the demand arrives.

What it means for you

If you're a credit union or community bank — No US regulator mandates AI-specific identity controls today; the obligation is inherited through your existing vendor-management and information-security duties, and it's sharpened by the fact that the NCUA cannot examine your third-party technology vendors (GAO-25-107197, May 2025) — so the accountability question inside a vendor's system is one you have to ask, because no examiner is asking it of them. Do-this-Monday: add "non-human / agent identities" to how you think about access reviews. For your core systems, ask a plain question — which service accounts and AI agents can act here, who owns each one, and can it grant itself more access? You will not get a clean answer the first time. Getting the question on the record is the point; proportionality (07-CU-13) lets you start with core and high-risk systems and work out.

If you're an RIA or broker-dealer — Reg S-P requires written policies for oversight, due diligence, and monitoring of service providers, plus a written incident-response program — and it's a named SEC Examinations FY2026 priority. An incident-response program presumes you can answer "who did this?" during an incident. If the actor might be an agent identity that no one owns and nothing tracked, your program has a gap you want to find on your own schedule. Do-this-Monday: ask your key vendors one question and file the answer — how do you identify, own, and revoke the AI-agent and service-account identities that touch our client data? A vendor who can answer crisply is demonstrating maturity; one who can't has just told you where your risk is.

How to get ahead of it

1. Treat non-human identities as in-scope for identity governance. They're identities. The same lifecycle questions apply: who owns it, why does it exist, when does it expire, who can revoke it. The mature-program pattern the industry is converging on is a registry with ownership assignment, short-lived credentials, just-in-time / zero-standing-privilege access, and behavioral monitoring — you don't have to build all of it to start naming owners.
2. Assign an owner to every agent that touches regulated data. The single highest-leverage move in the CSA framework is also the least technical: an accountable human name per identity. "No clear ownership" is the 51% failure — don't be it.
3. Ask vendors the identity question and keep the answers. Their answer to "how do you govern agent identities" is diligence evidence whether it's good or bad. File it dated and attributed.
4. Watch for the standard forming. Cryptographic workload-identity approaches (SPIFFE/SPIRE) and attribute-based access control are where the technical answer is heading. You don't need to implement them; you need to recognize them, so you can tell a vendor's real answer from a hand-wave.

What to watch out for

The overreaction: launching a six-figure NHI-management platform before you've named a single owner. The tooling is real and maturing, but it automates a discipline you haven't started. Assign owners and ask the vendor questions first; buy the platform when you've outgrown the spreadsheet, not before.

The snake oil: anyone selling "AI identity governance" that turns out to be a secrets scanner with a new label, or a dashboard that counts your identities without ever assigning accountability for them. Counting is not governing. The test question: does this tell me who is responsible for this identity, or just that it exists?

The false comfort: "we're SOC 2, so identity is covered." Per the CSA analysis, that's precisely the gap — SOC 2 scope was built around human users, and agent credentials can pass right through it. A certification you hold is not the same as a question you asked.

The bottom line

"Who did this?" is the oldest question in your job, and the agentic era is engineering a world where the honest answer is increasingly "a credential nobody owns, doing something nobody authorized in advance." No rule mandates the fix yet — which is exactly why the institutions that assign owners and ask the identity question now will be the ones with an answer when an examiner reaches for it. Inventorying which agents and non-human identities can touch your regulated data, and pinning an owner to each, is the spine of what a Discover scan produces — the named list, and the dated record that you built it before you were asked.

Request your Discover scan — we run it with you, and "who can act on this data" is the first thing it answers.