Why agents made this urgent
Non-human identity is not new. Service accounts, API keys and machine certificates have been around as long as services have called each other. What changed is the caller.
A normal application does what you wrote. An agent decides what to do, picks a tool, and acts with real permissions. When such a thing holds a shared API key, or runs under a human’s login, the key or the login is now doing whatever the agent decides, and the record shows a person or a service account rather than the agent. Nobody can say afterwards which agent did what, on whose authority.
So the first job is to give each agent an identity of its own, with an owner and a risk tier behind it, and to stop it carrying anything else.
Workload identity
Workload identity is the mechanism for issuing that identity to a running process rather than configuring it by hand. The workload asks for its identity when it starts and receives a short-lived credential it can present to anything that trusts the issuer, instead of holding a long-lived secret someone pasted into a config file.
The properties that matter for agents are the ones that make the identity hard to steal and cheap to check: it is issued automatically, it expires quickly, and a relying party can verify it rather than take it on trust. Enterprises get those properties from several different mechanisms, inside a cluster and across one, and most estates run more than one at a time.
KPATH works with the identities you already issue. Every call through it carries the agent’s identity with an owner and a risk tier. High-risk agents can be required to present a workload identity that your identity provider verifies, so a name alone is not enough for the actions that matter.
Principal binding
An agent’s own identity answers only half of the question. Most consequential agent actions happen on behalf of someone: a customer asking an assistant to move money, an employee asking a harness to change a repo, a partner system arriving from outside.
Principal binding ties the agent’s identity to the person or system it is acting for on this request. The call then carries two facts: which agent is calling, and whose authority it carries. Policy can act on both. When an agent acts for a person, KPATH policy can insist that the person is verified, not merely named, before a high-risk action proceeds.
This is the fact that is missing from most estates today. Application logs show that a service account touched a system. They do not show that a particular customer’s request, through a particular agent, was the reason.
No credentials in the agent
Identity and credentials are different things, and the difference decides the blast radius.
An agent that carries the real credentials for the systems it uses is a walking key ring. If it is compromised, through prompt injection or a poisoned tool description, every door it could open is open.
Under KPATH, agents carry their own identity and nothing else. On an allowed call KPATH adds the real credential for the target system; the agent never sees it. Those credentials are encrypted under a key held in your own vault or key service. KPATH is a crypto user, not a custodian. A compromised agent holds nothing that opens a door anywhere else, and stopping the agent removes the only thing it had.
Why identity alone is not enforcement
A verified identity answers who is calling. Three more things have to happen before the call is governed.
Something has to decide whether this identity, acting for this principal, may take this action on this target right now. That decision belongs with your identity provider and the policy you write there.
The decision then has to be applied on the call: refuse it, hold it for a person, add the credential only if it passes. An identity provider is not on the path of the call and cannot do this. A directory of identities, however complete, is a register.
Last, the identity, the principal, the decision and the outcome have to be recorded in a form an auditor can verify. Otherwise the identity work produces a better-labelled log and nothing more.
Where KPATH sits
Your identity provider decides. KPATH enforces. KPATH works with the identities you already issue and applies the decision per action, before the payload reaches the target, for the agent and, where policy requires, for the person it acts for.
It governs the request envelope only: identity, target, action, size, delegation chain. Of the payload, it reads only the values you declare for a rule, such as a payment amount.
Start in monitor mode: agents keep their framework, model and prompts, each sends its calls through KPATH with its own identity, and the inventory shows which identities are actually in use, including the ones nobody registered. Nothing is refused until you choose to enforce.