Quickstart
Install the CLI, scan a machine, write one policy, and run an agent with its tool calls governed — in under ten minutes.
This walks through the whole path once, end to end: install, look at what is currently ungoverned, write the smallest policy that says something real, then run an agent through it. Every other page in these docs goes deeper into one of these four steps.
What you'll do
cirvix binary on your machine. No account required for this part.permit and one forbid, in JSON — enough to make a real decision.1. Install the CLI
Pick whichever matches your toolchain — they install the same binary.
$ npx @cirvix/agent-control scan$ # or install it once: npm install -g @cirvix/agent-control$ # then: cirvix scanThe Installation page covers persistent installs, Docker, and Kubernetes.
2. Scan your machine
scan is read-only. It sends nothing anywhere and needs no account — it inventories agent runtimes, MCP server configurations, and credential files reachable from agent context, and reports what is currently unprotected.
$ cirvix scan --deep Cirvix scan · read-only · nothing was changed or sent runtimes 2 found Claude Code ~/.claude/settings.json ungoverned · 3 MCP servers Cursor ~/.cursor/mcp.json ungoverned · 2 MCP servers mcp servers 5 configured github stdio inline secrets filesystem stdio broad scope credentials 2 paths reachable from agent context AWS credentials On disk and readable by any agent with filesystem access findings 3 high · 2 medium ▲ Claude Code (runtime-ungoverned) Tool calls from Claude Code are not routed through a control plane. fix: cirvix gateway --servers ~/.claude/settings.json Nothing was changed. To see how a call would be decided: cirvix check --action fs.read --resource .envscan reads local configuration and prints a report; it does not require the account you'll eventually want for the hosted dashboard.3. Write your first policy
A rule set is an ordered array of JSON rules, and it defaults to deny — nothing is permitted until a rule says so. Start with one narrow permit and one guardrail forbid.
{ "rules": [ { "name": "deny-dotenv-read", "effect": "forbid", "actions": ["fs.read"], "resources": ["**/.env", "**/.env.*"], "reason": "Reading .env files is denied outside an approved secrets flow.", "remediation": "Request the value as a handle." }, { "name": "allow-workspace-read", "effect": "permit", "agents": ["pr-triage"], "actions": ["fs.read"], "resources": ["*"], "when": [{ "path": "path.insideWorkspace", "op": "eq", "value": true }], "reason": "Read inside the workspace root." } ]}Order does not matter here: forbid always wins, so the guardrail cannot be punched through by the permit above it or by any permit added later. Anything neither rule matches is denied, because the set is default-deny.
The Policies page explains the attributes available to a rule; Writing your first policy walks through building one up from nothing.
4. Check it, then enforce it
check evaluates one hypothetical call and executes nothing — the fastest way to confirm a rule does what you meant.
$ cirvix check --policy cirvix.policy.json \ --agent pr-triage --action fs.read --resource .env.production DENY fs.read /repo/.env.production rule deny-dotenv-read reason Reading .env files is denied outside an approved secrets flow. fix Request the value as a handle. considered → forbid deny-dotenv-readThen put the gateway on the wire. The agent talks to Cirvix; Cirvix talks to the real MCP servers, evaluating every call before it is forwarded.
$ cirvix gateway --servers ~/.cursor/mcp.json --policy cirvix.policy.json [cirvix] gateway up · 2 upstream · 2 rules · local policy permit fs.read ./data/input.csv 0.4ms deny fs.read .env.production 0.2ms └─ deny-dotenv-read [cirvix] stopping · 2 calls · 1 permitted · 1 denied · 0 heldWhat just happened
Every one of those two lines is one pass through the decision path: the agent's call was intercepted before it reached the filesystem, evaluated against the policy you wrote, and recorded either way. The denied call didn't crash the agent — it received a structured refusal it can reason about, which is what lets pr-triage re-plan instead of retrying blindly.
scan are open today; the hosted dashboard and team features need an account — see Start.