Every enterprise agent, governed, secured and auditable.

It is worth asking every vendor who uses the phrase. A management console tells you, afterwards, that an agent reached some data. An enforcement control plane is in the call path, so it can make sure the agent never reached data it was not authorised to touch. KPATH AMP is the second kind. Most products carrying the label are the first.

Because that puts the control inside the thing you are trying to control. Framework-level governance runs in the agent's own code, which is exactly what a prompt injection captures first. A hijacked agent can decide anything it likes. KPATH AMP sits outside the agent, on the path its calls have to travel, so the decision is not the agent's to make. It also covers agents that other teams and outside vendors built, which self-governance never will.

That chain is the part most tooling cannot see. KPATH AMP tracks which agent invoked which, so stopping an agent also stops the agents and actions it triggered downstream, rather than leaving a cascade running. Cost rolls up the same way, which shows you which original request caused the spend.

Then keep it. Your identity provider decides which agents exist and what they should be allowed to do, and it is the right place for that. What it cannot do is act on the decision at the moment an agent makes a call. KPATH AMP consumes the identities you already issue, whether from Okta, Microsoft Entra or SPIFFE, and enforces them per action.

Keep that too. API gateways were built for human traffic and for APIs you control, and they route and rate limit well. Agents are non-human callers that discover services, delegate to each other and act at machine speed. Verifying an identity per action, governing a chain of agents, and producing evidence an auditor accepts are not things an API gateway was built for.

An MCP gateway governs traffic on one protocol, typically deciding which tool servers an agent can see and applying rate limits to them. KPATH AMP treats MCP as one of the surfaces it governs, alongside REST and GraphQL APIs and internal services, so a tool call made over MCP is checked against the same identity, policy and record as anything else that agent does. Estates rarely speak a single protocol, and an agent is only as governed as its least governed path.

No. Anything non-human that makes a call is governed the same way, including backend applications, scheduled jobs, MCP clients and a partner's system arriving from outside. Agents are simply the newest and least predictable callers, which is why they get the attention.

Which agent took an action, on whose authority, when, and whether the record has been altered since. Approvals are captured as they happen rather than reconstructed afterwards, and the trail streams into your SIEM. It is built to be exported as evidence rather than read as a debug log.

It is built as a high availability enforcement point, which is the same pattern you already rely on for your API gateway and your identity provider. Worth weighing against the alternative: every team wiring its own identity, limits and logging into every agent, separately, forever. That is the arrangement that actually tends to fail.

Yes, and most organisations should. Monitor mode inventories the agents and services already running and permits every call. You see your estate first, then decide what to enforce and when. No agent gets rewritten to begin.