Kyvvu

ASK · In-process · European

An Agent Security Kernel for AI agents

Kyvvu is an Agent Security Kernel (ASK): an in-process security layer that checks every action an AI agent takes — against the full path of the task so far — and allows, warns, or blocks it before it runs, deterministically, in under a millisecond, without your data ever leaving your environment.

The name carries the idea: every agent has to ASK before it acts.

It's a reference monitor for agent actions — the security model used to confine operating-system processes, applied to AI agents instead: a small, trusted core that checks every action before it runs. Kyvvu runs inside the agent's own process rather than as a separate layer that traffic passes through. Because it sits with the agent, it works the same way however many models the agent uses, whichever ones they are, and wherever they run.

Security first. Governance follows.

Serious organizations worry about security before they worry about compliance. Kyvvu is built that way round. It exists to stop two kinds of harm:

• Data harm — unauthorized access, leakage, exfiltration. An agent reads a customer record, then sends it outside the org.
• Operational harm — an agent that deletes or corrupts data, breaks a process, or takes a destructive action. A finance agent asked to "clean up" a dataset issues a DELETE against a production table.

Both are legitimate actions in a dangerous sequence. Every individual step passes every individual check. The breach is the sequence — and the audit trail that proves you stopped it comes free with the mechanism. You get the right thing done, not just the paperwork that says you did.

Govern agents like microservices — but the new risk is the path

An AI agent is a new kind of workload, and most of governing it is not new. Agents need identities, scoped permissions, secrets management, and a place their logs land — exactly the disciplines you already apply to microservices. Use your existing IAM for identity. Use your existing SIEM for monitoring and incident response. Don't buy a parallel "agent governance" stack to reinvent them.

What is new is that an agent decides its own sequence of actions at runtime, and the danger lives in that sequence rather than in any single call. No IAM policy, no per-step content filter, and no gateway reasons over the full trajectory of a task. That trajectory — the path — is the one genuinely new security surface, and it is exactly what the ASK covers. Everything else, you already own.

See it in action

Most governance tools evaluate each action in isolation. Kyvvu evaluates actions in context — what the agent did earlier in the task determines what it's allowed to do next.

Get started in five minutes

The SDK and engine install with one command. The first 5,000 active instance hours are free — enough to put real agents under enforcement before you talk to anyone.

Get started — read the docs Open the dashboard

pip install kyvvu · first 5,000 instance hours free

How it works

Wrap your agent's actions with the Kyvvu SDK. Every atomic behaviour is modelled as a (step_type, scope, verb) triple and evaluated by the in-process engine before it executes — against the full ordered history of the task, not the isolated step.

from kyvvu import Kyvvu, KyvvuBlockedError, RiskClassification, StepType, Verb

kv = Kyvvu(api_url="https://platform.kyvvu.com", api_key="KvKey-...")
kv.register_agent(
    agent_key="support-agent",
    risk_classification=RiskClassification.HIGH,
    name="Customer Support Agent",
    declared_tools=["call_llm", "lookup_customer", "send_email"],
)

@kv.step(StepType.step_model, Verb.POST)
def call_llm(prompt: str) -> str:
    return openai.chat(prompt)

@kv.step(StepType.step_resource, Verb.GET)
def lookup_customer(customer_id: str) -> dict:
    return crm.get(customer_id)

@kv.step(StepType.step_exec)
def send_email(to: str, body: str) -> str:
    # Blocked by policy unless a human-approval gate precedes it on the path
    return smtp.send(to, body)

Policies are version-controlled YAML manifests in your own git — browse the open-source library — fetched and cached by the engine. No network call per step, sub-millisecond evaluation, path-dependent enforcement. Roll out in warn mode first to watch what your agents actually do, then switch to block to enforce — same manifest, agent by agent.

Three verdicts, one layer

• allow  Proceeds — recorded as a tamper-evident log entry.
• warn  Proceeds, but flags the step for review.
• block  Stopped before it executes, deterministically.

Human approval isn't a fourth verdict — it's a gate step a policy can require on the path (for example, before code execution or a destructive write). PII checks are likewise governed steps on the path, not a separate mechanism.

Where the ASK sits

Each layer of the agent stack does a real job, and you probably already run several of them: gateways handle routing and cost, IAM handles identity, registries handle compliance reporting. They're all worth having. The one thing none of them do is reason over the full sequence of a task while keeping your data in place — and that's the part the ASK adds.

Layer	Enforces	Path-aware?	Data leaves env?
Identity & access (IAM / RBAC)	Access by identity	No	No
Guardrails (I/O content)	Flag / redact / block one message	No	Depends
LLM router / AI gateway	Routing + content policy	Limited	Often (if SaaS)
Credential brokering / MCP	Whether to issue a credential	Per-task	Credentials only
Kyvvu — the ASK	Policy over the path (allow / warn / block)	Yes	No (in-process)

The ASK does two things together: it reasons over the full path of a task, and it keeps sensitive data inside your environment. Doing both at once is what's hard, and as far as we know it's the only approach that addresses the security problem agents actually introduce — the path. Everything else stays in place.

Security that scales means data stays put

Running agents at scale needs security that scales with them — across cloud, local, embedded, on-device, air-gapped, and multi-model setups, all handled the same way. Because the engine runs in-process, only your policy crosses the boundary, and it lives in your own git. Prompts and data stay inside your perimeter, so there's no extra network hop, no data-residency question, and nothing to depend on staying up. We're a European company, and since nothing is sent to a vendor to be processed, this fits naturally with teams that have data-sovereignty requirements.

How it fits together

Two audiences, one in-process runtime:

1. Developers integrate their agent via the SDK (Python, LangChain, LangGraph), a connector (Microsoft Copilot Studio, MS Agent SDK), or the local engine.
2. CISO and legal teams author policy as version-controlled YAML.

The Kyvvu Engine evaluates each behaviour against the policy library and returns the verdict to the agent — allow, warn, or block — in its own process. The hash-chained behavioural trace is shipped to the SIEM you already run; agent identities come from the IAM you already run.

Works with the frameworks you already run

Kyvvu is framework-agnostic, with documented integrations for:

• Core Python agents (the @kv.step decorator)
• LangChain and LangGraph (callback handlers)
• Claude Code (local engine)
• Microsoft Copilot Studio and MS Agent SDK (connector)
• Any other framework — via the locally running kyvvu-engine and REST API

Compliance comes free

Because every action is checked, recorded, and enforced at the step level, the ASK automatically produces the runtime evidence the EU AI Act asks for — supporting Art. 9 (risk management), 12 (record-keeping), 14 (human oversight), and 15 (accuracy & robustness). It's a mechanism, not a document — and a by-product of the security and operational control that is the real reason to deploy. You don't need a specialized agent-governance tool to file it: send the data to the SIEM and controls you already operate.

See how policies on paths map to the AI Act →

The white paper

Building Secure Agents at Scale — a slightly weird white paper on agent security. What AI agents are, what actually makes them dangerous, and the full menu of approaches to securing them (isolation, access control, prompts, gateways, guardrails, and runtime enforcement) — what each does well, and where each stops. It is deliberately not a marketing leaflet: every claim about Kyvvu sits inside a clearly-marked box, and you can skip all of them and still come away with a better map of the field.

Written with feedback from senior security, risk and AI leaders at the Belastingdienst, ING, Rabobank, Arcadis, Datashift and Valcon.

Read the white paper → Download the PDF

The one-pager

A single-page overview of the Agent Security Kernel — the risk your stack can't see, the three verdicts, the architecture, and how to start.

Download the ASK one-pager (PDF)

Where we are

Kyvvu is deployed in enterprise environments across regulated industries in the Netherlands — financial services, insurance, healthcare — enforcing on agent behaviour in production. Our approach is documented in the arXiv paper Runtime Governance for AI Agents: Policies on Paths, and is aligned with Anthropic's Zero Trust for AI agents framework (May 2026) — the ASK is a privacy-first, in-process realization of its "verify every action" principle.

Talk to us

Kyvvu is delivered through a small set of authorized partners — tier-1 consultancies and AI governance specialists who handle integration, policy design, and ongoing support. We work alongside them on every deployment.

Technical questions, integration details, and research: maurits@kyvvu.com

About Kyvvu

Kyvvu is a European company building the Agent Security Kernel — runtime security infrastructure for governing autonomous AI agents in regulated industries. Founded by Maurits Kaptein and Jeroen Ghijsen, based in the Netherlands.

Learn more about us or see open positions.