Kyvvu¶

The Agent Security Kernel (ASK) for AI Agents. Every agent has to ASK before it acts.

Kyvvu is an Agent Security Kernel (ASK): an in-process security layer that evaluates each action against the agent's full task path — before the step runs — to stop data leakage and destructive actions. Runtime governance follows. It decides allow, warn, or block in sub-millisecond time, directly inside your agent process. No proxy. No gateway. No perceptible latency.

The first 5 minutes¶

uv tool install kyvvu-cli

kyvvu try

That is the whole first minute. kyvvu try evaluates a four-step demo agent against the frozen baseline bundled inside the package, warns on its unmarked delivery of model output and blocks its ungated code execution — no account, no API key, nothing on the network. Everything below is what an account adds on top.

kyvvu auth
# → logs in via a device code; prints a code + URL to approve in your browser

# then, get an API key: open the dashboard, go to Workspace → API Keys

kyvvu init my-agent
# → scaffolds a demo agent project

cd my-agent
pip install -r requirements.txt
export KV_API_KEY=KvKey-...
python agent.py

The demo agent runs four decorated steps (a resource read, a model call, a reply that delivers the model's answer, and a code execution) — and it is governed from the first one. Registering an agent applies Kyvvu's bundled baseline automatically: 15 policies, OWASP Top 10 for Agentic Applications plus EU AI Act minimal risk, with nothing to assign and no repository to connect.

So the OWASP policy "Code execution requires a preceding gate" blocks the step.exec on the very first run:

Policy blocked this step: ...
   Risk score: 1.00
   Action:     block
   * Code execution requires a preceding gate (critical)

That's runtime policy enforcement — evaluated against the full task history, before the step runs rather than after.

To layer more on top, assign a manifest that does not overlap the baseline. The public library is already connected to every new workspace, so there is nothing to set up first:

kyvvu list-manifests
kyvvu assign-manifest --agent-id <agent key or id> --repo-id <id> \
    --manifest manifests/operational/demo.yaml

It prints the new assignment id; kyvvu unassign-manifest --assignment-id <id> removes the manifest again, and kyvvu list-assignments lists the ids.

That one layers cleanly on the demo agent. Some do not as published: manifests/security/data-exfiltration-guard.yaml blocks the demo's first step, because its allowed_domains are placeholders and a step with no target host fails closed. Copy it into your own repository with your real domains first.

Assigning manifests/security/owasp-agentic-default.yaml instead is refused with a 409, because the baseline already assigned that manifest, which is the platform telling you that you have it. The CLI prints the reason on one line and exits 1:

Error (409 manifest_already_assigned): Manifest 'OWASP Top 10 for Agentic Applications - Default Security Template' is already assigned to this agent at 'kyvvu-manifests-public/manifests/security/owasp-agentic-default.yaml' (assignment 9).

For why this architecture matters, see the blog post: The Hot Path Tax.

Architecture¶

Your Agent Code
  |  @kv.step / LangChain handler / REST API
  v
kyvvu Python client (translates events -> Behaviors)
  |  template.match() -> deep_merge -> Behavior
  v
kyvvu-engine (in-process, sub-ms policy evaluation)
  |  evaluate() -> allow / warn / block
  |  record() -> append to task history
  |  end_task() -> queue the behavioral trace for delivery
  v
Kyvvu Platform API (platform.kyvvu.com)
  |  policy storage, incident management, audit trail
  v
Dashboard (platform.kyvvu.com)
  |  manifest assignment, incident triage, reports

The engine runs in your process. Policy evaluation is pure CPU - no network calls, no database queries, no I/O. Policies are fetched in the background and cached. Trace delivery happens asynchronously in a background worker after the task ends.

What Kyvvu does¶

1. Registration enforcement - agents declare their name, purpose, owner and risk classification when they register. Policies validate these declarations at startup, and the tools an agent declares are what the allowlist policy checks each step against.

2. Runtime policy evaluation — every atomic step your agent takes is evaluated against loaded policies before execution. Decisions depend on the full ordered history of the current task ("policies on paths").

3. Behavioral trace logging - completed steps are recorded into an audit trail, queued for delivery to the platform API when the task ends. The trace is a structured JSON record of everything the agent did.

4. Incident management - policy violations generate incidents that surface in the dashboard for triage and resolution. An incident is created for each step that violates a policy.

Quick links¶

Next steps¶

• Installation — install the Python client and set up your account
• Your First Agent — walk through kyvvu init step by step
• Architecture — understand the package split and why the engine is in-process
• Creating Policies — author your first custom policy