What does the KPATH platform do?
KPATH governs, audits and controls every interaction your AI agents have with enterprise systems. It sits on the one path between the agents your teams build and the services they reach, so every call is identified, checked against policy and recorded.
Your agents call KPATH.KPATH calls your systems.
Every enterprise agent, governed, secured and auditable
Your agents call KPATH. KPATH calls your systems. Being on that path is what lets it allow or refuse a call while it is happening, rather than report on it afterwards.
- Personal assistants
- LangChain and CrewAI
- Claude and OpenAI agents
- MCP servers and tools
- identity
- policy
- cost
- approval
- guardrails
A refused call stops here, and is recorded.
- Internal service agents
- Enterprise APIs
- MCP tool servers
- External SaaS, proxied
One path between every agent and every system it can touch. Agents carry no system addresses and no credentials, so every call is identified, checked against policy and recorded, whatever framework the agent runs on.
Credentials are encrypted under a key held in your own vault or key service, content inspection can run inside your boundary, and the evidence lands in the systems your auditors already read.
What happens when a payments agent tries to send £48,000.
The same five checks run on every call, whether the caller is an agent your team built or one a vendor sent. Here they are on one call. The request: a payments agent is asked to send a £48,000 supplier payment.
- 01Discover
The agent asks KPATH which service can send payments. It gets a governed route to the ledger, never the ledger's address.
Route to ledger. - 02Identify
KPATH checks the agent's identity with your identity provider: the payments agent, owned by treasury operations, high-risk tier.
Verified. - 03Govern
Policy lets this agent make payments and the budget has room. Payments over £10,000 need a person, so the call waits. The request reaches an approver outside treasury operations in Microsoft Teams, because the team that owns the agent cannot approve its own requests.
Approved by a person. - 04Contain
Your guardrail scans the request on the way through. Only then does KPATH add the ledger credential, which the agent never sees.
Clean, credential added. - 05Prove
The call, the approval and the outcome go into the tamper-evident record and on to your SIEM.
Recorded.
If any step fails, the call stops there, and the refusal is recorded too.
Five checks, and what sits behind each one
These are not settings applied once at onboarding. They run on the request itself, every time an agent acts.
Find what exists
Live inventory. Every agent that calls through KPATH, and every service it reaches, goes into the inventory, including the ones nobody registered.
Governed directory. Agents ask which service can do a job and see only the ones policy allows. It also works alongside the catalogue you already keep.
Give every agent a name
Agent identity. Every call carries the identity of the agent making it, with an owner and a risk tier behind it. High-risk agents can be required to present a workload identity that your identity provider verifies. When an agent acts for a person, policy can insist that the person is verified as well as named.
No credentials in the agent. Agents carry their own identity and nothing else. KPATH adds the real credential for each system on an allowed call, so a compromised agent holds nothing that opens a door anywhere else. Those credentials are encrypted under a key held in your own vault or key service.
Decide at the call
Risk-tiered policy. Agents carry a risk tier that drives how strictly they are treated. High-risk agents face tighter rules than low-risk ones, rather than one flat ruleset for everything.
Budget. A team's spend limit can be enforced on the call itself, so the budget stops the spending instead of reporting on it afterwards. Spend is attributed to each agent either way.
Limits on the amount. Policy can read the values that matter inside a request, such as the amount of a payment, so a £10 transfer and a £10 million one are no longer the same call. Rules set the brackets: below one line the call goes through, above it a person decides, beyond another it is refused. KPATH proposes which fields carry the amounts, and a person confirms each one before a rule can use it.
Human approval, where your people already work. High-risk actions stop and wait for a person, inline at the call rather than in a review after the fact. Requests reach approvers in Slack, Microsoft Teams, ServiceNow or Jira as well as the KPATH console. Policy says who may approve, how many approvers it takes and from how many teams, and the person who registered the agent, or anyone on the team that owns it, can never approve its requests. A request nobody answers escalates. Every decision is recorded.
Slack
Microsoft Teams
Jira
Limit the blast radius
Kill switch. Any agent, or a whole chain of agents, can be stopped immediately and stays stopped, without waiting for a credential to expire or a deployment to roll back.
Behaviour watch. An agent that starts acting out of pattern gets flagged: a sudden burst of calls, reaching for systems it never used, a run of refusals, or a credential turning up where it should not. High-risk agents are paused automatically.
Your guardrails, inline. Your content guardrail runs at the call as a policy step, scaled to the agent's risk tier, with every verdict recorded.
Answer the auditor
Tamper-evident audit. A tamper-evident record of every call, streamed to your SIEM as it happens and ready for long term retention on write-once storage. It records who acted and what was decided, never a secret or a message body. Your auditor can check it has not been altered without taking our word for it.
Cost by agent. Spend is attributed to each agent and rolled up to the request that started the chain, so finance can see which piece of work caused it.
Want the detail behind each of these? Read what a control plane actually does.
Agents call other agents, so stopping one has to stop the rest
One request can set off a chain: an assistant calls a payments agent, which moves money. Revoking a single agent leaves everything it already started still running. KPATH stops the whole chain, and afterwards gives you a record anyone can check showing that nothing in it was authorised after the stop.
A control plane, not a gateway with a policy tab
The most common question is which of your existing tools this competes with. Usually none of them. KPATH replaces nothing, and adds the part the rest of your stack was never built to do.
Not a management console.
Plenty of products called control planes sit outside the traffic and report on what an agent did after the fact. KPATH is in the call path. That is the difference between being told an agent reached something and making sure it could not.
In the path like a gateway, checking different things.
Yes, KPATH sits in the path the way a gateway does. The difference is what it checks. API gateways route and rate limit traffic to APIs you control, MCP gateways govern one protocol, and model gateways decide which model answers. KPATH checks who the agent is, what it may reach across APIs, other agents and MCP servers, and what the whole chain of agents is doing. It meters model calls too.
Not an identity provider.
Your identity provider issues agent identities and decides what should be allowed. KPATH consumes those identities and enforces the decision at the moment the agent acts. Keep the one you have.
Not a firewall or network segmentation.
Firewalls and segmentation contain zones and applications. They were not built to contain an individual agent, whose calls look like any other request to an approved service. KPATH contains the agent itself: what it may reach, call by call. Your firewalls and web application firewalls keep their jobs.
Not a guardrails engine.
Content inspection catches prompt injection and unsafe payloads but does not know who is calling. KPATH invokes your guardrails inline as a policy step, so identity and content safety land as one enforced decision. If you host the guardrail yourself, the content it inspects never leaves your boundary.
Three steps, and policy blocks nothing until the last one
Connect in monitor mode
Point your agents' outbound calls at KPATH, each with its own identity. Agents keep their framework, model and prompts. Policy is not enforced yet, so calls go through and are recorded from the first day. Only a failed credential or an agent you stop is refused.
See the estate, then set policy
The inventory fills in from real calls, including agents nobody registered. Adopt what you find, give each agent an owner and a risk tier, and write policy against how agents actually behave.
Switch to enforce
When the picture is complete, turn enforcement on. From then on KPATH allows or refuses each call, and every decision lands in the record.
KPATH runs in your own AWS, Microsoft Azure or Google Cloud estate, on premises, fully air-gapped, or as a service we run for you.
Speaks the standards your security review will ask about
KPATH uses the identities you already issue, runs the guardrails you already chose, keeps its encryption key in your vault, and sends its evidence to the tools your security operations team already watches.
Microsoft Entra. Okta. Other standards-based identity providers. Workload identity for high-risk agents.
Lakera. Prompt Security. Microsoft Presidio. Your own content scanner.
Splunk. Microsoft Sentinel. Rapid7 InsightIDR. Graylog. Syslog.
HashiCorp Vault. Azure Key Vault. AWS Secrets Manager and KMS. Google Cloud Secret Manager and KMS.
Model Context Protocol. Signed payment mandates for agents that move money. Encryption in transit on every hop.
WORM-ready audit retention. Amazon S3 Object Lock. OpenTelemetry.
KPATH earns its place when all three of these are true
We would rather tell you early that your estate does not need this yet. When these three hold together, running agents safely without an enforcement point stops being realistic.
Many to many
Dozens or hundreds of services with a growing agent population that needs to reach them, where hard wiring every pair has stopped being practical.
Multi-framework
Different teams building on different agent frameworks, with no single message format and no common way of calling things.
High stakes
Agent actions that touch regulated data or money, where someone will eventually ask which agent did this, on whose authority, and prove it.
In a bank or an insurer? See how KPATH governs agents in financial services. Not sure how many agents you are actually running? Start with shadow agent discovery. Working out what the EU AI Act asks of your agents? Read our breakdown.
Every page in Platform
How does KPATH give AI agents an identity?
Every call carries the identity of the agent making it, with a named owner and a risk tier behind it. Your identity provider issues that identity and KPATH verifies it on each call. Agents carry their own identity and nothing else; KPATH adds the real credential for each system on an allowed call, and the agent never sees it.
How does KPATH enforce least-privilege policy on AI agents?
Policy is set per agent and tightens with its risk tier. On every call KPATH checks identity, policy, budget and human approval, and refuses anything outside the agent's job. High-risk actions wait for a person inline at the call. Your content guardrail runs as a policy step. Every decision is recorded.
How do you stop a chain of AI agents?
Stop the chain, not one agent in it. One request can set off a chain: an assistant calls a payments agent, which moves money. Revoking one agent leaves what it started still running. KPATH stops the whole chain, the chain loses the credentials it relied on, and a containment proof shows nothing was authorised after the stop.
What makes an AI agent audit log evidence?
A log becomes evidence when a third party can verify it without trusting whoever produced it. KPATH records every decision in a signed, tamper-evident record that streams to your SIEM and is ready for write-once retention, and an auditor can prove offline that the record has not been altered without trusting KPATH.
How do you control AI agent spend per agent?
Enforce the budget on the call. KPATH checks a team's spend limit as part of policy on every request, so the budget stops the spending instead of reporting on it afterwards. Spend is attributed to each agent and rolled up to the request that started the chain, so finance can see which piece of work caused it.
How do AI agents discover which services they may call?
Almost every organisation running AI agents has more of them than anyone has written down. Discovery builds a live inventory from the calls themselves: every agent that calls through KPATH and everything it reaches, with no policy enforced.
Where does KPATH run?
Wherever your agents run. KPATH deploys self-hosted in your own AWS, Microsoft Azure or Google Cloud estate, in a VPC, on premises or fully air-gapped, or as a managed service KPATH runs. It runs as several redundant enforcement points, and you choose in advance how it behaves if it fails.
Common questions
Why not govern this inside the agent, or in the framework we already use?
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 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.
We already have an identity provider for agents.
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 consumes the identities you already issue, whether from Okta, Microsoft Entra or Kubernetes workload identity, and enforces them per action. That includes agents you did not build. A vendor's or partner's agent presents its own verified identity and is checked like any other, and one whose identity fails verification is refused outright.
We already have a service catalogue. Do we have to replace it?
No. KPATH can be the directory your agents search. It can also work alongside the catalogue you already keep, such as ServiceNow or Backstage: you bring the services you want governed into KPATH, and your catalogue stays the source of truth. Or it can skip discovery altogether and only govern the calls, so your catalogue says which service and KPATH decides whether the call goes ahead. Different parts of the estate can use different arrangements.
Does this only cover AI agents?
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.
Won't something in the call path add latency, or become a single point of failure?
It runs as several redundant enforcement points, the same pattern you already rely on for your API gateway and your identity provider. You also decide in advance what happens if KPATH itself has a problem: keep applying the last decision it made for that agent and action, or refuse calls until it recovers. Monitor mode raises the gap rather than quietly waving through calls it cannot see. If you already run enforcement points of your own, they can ask KPATH for the decision instead of sending traffic through it. Compare that with the usual alternative, where every team wires its own identity, limits and logging into every agent, and each one fails in its own way.
Can we start without blocking anything?
Yes, and most organisations should. Monitor mode inventories the agents and services already running and lets calls through without enforcing policy. You see your estate first, then decide what to enforce and when. Each agent needs a small change to send its calls to KPATH, but none is rewritten.
Published Updated
Start in monitor mode. See everything before you enforce anything.
Deploy in monitor mode: observe only, enforce no policy, rewrite no agents. Flip to enforce by repointing egress. See the agents already running in your estate before you decide what to enforce.