Ask before you act.

What this is

When an agent works inside the Cirvix console, it can call these tools directly rather than trying to read the interface. They register through navigator.modelContext when the browser supports WebMCP, and they carry your signed-in session — nothing more.

That last point is the whole security model, and it is structural rather than a check we perform. Five of the six tools are thin wrappers over the same authenticated client the console itself uses, so a tool cannot reach anything you could not already reach by clicking. Authentication, scopes, capability gates, tenant isolation, rate limiting and audit all happen where they already happened. Signed out, every tool that touches your data refuses.

Why evaluate_action is advisory

Cirvix does not authorize actions over HTTP. Enforcement is local — in the engine sitting in front of the agent — so that losing the network costs you telemetry rather than control. A browser tool that returned ALLOW would either be lying about its authority, or would have required building the remote authorization hop the architecture deliberately avoids.

So the tool answers a different question, and says so in every field it returns:

{
  "mode": "ADVISORY",
  "result": "WOULD_REQUIRE_APPROVAL",
  "authorizationGranted": false,
  "risk": "HIGH",
  "policyId": "PROD-DEPLOY-004",
  "policyVersion": 7,
  "reason": "Production deployment requires human approval.",
  "action": "k8s.apply",
  "actionSource": "derived from tool name",
  "notEvaluated": ["command", "secrets", "session.touchedSecret", "real-workspace-paths"],
  "evaluationId": "adv_0b2e5188b4de11f7"
}

There is no bare ALLOW in the vocabulary. The four results are WOULD_ALLOW, WOULD_ALLOW_WITH_CONDITIONS, WOULD_REQUIRE_APPROVAL and WOULD_DENY, and an outcome the tool does not recognise becomes WOULD_DENY rather than something permissive — the safe reading of “I do not understand this” is not “proceed”.

It runs the real engine

The analysis is not a lookalike written for the website. assets/policy-engine.js is generated from the runtime’s own source by tools/build-engine.mjs, and the decision sequence — classify, evaluate, escalate for risk — is the one Guard.authorize() performs.

Copies drift, so a conformance run puts 1,050 cases through both the browser path and the genuine runtime Guard, and fails the build if the verdict, decision, rule or risk ever differ. That corpus also pins how a tool name maps to an action, which is not the identity: a tool called deploy_production classifies as k8s.apply.

Which is why the tool prefers a tool name over an action string. Give it the name of the tool you would really call and the analysis describes your actual call; give it an action the runtime would never derive and you get a confident answer about a different one. The response echoes action and actionSource so the mismatch is visible rather than silent.

What it cannot see

An advisory analysis has less information than enforcement, and the tool names the gap rather than papering over it. Every entry in notEvaluated is a rule predicate that could not be evaluated:

Each of those can only make the analysis more permissive than enforcement, never less. That is tolerable precisely because the output is advisory: a WOULD_ALLOW the runtime later denies costs an attempt, not a breach. It would not be tolerable in something that granted permission — which is the second reason this tool does not.

The other five tools

A record belonging to another organisation answers exactly as one that does not exist, so the tools cannot be used to confirm an id exists somewhere. Plan gates report the plan, never the record.

A worked flow

The intended shape is ask, then act or escalate — never ask and treat the answer as a grant.

// 1. Before deploying, ask what policy would do.
cirvix_evaluate_action({ tool: "deploy_production", resource: "prod/api" })
// -> WOULD_REQUIRE_APPROVAL, PROD-DEPLOY-004, authorizationGranted: false

// 2. Not a refusal — a routing instruction. Escalate to a human.
cirvix_request_approval({
  action: "k8s.apply", resource: "prod/api",
  justification: "Release 2.1.0, changelog reviewed",
  evaluationId: "adv_0b2e5188b4de11f7"
})
// -> status: "pending". A person decides. Still not authorized.

// 3. Act only when the runtime lets you — enforcement is local, and it
//    is the engine in front of the agent that permits the call.

Availability

The tools register automatically in a browser that exposes navigator.modelContext. In a browser that does not, they are defined and inert — nothing is missing from your account, and the console says so plainly rather than implying a feature is broken. The Agent Interface section of the console shows what is registered in the browser you are actually using.