Skip to main content

cirvix

Runtime governance for Python AI agents. Every tool call is evaluated against policy before it executes.

Zero dependencies. Standard library only, permanently — the same reason the Node package has none.

pip install cirvix

Full documentation: docs/Python SDK, policy reference, quickstart.

Governing an agent

from cirvix import guard, CirvixDenied, CirvixHeld

tools = guard.wrap(
    my_tools,
    agent="pr-triage",
    environment=os.environ.get("CIRVIX_ENV", "local"),
    rules=rules,
)

try:
    crew.kickoff()
except CirvixHeld as held:
    print(held.approvers)     # ["platform-oncall"] — this call is waiting
except CirvixDenied as err:
    print(err.policy)         # "deny-dotenv-read"
    print(err.remediation)    # 'secrets.get("STRIPE_KEY")'
    print(err.decision_id)    # pass to `cirvix why`

wrap accepts the shapes Python tool collections actually come in and returns the same shape:

It accepts Framework
A mapping of name -> callable hand-rolled loops, AutoGen function maps
A sequence of objects carrying func LangChain
A sequence of objects carrying _run CrewAI
A single callable anything

Async tools stay async. Tool objects keep their descriptions and schemas, and the list you passed in is left alone — a framework holding the originals does not find them governed by surprise.

CirvixDenied vs CirvixHeld. A denial means re-plan. A hold means this exact call may still happen once a person says yes. They are separate types because collapsing them teaches an agent to treat both as failure.

Why this is a real evaluator and not an HTTP client

The easy version of this package asks a control plane over the network for every decision. That would have been a fraction of the work and it would have been wrong twice over: it puts a round trip in the enforcement path, and it breaks the offline-first property the whole product rests on — a control plane that stops enforcing when the network blips is worse than none, because the failure is invisible.

So this is a native port. Which raises the real risk: two engines that can silently disagree are worse than one engine and an honest gap. An agent denied by the Node gateway and permitted here is a bypass nobody would find until it mattered.

What makes it safe is packages/conformance/policy-conformance.json. Both engines load that file and must produce identical verdicts, rules, canonical resources, and rule traces across 44 cases — forbid short-circuiting, hold outranking permit, default deny, glob semantics, path traversal, URL normalization, every comparator, and the fail-closed behaviour for unknown ones. Neither language gets a private copy, and changing behaviour means changing the fixture first, in a commit a reviewer can see.

It has already earned its keep: writing it surfaced a bug where the Node engine canonicalized /etc/passwd to C:/etc/passwd on Windows, so a rule written resources: ["/etc/**"] silently did not match on the machine it was most likely written to protect.

python -m unittest discover -s tests

Testing a policy like code

from cirvix.testing import evaluate, expect_no_loosening

def test_production_writes_are_held():
    decision = evaluate(
        policy_dir="./policies",
        agent="deploy-bot",
        action="k8s.apply",
        resource="production/checkout",
        context={"environment": "production"},
    )
    assert decision.verdict == "hold"
    assert "platform-oncall" in decision.approvers

expect_no_loosening(before=…, after=…, calls=…) reports any call a policy change would newly permit. Tightening passes — a security policy is allowed to move that way without surprising a reviewer.

What wrap does not do

The MCP gateway governs everything an agent does, including tools added after you deployed it, because it sits on the wire. wrap governs a list. You keep the same engine, rules, decision records, and audit chain; you give up coverage of tools you did not enumerate.

If your agent speaks MCP — Claude Code, Cursor, or anything else — use the gateway instead:

cirvix gateway --servers ~/.cursor/mcp.json

Status

Pre-release. The policy engine, guard.wrap, and the testing helpers work today. Not yet in this package: secret-handle brokering and telemetry shipping, both of which the Node SDK has — until then, point Python agents at the gateway if you need those.

Release files for cirvix 0.1.5

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for cirvix 0.1.5
File Size Uploaded
cirvix-0.1.5.tar.gz 30.6 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for cirvix 0.1.5
File Interpreter ABI Platform
cirvix-0.1.5-py3-none-any.whl Python 3 none any Details

Total release size:60.3 kB

Release files / cirvix-0.1.5.tar.gz

Download URL cirvix-0.1.5.tar.gz
Size 30.6 kB
Tags Source
SHA-256 checksum
How to use checksums
80b06d4327280451331c4796f21166a2e56099641e253446073d42067fb9a837
BLAKE2b-256 checksum
How to use checksums
0a56309dab209d878a050e8f67679d72bf61a5ecf4e129370b063ad5e5c5e515
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 15, 2026.

Transparency log

Release files / cirvix-0.1.5-py3-none-any.whl

Download URL cirvix-0.1.5-py3-none-any.whl
Size 29.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
6e35822e698370b5dc0294931d088bc436e2d24d4b8622998d4128bf63e35177
BLAKE2b-256 checksum
How to use checksums
913880bc7f0b0add2078ec7525ad1e77bfd858889c005395ac0138a8468ffaeb
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 15, 2026.

Transparency log

Release history Release notifications | RSS feed

0.2.5

2 release files

0.2.4

2 release files

0.2.3

2 release files

0.2.2

2 release files

0.2.1

2 release files

0.2.0

2 release files

This release

0.1.5 This release

2 release files

0.1.4

2 release files

0.1.3

2 release files

0.1.2

2 release files

0.1.1

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page