kitelogik compliance

Audit your policy bundle against four structural checks and report how it maps to the OWASP Agentic Security control list. Designed for the conversation with your security team — runs locally, prints a deterministic report, exits cleanly.

Synopsis

kitelogik compliance [--path PATH]

Flag	Default	Meaning
--path PATH	auto-discover	Path to a policies directory

What it checks

1. Default-deny posture

Every non-main.rego policy file should declare default deny or default allow at the package level. A file with neither defaults to "unmatched input → undefined" — which composes badly when main.rego aggregates results. The check reports any file missing a default declaration.

2. Governance event coverage

Five event types are recognised: tool_call, agent.spawn, agent.delegate, agent.plan, agent.budget. The check scans the bundle for explicit references to each. tool_call is implicitly covered (it's the default event type for policies without an event_type filter). The other four are reported as covered if any policy file mentions them by name.

3. Test coverage

Every <module>.rego should have a paired <module>_test.rego in the same directory. The check reports any module that doesn't — main.rego is excluded from the count since it aggregates rather than implements rules.

4. OWASP Agentic Security controls

Maps presence of relevant policies / fields to the 10 OWASP Agentic Security controls (ASI-01 through ASI-10) and reports each as COVERED or GAP. Detection heuristics:

Control	COVERED if
ASI-01 Tool Call Authorization	tool_call event type covered
ASI-02 Agent Identity & Auth	bundle references session_id or token
ASI-03 Excessive Agency Prevention	agent.plan event type covered
ASI-04 Privilege Escalation	bundle references delegation
ASI-05 Resource Abuse	agent.budget event type covered
ASI-06 Prompt Injection Defense	a policy file is named sanitize* or security*
ASI-07 Data Exfiltration	bundle references resource_path
ASI-08 Agent Lifecycle Control	agent.spawn event type covered
ASI-09 Audit & Observability	main.rego exists in the bundle
ASI-10 Multi-Agent Governance	agent.delegate event type covered

These are presence checks, not depth checks. A COVERED here means "the bundle has policies that touch this control area", not "this control is exhaustively addressed".

Example output

Kite Logik Compliance Check — /home/me/my-agent/policies

  Policy files:  8
  Test files:    7

  PASS  Default-deny posture: all policy files declare defaults
  PASS  Event coverage: all 5 governance event types covered
  WARN  Test coverage: 1 policy file(s) have no test: custom.rego
  PASS  OWASP Agentic Security: 9/10 controls addressed

  OWASP Agentic Security Controls:
    [COVERED]  ASI-01 Tool Call Authorization
    [COVERED]  ASI-02 Agent Identity & Auth
    [COVERED]  ASI-03 Excessive Agency Prevention
    [COVERED]  ASI-04 Privilege Escalation
    [COVERED]  ASI-05 Resource Abuse
    [    GAP]  ASI-06 Prompt Injection Defense
    [COVERED]  ASI-07 Data Exfiltration
    [COVERED]  ASI-08 Agent Lifecycle Control
    [COVERED]  ASI-09 Audit & Observability
    [COVERED]  ASI-10 Multi-Agent Governance

  Result: 3 passed, 1 warning(s). Review warnings above.

Exit code

compliance always exits 0 on a successful audit run — even when issues are reported. The exit code reflects whether the check itself ran, not whether your bundle is gap-free. Pre-flight failures (no policies directory, no .rego files) exit 1.

This is deliberate: compliance is a reporting tool. If you want a CI gate that fails on warnings, parse the output (or open an issue — a --strict flag is reasonable to add).

What it does NOT validate

• Rule semantics. compliance doesn't run your rules. Use test for behavioural assertions and check for one-off dry-runs.
• OPA bundle correctness. compliance reads files and pattern-matches. Run validate first to catch parse errors.
• OWASP control depth. A COVERED result means a relevant artefact exists, not that it's correctly implemented. Treat the audit as a structural smoke test — pair it with policy review and tests.

When to run it

• Before a security review — generate the report and walk through any GAPs with the reviewer.
• In CI on policies/ changes — the report is short; commit it to a known location and diff over time to catch regressions.
• After adding a new policy module — confirms test coverage and that the new module didn't accidentally drop default-deny.

Related

• validate — run first to surface parse errors with a clear message
• test — behavioural assertions; complement to the structural audit here
• Governance events — the 5 event types this check looks for