NPE Identity: Your Agent's Credential Needs a Sponsor

When an AI agent touches a classified system, whose credential does it use?

For years the answer has been an awkward one. A service account. A shared credential in a vault. A human's token, borrowed by a process, so that the audit log carries the name of somebody who did not perform the action.

The federal identity community has a name for the fix: the non-person entity. An NPE is any automated process, script, service, or device that needs authenticated access. The concept is not new. It shows up in the DoD Enterprise ICAM Reference Design (opens in a new tab), which treats NPEs as first-class principals with their own lifecycle, attributes, and access decisions, and in the DoD PKI certificate profiles that include NPE certificates alongside human ones.

What is new is the volume. Agentic systems multiply the number of principals in an environment by an order of magnitude, and the service account pattern does not survive that multiplication.

The CAC metaphor is the wrong one

"An identity card for AI agents" is a good headline and a bad mental model. A CAC is a token a person carries, protects, and can refuse to hand over. An NPE credential is issued by a system to a process, and the process has no interest in protecting it.

The metaphor matters because it points at the wrong control. If you think the problem is hardware, you buy tokens. If you think the problem is accountability, you build a lifecycle.

An NPE needs the same four things a service account nominally has and almost never actually gets: a unique identity, a bounded scope, a named owner, and an expiry that something enforces.

Three of those are engineering. The owner is management, and it is the one that decides whether the system is auditable.

The sponsor is the whole control

Every NPE should have a named human sponsor recorded in the identity record. Not a team name. Not a distribution list. A person who can answer three questions: what this entity is allowed to do, why it needs that scope now, and what happens to the work when it is switched off.

The sponsor is what makes the rest work. An access review with no sponsor becomes a rubber stamp, because nobody in the room owns the answer. A revocation with no sponsor becomes an incident, because nobody knows which process will break. A decommissioning with no sponsor never happens, and the credential outlives the project by years.

This is also the cheapest control to implement. One required field in the identity record, one review per cycle, one escalation when the sponsor leaves the company. Compare that to the cost of the alternative, which is an agent running with standing access that nobody can justify when an assessor asks.

If you cannot name the person who would be called when the agent goes wrong, the agent is not authorized. It is merely running.

Four fields, and the one people skip

A usable NPE record carries more than a name. Four fields do the work.

Purpose and scope. What the entity does, expressed as the systems and actions it can reach. An agent that "processes financial data" is a category. An agent that "reads contract line items from the procurement system and writes a draft invoice" is a scope.

Attributes for the access decision. Purpose, data sensitivity, time window, environment. Attribute-based access control is not a luxury here; it is the only way to express "this agent may read CUI during business hours and may never touch classified material" without building a role for every combination.

Sponsor and review date. The person, and the date the scope gets re-examined. Put the date in the record and make something fail when it passes.

Revocation path. The mechanism, tested, that ends the identity and invalidates its credentials. If revocation is a ticket to another team, it is not a control.

The skipped field in most designs is the review date, because it is the one that produces work. A record without it is a snapshot, and snapshots drift into permanent standing access.

What this changes in a system you are building

Four things, in the order they will bite you.

Design the identity in from the start. Retrofitting per-agent identity onto a system built around one shared credential is a rewrite of the auth layer, not a configuration change. If the agent architecture is still on paper, this is the cheap moment.

Plan for credential volume. Dozens or hundreds of NPEs per system means issuance, rotation, and revocation have to be automated. Manual processes fail at the second order of magnitude, and they fail quietly.

Log at the entity level, and record the decision. An entry that says an agent called an API is close to useless. What an auditor needs is which entity, under which scope, on whose behalf, with what result. The decision and the effect both.

Baseline the behavior, then watch it. Continuous verification needs a definition of normal: which tools this entity calls, at what rate, from where. The baseline is also what tells you an agent has been induced to do something new, which is the failure mode that worries me most.

Zero trust says verify every request regardless of origin. That only works if the requester has an identity worth verifying. "Service account" is not one, because it names a purpose rather than a principal.

NPE identity closes that gap. Same policy engine, same logging, same enforcement for a bot as for a person. No carve-out for automation, which is exactly the carve-out that has been quietly expanding for a decade.

What I would not claim

I am not going to tell you a date when this becomes mandatory, because I do not know, and the guidance is moving. I also would not call an NPE certificate a CAC. What I will say is that the direction is one way: as agents take real actions in federal systems, the requirement to attribute those actions to something with a name and an owner becomes unavoidable.

The organizations that struggle will not be the ones that cannot issue a credential. They will be the ones that cannot answer who owns it.