The question every other control depends on
A call arrives at a payments system. Something made it. Which agent was it, who owns that agent, and on whose authority was it acting? Most estates cannot answer that from the call itself, and every control that follows needs the answer: policy has nothing to apply to, a budget has nothing to charge, an approval has nobody to name, and the record cannot say who acted.
This is the Verify step of the Verify-Enforce-Stop-Prove test: a caller acting under a verified identity rather than a claimed one.
What an agent identity is in KPATH
Every call that passes through KPATH carries the identity of the agent making it. Behind that identity sit a name, a named owner and a risk tier. The risk tier sets how strictly the agent is treated downstream: which policy applies, whether a guardrail runs, and whether a person has to approve.
KPATH does not invent the identity. Your identity provider issues it and decides what the agent should be allowed to do. KPATH consumes that identity and enforces the decision at the moment the agent acts. Your identity provider decides. KPATH enforces.
Non-human callers, resolved by identity
KPATH treats anything non-human that makes a call the same way: agents, backend applications, scheduled jobs, MCP clients, and a partner’s system arriving from outside. Each is resolved by identity rather than by what it claims to be, so nothing hides behind a framework.
That includes agents you did not build. A vendor’s or a partner’s agent presents its own identity, verified against your identity provider like any other caller. An identity that fails verification is refused outright, before any policy is applied.
Proof rather than a claim, where the stakes are high
A name in a request is a claim. For low-risk agents that may be enough. For high-risk agents, KPATH can require the running workload to present a workload identity that your identity provider verifies, so the identity is proven by the workload itself rather than asserted by it. Which agents face that bar is a policy choice you make.
Acting on behalf of a person
Many agents act for someone: a personal assistant working for an employee, a service agent handling a request for an account holder. When an agent acts for a person, policy can insist that the person is verified as well as named in the request.
The result is a call bound to two identities: the agent that made it and the principal it acted for. Both land in the record, so the question “on whose authority” has an answer that does not depend on the agent’s own account of itself.
No credentials in the agent
Agents carry their own identity and nothing else. They hold no system addresses and no credentials for the systems they reach. When a call passes policy, KPATH adds the real credential for that system on the way through, and the agent never sees it.
This changes what a compromise is worth. A hijacked agent holds nothing that opens a door anywhere else. Revoking the agent’s own identity is a single action rather than a hunt through every system it was ever wired into.
The credentials KPATH adds are encrypted under a key held in your own vault or key service. KPATH is a crypto user, not a custodian.
Identity in the record
The Identify step is what makes the Prove step worth anything. Every call in the tamper-evident record carries the verified agent identity, its owner, its risk tier and, where relevant, the verified principal. That is how a regulator’s first question, “who is this agent?”, gets answered from the record rather than from a conversation.
Identity lifecycle
Each agent becomes a governed identity with an owner, a risk tier, a lifecycle, and a switch that turns it off. An agent that is stopped stays stopped without waiting for a credential to expire, because the credentials were never in the agent to begin with.