Enforce
Policy Engine
Authorization is an ordered set of JSON rules evaluated by a deterministic engine: forbid always wins, a hold outranks a permit, and anything unmatched is denied. Rules are versioned, diffable, and evaluated identically in the CLI, in CI, and at runtime.
The problem
Permissions for agents get written as if-statements scattered through application code. Nobody can answer 'what is this agent allowed to do' without reading every call site, and no auditor will accept the answer.
Capabilities
How Policy Engine works
- 01
One evaluator everywhere
The same policy set decides in local development, in a pull-request check, and in production. A rule cannot pass review and then behave differently at runtime.
- 02
Attributes, not just roles
Decisions read agent identity, tool, resource, environment, data classification, time, and prior approvals — so 'read-only in prod, read-write in staging' is one policy, not two deployments.
- 03
Approval as an outcome
A policy can resolve to `permit`, `forbid`, or a requirement for named human sign-off, which is what makes graduated autonomy expressible at all.
- 04
Change control
Every policy change is a reviewable diff with a simulation against recent traffic, so the blast radius is known before merge rather than discovered after.
In practice
What it looks like
{ "rules": [ { "name": "deny-exfiltration-after-secret", "effect": "forbid", "actions": ["http.request", "net.*"], "resources": ["*"], "when": [ { "path": "egress.external", "op": "eq", "value": true }, { "path": "session.touchedSecret", "op": "eq", "value": true } ], "reason": "This session read secret material, so external egress is blocked for the rest of it." }, { "name": "hold-production-writes", "effect": "hold", "actions": ["db.write", "db.migrate", "k8s.apply"], "resources": ["*"], "when": [{ "path": "environment", "op": "in", "value": ["production", "prod"] }], "approvers": ["data-oncall"], "reason": "Held for a named human. The call waits rather than failing." }, { "name": "allow-read-only-tools", "effect": "permit", "actions": ["*.read", "*.list", "*.query"], "resources": ["*"], "reason": "Read-only tool call." } ]}Limits
What this does not do
- The engine decides authorization; it does not inspect payload semantics. A permitted query that returns more rows than intended is a query design problem, not a policy outcome.
- Policy quality is your responsibility. Cirvix ships a starter set and flags unreachable or shadowed rules, but a permissive rule you wrote will be honoured.
- Simulation replays historical calls against a candidate policy. It predicts behaviour on traffic you have already seen, not on traffic you have not.
Get started
Let the agents do real work.
Start with the free local scanner — it needs no account and tells you what is already ungoverned on your machine. Move to a governed runtime when you are ready.
Cirvix AgentControl is in private beta. Pricing is published and plans are not yet chargeable — early access confirms your place and we will tell you before anything bills.