For the complete documentation index, see llms.txt. This page is also available as Markdown.

Your First Agent

What you'll learn: How kyvvu init works, what the demo agent does, and how to read the policy evaluation output.


Scaffold a project

kyvvu init my-agent

This scaffolds project files — agent.py, requirements.txt, .env.example, .gitignore, and README.md. No authentication is required.

The output looks like:

✓ Created my-agent/

Next steps:

    cd my-agent

    # Install requirements:
    pip install -r requirements.txt

    # Set your key:
    # (run `kyvvu register` if you have none)
    cp .env.example .env       # add your KV_API_KEY
    # or: export KV_API_KEY=your-key

    # Run the agent:
    python agent.py

To assign compliance policies, go to the dashboard:
    Manifests page → select a manifest → assign to your agent
Or use the CLI:
    kyvvu list-manifests
    kyvvu assign-manifest --agent-id <id> --repo-id <id> --manifest <path>

Caching: register_agent() results are cached locally at ~/.kyvvu/registrations/. If you call it on every startup with the same parameters, the SDK reuses the cached registration without a network call. You can safely call register_agent() every time your agent starts.

Data minimization: By default, only your agent's opaque ID and operational fields (risk classification, environment, declared tools) are stored in Kyvvu's cloud. Descriptive metadata (name, purpose, owner) is not persisted server-side. Pass store_metadata=True to opt in to storing metadata on the platform.

Assign compliance policies

Policies are managed via manifests — YAML files stored in a GitHub repository. To assign policies to your agent:

  1. Go to the Manifests page in the dashboard

  2. Connect a repository containing manifest files (or use the default Kyvvu/manifests repo)

  3. Click Assign on a manifest and select your agent

Or use the CLI:

See Manifests for details on manifest structure and available policy sets.

Run the demo agent

The full agent.py source:

It starts a task, calls all three steps, and the third one gets blocked:

What happened

The @kv.step decorator wraps each function call in a three-phase cycle:

  1. Evaluate — the engine checks the intended behaviour against all applicable policies. It reads the task's history to make path-dependent decisions.

  2. Execute — if the evaluation returns allow or warn, the function runs.

  3. Record — the completed step (with output) is appended to the task's history for future evaluations.

Steps 1 and 2 passed for call_llm and fetch_user_data. When run_script was evaluated:

  • The engine identified it as step.exec (code execution).

  • The OWASP policy "Code execution requires a preceding gate" checked whether a step.gate existed earlier in the task history.

  • No gate was found. The policy has severity critical, so the engine returned block.

  • The decorator raised KyvvuBlockedError instead of executing the function.

Inspect the policies

This shows policies assigned to your agent via manifests. If no manifest has been assigned yet, the list will be empty.

Each policy is an instance of a rule with specific parameters. For example, "Code execution requires a preceding gate" uses the step_requires_gate rule with target_step_types: ["step.exec"]. The same rule backs "Destructive resource ops require a gate" with different parameters (target_step_types: ["step.resource"], target_verb: "DELETE").

For the full details of each OWASP policy, see OWASP Default Manifest.


Next steps

Last updated