Building the agent takes a week.
Getting it into production takes a quarter.
Not because the agent is hard. Because of everything underneath it. The model. The harness. The isolation. The layer that stops it doing damage. That's four vendor decisions, four security reviews and four data-residency conversations. The Secure Agent Toolkit is that whole stack, already assembled.
One email, when there's something worth showing you.
No sequence, no newsletter. One reply and you're off the list, no reason needed.
Three sentences from the last agent project
The prototype is never the problem. Teams get an agent doing something impressive in days. Then it meets the organisation.
"The demo took a week. The review took a quarter."
Model provider, orchestration framework, sandboxing, secrets, logging, content filters. Six decisions, six threat models, six data-residency questions — for infrastructure that is not your product and that every one of your competitors is also rebuilding.
"Legal won't let this data reach a US model provider."
So the obvious model is out. The open alternatives mean you now run inference yourself — GPUs, scaling, uptime, someone on call — before you've shipped anything a customer can see.
"It works. Nobody will let it run unattended."
An agent that only acts when a human watches is a demo. The moment it holds real credentials and decides its own next step, someone has to be able to say exactly what it can and cannot do — and prove it afterwards.
None of that is your product. All of it is on your roadmap. The toolkit exists to take it off.
Four parts. One thing to adopt.
Everything under your agent, chosen to work together and shipped as one stack — so the security review happens once, not four times.
A private model, hosted in Europe
Your choice of open-weight and hosted models, served from European datacentres by European providers. You don't run GPUs and you don't send your data to a US hyperscaler.
Your prompts and your customers' data are not shared with model vendors and are not training anyone's next model.
An agent harness worth extending
Tools, memory, task state, retries — the scaffolding every team writes and then regrets. Open, small enough to read in an afternoon, and built to be extended rather than worked around.
A sandbox your agent actually runs inside
Operating-system level isolation, scoped credentials, encrypted state — enforced by the kernel of the machine, not by asking the model nicely. It runs in your own infrastructure.
Built on SHADI, open work from the Linux Foundation's AGNTCY project, rather than something we reinvented.
Every step checked before it runs
Each action the agent attempts is evaluated against everything it has already done in this task, and allowed, warned or blocked — in the agent's own process, before it executes.
This is Kyvvu's core product. It ships today via pip install kyvvu. The rest of the toolkit exists because customers kept asking what to put around it.
Take all four, or take one. The parts are separable on purpose — plenty of teams will already have a model they like, and that is fine.
What it looks like once it's yours
The rules come with it
Most agent projects discover the rules they needed after something goes wrong. The toolkit ships policy sets for the patterns teams actually build, so you start from a sensible default and change what doesn't fit.
- Customer service Refund and credit limits that hold across a whole conversation, not just per action. No sending customer data outward after reading a record.
- Personal and internal assistants Read widely, act narrowly. Calendar, mail and document access without the ability to send, delete or share on its own initiative.
- Back-office and operations No destructive write to a production system without a human approving it first. Nothing outside the systems the agent declared at startup.
- Anything you build yourself The defaults are readable sentences you edit, version and review like any other change — not a vendor console you file tickets against.
The point of checking the path rather than each action alone is that most real failures are made of individually reasonable steps:
# every refund is under the €250 limit. every one is to a real customer.
refund €180 ticket 4471→ ALLOW
refund €95 ticket 4472→ ALLOW
refund €210 ticket 4473→ ALLOW
# ... 197 more, all individually fine ...
refund €140 ticket 4671→ BLOCKED
↳ running total for this task exceeds the daily ceiling
identity permitted every one · checks approved every one · the breach is the sequence
Your coding agent writes it. Ours makes it safe to ship.
Your developers are already building with Claude Code, Cursor or Copilot, and that is how agents will get built from here. So the toolkit is written for that: documented so a coding agent can read it, structured so a coding agent can extend it, with worked examples it can start from rather than invent around.
In practice: you describe the agent you want, your coding agent assembles it on top of the toolkit, and the model, the sandbox and the security kernel are already underneath. The generated code is the part that changes. The floor under it doesn't.
What exists today, and what doesn't
This is a waitlist, not a signup — and the difference is deliberate.
- The security kernel is real and in production. Running today at organisations in financial services, insurance and healthcare. Not a plan.
- The runtime is open work we are integrating. SHADI exists and is public. Our job is making it a five-minute decision instead of a two-week one.
- The harness and the hosted model are being assembled now. With partners, and with the first teams on this list.
We would rather tell you that plainly than sell you a launch date. Join the list and we will come back when there is something you can put your hands on — with what it costs, which we also don't know yet.
Four questions. No commitment.
Tell us what you're building and we'll come back when there's something to try. What people put in this form is what we prioritise — so it's worth a sentence.
Questions we get asked first
- Isn't this just open-source components in a box?
- Partly, and on purpose. The sandbox is open work from the Linux Foundation and we would be foolish to rewrite it. What we add is the security kernel, the policy sets, the European inference, and the unglamorous work of making four things behave as one. If you would rather assemble it yourself, everything we build on is public — you genuinely can.
- Can we take just one part?
- Yes. Most likely you already have a model you like, or a framework you've committed to. The security kernel works underneath what you have; the toolkit is for teams who would rather not make those four decisions at all.
- Which models can we use?
- Open-weight models served from European infrastructure, and hosted European models. The specific list is one of the things we are settling with our partners — tell us what you need on the form and it counts.
- Does our data reach you, or the model vendor?
- The harness, the sandbox and the security kernel run in your own environment. Inference is the one thing that leaves, it goes to European datacentres, and your prompts and data are not shared with model vendors or used to train anything.
- Can we run all of it ourselves?
- That's the intention, including inference for teams that need it. Say so on the form — how many people ask for it decides how early we support it properly.
- What will it cost?
- We don't know yet, and we would rather say that than invent a number. Nobody on this list will be charged for anything without being told first.
- When?
- No date, deliberately. The kernel ships today; the assembled toolkit does not. You'll hear from us once, when there is something real to put your hands on.
Kyvvu is an Agent Security Kernel — a security layer that runs inside AI agents and checks every action, against the full path of the task, before it runs. Built on Runtime Governance for AI Agents: Policies on Paths — Maurits Kaptein, full professor, Eindhoven University of Technology. European company; your data stays in your environment.