Control what your AI agents can reach, and prove what they did.
KPATH governs, audits and controls every interaction your AI agents have with enterprise systems. Your identity provider decides what an agent may do. KPATH enforces it on every call, and keeps a record your auditor can check.
Three problems arrive together, usually in this order.
Almost every organisation running agents at any scale recognises at least two of these. They are not separate problems. They all come from the same gap.
Spend climbs, nobody can attribute it
Token spend rises every month with no per-agent attribution. Finance starts asking which agent cost what, and the platform team has no way to answer.
Four teams, four frameworks, no registry
Agents get built independently across the business. Nobody keeps a shared inventory, most agents have no named owner, and the rules live in whichever team wrote them.
Agents act on their own, with credentials
An agent that is useful holds real access. When one behaves badly there is no way to stop it mid-action, and no record that survives an audit.
Governance decides. Someone has to enforce.
Identity platforms issue agent identities and decide what should be allowed. A decision is not an enforcement. Something has to be sitting there at the moment the agent acts, able to say no. Most estates have nothing in that position, which is why the spending and the sprawl go unnoticed until someone audits them.
Your identity provider
It issues the identity and decides what the agent may do. It has no way to stop the call once the agent is acting.
KPATH
It sits on the path between agents and services, so it can allow or refuse the call while it is happening, and log it.
Your identity provider decides. KPATH enforces.
KPATH, the control plane between your agents and everything they touch.
Every call from an agent goes through it, which is what makes it a control plane rather than a dashboard: the one place where governance is applied rather than reported on 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.
Find what exists
A live picture of the agents running in your business and the services they reach, including the ones nobody registered. Agents are pointed only at the services a job needs, which also cuts the tokens they spend.
Give every agent a name
Each agent becomes a governed identity with an owner, a risk tier, a lifecycle, and a switch that turns it off.
Decide at the call
Identity, budget, policy and human approval are checked on every request, not signed off once at onboarding.
Limit the blast radius
Threat filtering runs inline, and stopping a chain stops every agent and action descending from the original request. Afterwards there is a record anyone can check showing the stop held.
Answer the auditor
A tamper-evident record of which agent did what, on whose authority, streamed to your SIEM.
Zero trust, applied to every call an agent makes.
The principles your security team already runs still hold. What changes is the caller. An agent acts on its own, for someone else, and hands work to other agents, so the check has to happen on every call, not once at login.
Check who is acting, and for whom
Every call carries the agent's own identity and, when it acts for someone, theirs too. Nothing is allowed because of where the call came from.
Only what this action needs
An agent never inherits the permissions of the person who started it, and never holds the credentials of the systems it reaches.
Plan for an agent being turned
Limit what any one agent can reach, stop it and everything it set in motion, and keep a record your auditor can check.
Nothing gets torn up
Keep your identity provider, your guardrails engine, your agent platform, and your existing APIs. KPATH adds the enforcement layer the rest of the stack was never designed to provide.
Starts in monitor mode
The first step only watches. It inventories the agents and services already running and enforces no policy yet, so you see the picture before committing to enforcement.
Follow one call through the KPATH platform to see the five checks, the containment model and the standards it speaks.
Not ready for a control plane yet? Our consultancy helps you work out where agents belong and what to enforce.
See the consultancy →Built by security people, with UK research partners behind the work.
KPATH is built by the team that built and scaled HYDN Security, a cybersecurity firm whose clients include Rapid7, a16z, Consensys and MetaMask.
Meet the team →We develop secure AI with the Artificial Intelligence Collaboration Centre, led by Ulster University with Queen’s University Belfast, and the Centre for Secure Information Technologies at Queen’s.
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.
The checks people run before routing agents through anything.
Does KPATH read our payloads?
Only what you declare. KPATH governs the request envelope: identity, target, action, size, delegation chain. Of the payload, it reads only the values you declare for a rule, such as a payment amount.
Who holds the encryption keys?
You do. Credentials are encrypted under a key held in your own vault or key service. KPATH is a user of those keys, never the custodian.
What happens if KPATH itself has a problem?
It runs as several redundant enforcement points, the same pattern you already rely on for your API gateway and your identity provider. You decide the failure behaviour in advance: keep applying the last decision 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.
What does monitor mode risk?
Deploy in monitor mode: observe only, enforce no policy, rewrite no agents. Flip to enforce by repointing egress. It inventories the agents and services already running and enforces no policy, so you see the estate before deciding what to enforce and when.
Does KPATH need the cloud?
No. It runs in your own AWS, Microsoft Azure or Google Cloud estate, on premises, in an air-gapped environment, or as a service we run for you. There is no runtime dependency on a KPATH-hosted service in the self-hosted tiers.
Which agent frameworks does it support?
Any. Agents keep their framework, model and prompts, and need only a small change to send their calls to KPATH. None is rewritten. It governs other non-human callers the same way, including backend applications, scheduled jobs and MCP clients.
Does it replace our identity provider?
No. Your identity provider is the policy decision point: it issues agent identities and decides what should be allowed. KPATH is the policy enforcement point that acts on that decision at the moment the agent calls. Keep the one you have.
Can the audit record be verified without trusting KPATH?
Yes. The record is signed and tamper-evident, and you can check it yourself, offline, with a standalone verifier and a sample export we provide. A log you control is not evidence.
See KPATH running on a live agent estate.
A 30-minute call with the people building it. We reply within one working day.