The four questions at the heart of the blueprint, answered with evidence.
In September 2026 twelve vendors, among them Okta, AWS, Google Cloud, CrowdStrike, Databricks and Salesforce, published Governing Agentic Execution, an open reference architecture for securing AI agents. It is built around four questions. Where are my agents? What can they do? What are they doing? How do I respond? This page maps Vorim onto each one, plainly, including the parts Vorim does not do.
Vorim is not a member of the Blueprint Alliance yet. The architecture is published for open use and our customers will be asked about it, so we map to it here.
What the paper asks for, what Vorim ships, what sits beside it.
The architecture is a stack of many products, not one. Vorim is the identity, permission and evidence layer in it. Gateways, endpoint tools and network controls do the rest, and we say so below.
Where are my agents?
An agent directory where every agent has a cryptographic identity, an accountable owner, a class (autonomous, on behalf of a person, orchestrator, sub-agent), a lifecycle status and a risk tier. Discovery of unregistered agents across cloud, network, endpoint and browser.
Every registered agent gets an Ed25519 keypair and a public id, an owner, a status (active, suspended, revoked), scoped capabilities, a class and a risk tier on its record, and a public trust page anyone can check without asking us. Short-lived sub-agents get ephemeral did:key identities that expire on their own.
Shadow AI discovery on your network, endpoints and browsers. Vorim is the directory those tools hand agents to once found, not the scanner.
What can they do?
Access scoped to the task rather than standing, time-bound grants, delegation where a sub-agent's authority is the intersection of its own and its delegator's, separation of duties, and contingent review when an action crosses a financial threshold.
Seven independent scopes with rate limits and expiry per grant. Delegation chains computed as the intersection of grants, capped in depth. Separation-of-duties conditions in policy rules. Threshold rules that pause any action at or above an amount you set and route it to a named approver, whatever the agent's technical permissions say.
Network segmentation and L3/L4 controls between agents and targets. Vorim decides whether the action is allowed; the network decides whether the packet gets there.
What are they doing?
Runtime authorisation in the execution path, workflow-in-the-loop for high-risk actions, cost and token tracking, and traceable decision evidence captured at the boundary so a compromised agent cannot rewrite its own record. OCSF for normalised telemetry.
A decision before each gated action, allow, deny, modify or escalate, with the reason recorded and the human approval signed into the record when one was needed. Token budgets per agent and per workflow. Every event signed by the agent over canonical JSON and verifiable offline with open source tooling. Signed bundles delivered on a schedule to your own S3 bucket, Splunk, Datadog or any HTTPS collector, natively or as OCSF API Activity events.
Prompt injection scanning, DLP on outputs, sandboxing and endpoint isolation. Those live in the security gateway and the runtime; Vorim records what they let through and what they stopped.
How do I respond?
Containment that is instant and reversible, with a proportional ladder from throttling to revocation, and a deliberate path back: re-attestation, staged re-enrolment, root-cause sign-off, audit trail closure.
Suspend is the kill switch. It takes effect on the next permission check, expires every cached decision, and is reversible by an owner or admin. Rate limits per grant give you the throttle below it. Revoke is permanent. Every one of those actions is itself in the signed record, so the incident closes with evidence rather than a note.
Network quarantine, process termination and cloud instance shutdown. Vorim cuts the agent's authority; your platform cuts its compute.
Where Vorim stands on each.
The paper names the open standards its founding members validate their platforms against, and says validated results will be published as testing completes. This is our honest position on the same list.
Start where the Alliance says to start.
Its closing advice is a sequence, not a checklist. Vorim covers three of its seven steps on day one, which are logging, registration and testing the kill switch. Discovery, the second step, belongs to the scanners beside us.
Stand up logging first
Register agents, point the SDK at them, and every action lands in one signed log you can export or stream to your SIEM. That is the log lake the paper says everything else depends on.
Register before you restrict
A policy on an unregistered agent is a policy on nothing. Vorim makes registration a single call, so teams do not route around it with shared human credentials.
Test the kill switch before you need it
Suspend a non-production agent, watch its next permission check fail, reactivate it. Ten seconds, and now it is a control rather than a hypothesis.