GVNR and Enforcer
Coming soon. Today GVNR is for personal use: it decides and records on your own machine. This page describes what team use will add.
GVNR makes every decision on the machine it runs on: the rules, the spend and rate limits, the loop check. That does not change when you sign in. What signing in to an Enforcer workspace adds is one record for the whole team. One sign-in covers GVNR and the Enforcer MCP server:
/enforcer:login ACME-1234-ABCDThe workspace code is optional. With it, the sign-in page opens straight on your workspace.
Each install ships its receipts in the background after each session, signed in as the person using it. The governance console then answers the questions a team actually asks:
The record is tamper-evident: the workspace can recompute each install's hash chain on its own, and an edited or missing line shows. The Enforcer MCP server's governance tools let you ask Claude the same questions.
Optionally, /enforcer-governor:telemetry on also sends Claude Code's own OpenTelemetry (cost, tokens, tool use, never prompt text), so the console also shows Claude Code's own cost and token figures.
| What | When | Switch |
|---|---|---|
| Decision receipts: verdict, rule, tool, model, tokens, project, operator. Never command text, file contents or prompts. | After each session, once signed in | shipOn |
| Policy questions, naming the rule, not the command | Only when a rule matches | policyOn |
| Claude Code's OpenTelemetry | Only if turned on | /enforcer-governor:telemetry |
Everything goes to the workspace you signed in to and nowhere else. /enforcer:login logout stops all three.
Two controls let an organisation change the decisions themselves. Both are off until an admin sets them up: a workspace starts with no agent policy and no managed settings, so every decision stays the plugin's own until then.
When a rule matches, GVNR asks your workspace's policy about it: a resource of type agent_action whose id names the rule, such as fs.delete_tree or deploy.publish. With no policy for agent_action, the answer is silence and the local rule decides. Policies are Rego, versioned and rolled back by activating the previous version:
declared_types := ["agent_action"]
allow if { input.resource_type == "agent_action" }
deny contains "agents in this tenant do not delete whole directory trees" if {
input.resource_type == "agent_action"
input.resource.id == "fs.delete_tree"
}
deny contains "ask: publishing from an agent needs a person to confirm" if {
input.resource_type == "agent_action"
input.resource.id == "deploy.publish"
}A policy can make a rule stricter or waive a confirmation. It cannot lift a hard deny (curl | sh stays refused) and cannot skip a rewrite. If the workspace is slow, down or you are signed out, the local rule decides alone, so losing the network never allows more. Only a matched action is asked about; ordinary tool calls never wait on the network.
An admin can publish limits and checks for every install. Each machine applies whichever is stricter, its own or the organisation's, and a check the organisation turns on cannot be turned off locally. See Configure.
GVNR asks one question: may this agent do this, right now? Enforcer is Instruxi's identity and authorization service, and asks the same question inside your own applications, for users, tenants, services and agents calling your API, with a reason for every answer. Try the sandbox.