The agent's map, written down
Its tools, data, destinations and permissions, each marked with how sensitive it is and signed off by your team.
Kern
Know what an AI agent can reach before you approve it.
Block what it must never do.
Kern shows every place an AI agent can send your data, proves sensitive data cannot leave even if an attacker wrote the email it reads, and blocks any tool call you have not allowed.
- Map what it can reach
- Prove where data can go
- Block calls you have not allowed
The business wants AI agents in email, files and customer records. You are the one who signs off.
An agent reads email, documents and web pages, then acts on what it reads: it searches, writes, sends and calls other tools. Any of those pages or emails can carry instructions planted by an attacker. This is called prompt injection.
Testing shows how an agent behaved against the attacks someone thought to try. It cannot show what the agent will do when it meets an attack nobody has tried yet.
Say no and you block the business. Say yes and you are accountable if the agent sends out the wrong file or deletes the wrong thing.
Approving an agent should rest on evidence you can check, the same way every other access decision does.
Telling an agent not to do something does not stop it.
1,200+executives' records wiped by one agent, during a code freeze
In July 2025 an AI coding agent on Replit deleted a company's live database during a declared code freeze, after being told not to make changes without approval. Records for more than 1,200 executives and 1,190 companies were wiped. The data was later recovered, but Replit's chief executive said it "should never be possible".
Fortune, 23 July 2025, and The Register, 21 July 2025. Fortune report, The Register report.
A limit only works if something checks each action before the agent takes it. Kern writes the limits down, proves them, and checks every tool call against them. See how, step by step
After Kern
What you get after Kern.
- A clear yes, no, or "yes, on these conditions" for each agent, with the reasons written down.
- Proof that sensitive data has no route to the wrong place, whatever the agent reads.
- Any risky route named step by step, so your team knows the one change that closes it.
- Calls you have not approved are refused as they happen.
- Evidence your auditor, regulator or insurer can re-check without us.
The business wants agents now, and you carry the risk if one goes wrong.
We modelled a real Copilot flaw. Kern found the route and proved the fix.
In June 2025 Microsoft fixed a critical flaw in Microsoft 365 Copilot, rated 9.3 out of 10 (CVE-2025-32711, known as EchoLeak): a single email could make the assistant send out confidential data with no one clicking anything.
We described a Copilot-style assistant with the same shape: a mailbox, SharePoint, incoming email and a send-email tool. Kern returned the exact route: mailbox, to the reply tool, to outgoing email.
With that one connection removed, Kern proved no confidential data can leave, and the separate checker confirmed it.
CVE record published by Microsoft, 11 June 2025. CVE-2025-32711, Microsoft Security Response Center.
Three more tests: two live tools and one tampered proof file.
Kern in front of the tools agents really use, allowing ordinary calls and refusing the ones you have not allowed. And a proof file with its result changed by hand, caught by the checker.
A live browser agent
Kern in front of Microsoft's Playwright browser server, the tool agents use to drive a web browser. The agent holds a secret login token.
Kern also caught the secret by following where it came from, even when the typing tool itself was marked as safe for public data.
- Open the supplier's order pageAllowed
- Type the secret token into a web formRefused
- Run its own code in the browserRefused
A live file agent
Kern in front of the standard filesystem server for AI agents.
- Read a public fileAllowed
- Write a secret file into a public folderRefused
- Move filesRefused
A tampered result, rejected
Take a proof file for a setup that leaks, change the result to "safe", and hand it over. The checker re-does the work from the file, gets a different answer, and rejects it.
Proof fileroutes checked: 7result:route foundsaferules: as agreedCheckerRe-done from the file. The route Mailbox, Compose reply, Outgoing email still exists.Rejected. The file does not match its own contents.
The Kern method
Kern works in three steps: map, prove, enforce.
- 1
Map
We write down what the agent can reach: its tools, the data they read, where they can send it, and which agents can ask others to act. Your team confirms how sensitive each source is. Until it is confirmed, Kern treats it as the most sensitive.
- 2
Prove
Kern checks every route, assuming anything the agent reads could come from an attacker. You get a proof that sensitive data stays where it belongs, or the exact route that must change. The proof file can be re-checked by your team, your auditor or your insurer, without us.
- 3
Enforce
Kern sits in front of the agent's tools and applies the same rules to every call. Calls you have allowed go through. Any other call is refused, with the reason. When in doubt, Kern blocks.
Our promises
What we promise before you start.
- The first check works from a description of the agent. It needs no access to your live systems.
- Kern runs on your machines. It needs no internet connection and no database, so nothing leaves your environment.
- Your team decides how sensitive each piece of data is. Kern starts from the strictest setting until you confirm.
- When in doubt, Kern blocks: an unknown tool or unmarked data is refused, never waved through.
- Each step is scoped on its own. You decide the next step after you see the result.
- You keep the map, the proof file and the checker, and your team can re-run the check without us.
What you receive
Four things, all yours to keep.
The result
A proof that sensitive data has no route to the wrong place, or every route that must change, step by step.
The proof file and the checker
So anyone you choose can re-check the result on their own computer.
The gate, tested
Kern in front of the agent's tools in a test setting, showing which calls pass and which are refused.
How to start
Recommended first step
The Kern Pilot
One AI agent, in one setting, mapped, proven and enforced in a test environment in two to three weeks once we have its description. Scope agreed in writing before we start.
The pilot ends with a written review where you decide: approve, approve with the changes Kern named, or stop with the reason recorded.
- Step 1Map the agent. You confirm how sensitive each source is.
- Step 2Prove it. You receive the result and the proof file.
- Step 3Enforce it in a test setting. You see allowed and refused calls.
Agent not built yet? We can check the design before anyone builds it.
Already running agents? Bring the tool list and we start from what they actually do.
Is Kern right for you?
Who it is for
Security leaders in organisations connecting AI agents to email, documents, customer records, browsers or files: banks, insurers, healthcare, government, law firms, and any organisation with data it cannot afford to see leave.
What we need from you
A description of one agent (its tools and connections), someone who knows how sensitive each data source is, one technical owner, and one person who owns the decision.
For each person in the decision
- Security leaderWhich agents to approve, on what conditions, with evidence behind each decision.
- Engineering and platformKern is one small program that sits between the agent and its tools. No new platform, no internet connection, no database.
- Data protectionWhere personal data can and cannot go, shown route by route.
- Risk, audit and insurersThe proof file and the checker, and how to re-run it without us.
- Finance and procurementFixed scope, stage by stage. Each step agreed before it starts.
What Kern works with.
- Agents that call tools through MCPThe Model Context Protocol is the open standard many agents use to connect to tools. Run in front of Microsoft's Playwright browser server and the reference filesystem server.
- Copilot-style assistantsAssistants connected to a mailbox, SharePoint and a CRM, described from their connections.
- Agents that hand work to other agentsWhich agents may ask others to act, and limits on what may be passed along.
- Agents that move moneyKern proves a spending limit holds across a whole session, not just one payment.
- Any agent that can ask firstAn agent that can ask a small local service "may I make this call?" before acting.
Questions we are asked first.
Which agents and tools does Kern work with?
Agents that call tools through MCP, assistants connected to mail, documents and CRM, and agents that pass work to other agents. If yours is different, ask. The method is the same: map, prove, enforce.
What does "whatever the agent reads" mean?
Kern assumes any email, document or web page the agent reads could have been written by an attacker, and checks every route anyway. It does not rely on the agent behaving well.
What if we mark something wrong?
The proof is exactly as good as the map. That is why your team signs off how sensitive each source is, why Kern starts from the strictest setting until you do, and why we review the map with you before any result is given.
What about tools that can run any code?
A tool that runs its own code can reach anything, so no one can prove limits for it. Kern blocks those tools outright and keeps the rest of the agent working.
Does Kern need access to our live systems?
The map and the proof work from a description. The gate runs in your environment, in front of the tools you choose.
Who can re-check the result?
Anyone you give the proof file to. The checker is a separate program that re-does the work in its own code and ignores the result written in the file.
How long does a pilot take?
Two to three weeks for one agent, once we have its description.
How is it priced?
Each step is fixed in scope and agreed in writing before work starts. Price is set out in the written scope, so there are no surprises later.
How Kern works.
Kern starts from a description of the agent: the tools it can call, the data each tool can read, where each tool can send data, and which agents can ask others to act. Your team marks how sensitive each data source is and what each destination may receive. Kern then checks every route through that description, assuming anything the agent reads could have been written by an attacker.
If sensitive data can reach a destination that should not receive it, Kern shows the exact route, step by step, so your team can close it. If it cannot, Kern produces a proof file. A separate checker re-does the work from that file in its own code and confirms or rejects the result, so your auditor or insurer can check it without trusting us. The same rules then run as a gate in front of the agent's tools: allowed calls go through, and any other call is refused with the reason.
Read more: the technical detail
- What the map holds. Agents, tools, data sources with their sensitivity, destinations with what they may receive, and which agents may ask others to act, including limits on what may be passed along.
- How the proof works. Kern turns the map into a finite set of routes, wires every input to every tool that could receive it, and checks the most sensitive data that can reach each destination. Kern has two separate checking methods, and they give the same answer on every case we have run.
- How the proof file is checked. The checker rebuilds everything from the file, ignores the claimed result and reports valid, tampered or unreadable. The file format is written down so an auditor's own team could build their own checker.
- Following a secret through a session. Once the agent reads something secret, Kern tracks that value, and refuses the call if it later tries to send it somewhere public, even through a tool marked as public.
- Money limits. For agents that move money, Kern proves a limit such as "total spent never exceeds reserves" holds across a session of any length, or shows the sequence of payments that breaks it.
- Drafting the map from activity. From a record of what agents actually called, Kern drafts the map and leaves every sensitivity for your team to confirm, set to the strictest until they do.
- How it runs. Written in Rust. It runs offline and needs no internet connection or database. The gate is started from the command line.
Bring us the agent you are being asked to approve.
Email us a description of the agent and what worries you about it. We reply with a pilot plan.
Sovereign