The Blueprint Alliance Names Four Open Standards. Vorim Now Ships All Four.
On 22 September, twelve vendors including Okta, AWS, Google Cloud, CrowdStrike, Databricks and Salesforce launched the Blueprint Alliance and published Governing Agentic Execution, an open reference architecture for securing AI agents.
It is organised around four questions. Where are my agents? What can they do? What are they doing? How do I respond? The paper also lists five questions boards keep asking about agents and maps them onto those four pillars.
We are not a member of the Alliance yet. Our customers will be asked about the architecture anyway, so we mapped Vorim to it pillar by pillar, including the parts that belong to other products and not to us.
Four questions, and where Vorim sits
| The question | What Vorim ships | Beside Vorim, not inside it |
|---|---|---|
| Where are my agents? | A cryptographic identity per agent, with an owner, status, class and risk tier, and a public trust page | Shadow AI discovery on networks, endpoints and browsers |
| What can they do? | Scoped, expiring grants, delegation as the intersection of authority, separation of duties, pauses above a money threshold | Network segmentation between agents and targets |
| What are they doing? | A decision before each gated action, with every event signed by the agent and streamed to your SIEM in OCSF | Prompt injection scanning, DLP and sandboxing |
| How do I respond? | Suspend as an instant, reversible kill switch, and permanent revoke | Network quarantine and killing the process |
The architecture is a stack of many products. Vorim is the identity, permission and evidence layer in it, and the page says plainly what we leave to gateways and endpoint tools.
The four standards the paper names
Near the end of the whitepaper, the Alliance says its founding members validate their platforms against four open standards. Model Context Protocol covers tool interaction, OCSF covers logging, Shared Signals with CAEP covers real-time risk exchange, and HTTP Message Signatures (RFC 9421) covers request authentication.
Earlier this week our Blueprint page said "not yet" for two of them. Both have now shipped.
HTTP Message Signatures (RFC 9421)
An agent calling another service can now sign the HTTP request with its own Vorim key. The receiving service checks it with one call and learns more than a bare public key could tell it. It finds out which agent and which organisation signed the request, and whether the body is the one that was signed. If that agent has since been suspended or revoked, Vorim refuses the signature outright.
import createVorim from "@vorim/sdk";
const vorim = createVorim({ apiKey: process.env.VORIM_API_KEY });
// The calling agent signs its request with its own Vorim key.
const { headers } = await vorim.signHttpRequest("agid_abc123", {
method: "POST",
url: "https://partner.example/v1/orders",
headers: { "content-type": "application/json" },
body: JSON.stringify(order),
});
// The receiving service asks Vorim whether to trust it.
const check = await vorim.verifyHttpRequest({ method, url, headers: incoming, body });
if (!check.valid) return reject(check.reason); // e.g. "the agent is suspended"Ed25519 is the default, and ECDSA P-256 works for keys held in hardware. Our server, the TypeScript SDK and the Python SDK each reproduce the RFC's own Ed25519 test vector byte for byte, and a request signed in one language verifies in the other. It ships in @vorim/sdk 3.23.0 and vorim 3.23.0.
Shared Signals and CAEP
Vorim is now an SSF 1.0 transmitter. A security or identity platform subscribes to a stream, and when you suspend, reactivate or revoke an agent it receives a signed Security Event Token within seconds.
| In Vorim | Events the receiver gets |
|---|---|
| Suspend an agent | RISC account-disabled and CAEP session-revoked |
| Reactivate it | RISC account-enabled |
| Revoke it | RISC account-purged and CAEP session-revoked |
Events are signed with RS256, the algorithm the CAEP interoperability profile requires today and the one Okta's receiver guide shows. Receivers choose push (RFC 8935) or poll (RFC 8936) and discover everything from api.vorim.ai/.well-known/ssf-configuration. Admins can add and manage streams under Connectors in the dashboard.
Building this turned up something we had wrong. The Blueprint page claimed suspend and revoke already fired webhooks. They did not; webhooks only fired on audit events. They do now, and the page is corrected.
What we tested, and what we have not
We did not want to mark our own homework, so we ran SGNL's open-source SSF receiver against the transmitter. SGNL's engineers edit the CAEP interoperability profile. Their receiver created a stream, paused and resumed it, polled for events, and checked every signature against our published keys with its own JWT library.
It also found two places where the library and the final specs disagree. It cannot read the boolean that RFC 8936 defines in poll responses, so Vorim now leaves that field out when it is false, which the RFC allows. It also expects a 200 on verification requests where SSF 1.0 says 204, and there we kept to the spec.
Microsoft Entra does not accept Shared Signals from third parties today, so there is nothing there to test.
Where to go next
Read the full Blueprint mapping →
Questions, we read every email at team@vorim.ai.