Non-Human Identity Governance Wasn't Built for Agents That Improvise

Non-human identity (NHI) became its own security category for a good reason: service accounts, CI/CD tokens, and machine-to-machine API keys outnumber human logins in most organizations by an order of magnitude, and almost nobody had a program for them. AI agents are now the fastest-growing line item in that inventory. The trouble is that most NHI programs were designed around identities that don’t decide what to do next — and an agent’s whole job is deciding what to do next.

The failure: an NHI program that assumes the identity is static

A mature NHI program does four things well for a service account: discover it, assign an owner, rotate its secret on a schedule, and flag it when it goes quiet or spikes. All four assumptions hold because a service account’s behavior is fixed at deploy time — the same job calls the same three endpoints in the same order until someone changes the code. Anomaly detection works precisely because “normal” is narrow and doesn’t move.

An AI agent breaks that model in three ways at once. First, its call pattern isn’t fixed by a deploy — it’s composed at runtime by an LLM reading a prompt, a tool description, or an Agent Card, so “normal” for one invocation of the same agent can legitimately look nothing like the last one. Second, it’s provisioned faster than any NHI intake process was built to absorb — an engineer wires an agent to a new API on a Tuesday afternoon, and the credential that agent holds never goes through the same review a new service account would. Third, it doesn’t stay inside one system’s inventory: an agent authenticated under your NHI program can turn around and call another agent over A2A, or reach a downstream tool over MCP, extending an identity’s effective reach past the boundary any single team’s spreadsheet tracks.

The result isn’t that NHI programs are wrong about agents — it’s that the inventory-and-rotate model answers “does this identity exist and is its secret fresh,” which is necessary and says nothing about “is what it’s doing right now consistent with what it’s for.”

Why “just add agents to the NHI inventory” doesn’t close the gap

Extending an existing NHI tool to enumerate agent credentials is the obvious first move, and it’s worth doing — but it solves discovery, which was never the hard part for agents. The hard part is that an agent’s authorization boundary needs to be evaluated on every call, because the call itself is decided at runtime, not at provisioning time. A service account’s key rotating on schedule is a meaningful control because the account’s behavior between rotations is predictable. An agent’s key rotating on the same schedule protects the same thing — the secret’s freshness — but says nothing about whether call #4,000 this hour was one the agent should have made. Rotation is a credential-lifecycle control. Agents need a per-call authorization control layered on top of it, and most NHI tooling stops at the first.

This is also why NHI dashboards built around per-identity risk scores under-serve agents: a single agent identity can be the correct actor for one call and a confused deputy on the very next one, using the exact same credential. Risk lives at the call, not just at the identity.

Where the fix actually has to live

• Provisioning has to happen at the same broker that will later enforce and audit the call, not in a separate onboarding step that hands the agent a standing secret and hopes the NHI tool notices it later. An inventory built by scanning for credentials after the fact is always behind the agent that already has one.
• Ownership has to be assignable per agent, per workspace, and reviewable on the same cadence as human offboarding — an agent whose owning team disbands or whose project ends is exactly the kind of stale NHI a program exists to catch, and agent offboarding needs the same urgency as a person leaving, not a quarterly access review that finds it six months late.
• Rotation and scoping are table stakes, not the whole answer — an agent’s credential should be short-lived and scoped to exactly what that task needs, but that’s the floor an NHI program already knows how to build. The part it’s missing is policy evaluated fresh on every call the credential is used for.
• Every call needs to be attributable back to the identity, the task, and — across a delegation chain — whoever the agent is ultimately acting for, in one connected record. An NHI inventory that stops at “this key belongs to this agent” can’t answer “which of this agent’s three thousand calls today were the ones that mattered,” which is the question an incident review actually asks.

The business case: a broker is an NHI program’s missing enforcement layer

Fullmakt doesn’t compete with an NHI inventory tool — it’s the piece that makes an NHI program’s controls actually reach agentic AI, because it sits as the broker between every agent and every credentialed call instead of just cataloging credentials from the outside:

• Provisioning and enforcement happen in the same place, so an agent never holds a standing secret an inventory has to go find later — every credential an agent uses was issued scoped, short-lived, and already known to the system that will evaluate its next call.
• Policy is evaluated per call, not just at issuance — which is what turns “this identity has access” into “this specific action, right now, is or isn’t allowed,” the missing layer under most NHI risk scoring.
• Offboarding and ownership changes take effect immediately, because revoking access at the broker doesn’t wait for a key rotation window or a credential-scanning sweep to catch up — a stale agent identity stops being able to act the moment someone decides it should.
• The same tamper-evident audit trail that satisfies traceability requirements also gives an NHI program the thing its inventory alone can’t: a call-level record of what each agent identity actually did, across MCP tool calls and A2A delegations alike, tied back to task and requester.

The category-level shift here is the same one 1Password recognized when it bought into credential brokering for agents: NHI programs are realizing that inventory and rotation, built for identities whose behavior is fixed at deploy time, don’t extend to identities that compose their own next action. Closing that gap takes a broker sitting on every call, not a bigger row in the same spreadsheet.

FAQ

Isn’t an AI agent’s credential just another service account? Structurally, often yes — an API key or OAuth client. Behaviorally, no: a service account’s call pattern is fixed by its code, an agent’s is composed at runtime by a model, which is why identity-level controls built for the former under-cover the latter.

Do we need to replace our existing NHI/secrets-management tool? No — inventory and rotation tooling still does real work at the credential layer. What’s missing for agents is per-call authorization and attribution, which sits at a different layer and can coexist with whatever already tracks and rotates the underlying secrets.

Does this overlap with the shadow AI problem? It’s related but distinct: shadow AI is about credentials nobody centrally knows exist. This is about what happens once an NHI program does know an agent exists, and still can’t answer whether its four-thousandth call today was the right one.

What should an NHI program ask about an AI agent it’s onboarding? Not just “who owns this and how often does its secret rotate,” but “where is every call this identity makes evaluated against current policy, and can we produce a call-level record of what it actually did, across every protocol it uses.”

Is this only relevant to regulated industries? Compliance frameworks like ISO 42001 and the EU AI Act make the requirement explicit, but the underlying gap — an identity whose behavior isn’t fixed at provisioning time — exists anywhere an agent holds a credential, regulated or not.

A non-human identity program answers “does this credential exist, who owns it, and is it fresh.” An AI agent needs all three of those answers, plus a fourth one no inventory can give it on its own: was this specific call, at this specific moment, actually the thing this identity was supposed to do. That answer has to come from whatever sits between the agent and the call — not from a dashboard that only looks at the credential from the outside.