​

Sigil Open Framework (SOF)

The Sigil Open Framework (SOF) is an open specification for cryptographic pre-execution authorization of autonomous AI agents. Define what’s allowed once, in policy. Everything else is blocked automatically — before it fires. SOF defines a protocol contract that conforming signers, policy engines, and legal wrappers implement to give autonomous agents the cryptographic and legal boundaries required to operate safely in production. The specification is implementation-agnostic by design: any signer that issues conforming Intent Attestations against a warranty.md policy is a valid SOF implementation. Sigil Core publishes the reference implementation. Independent implementations — by audit firms, custodians, enterprise security teams, or any third party — are explicitly welcome and structurally accommodated. The full conformance contract is documented in Conformance. If standard agentic frameworks are the accelerator pedal, SOF is the cryptographic brake protocol. The reference implementation is one engine that speaks it. Others can speak it too.

---

​

Evidence a third party can check

The central question is not whether an agent seems safe. It is whether an outside reviewer can determine who authorized a specific action, under which policy, before the action ran. SOF binds the signed policy, declared intent, decision, approval outcome where required, and execution check into evidence a verifier can inspect. A reviewer does not need a commercial relationship with the deployment to examine the artifacts. The reviewer still makes an independent trust decision about the policy owner and issuer. Verification proves what the signed evidence says. It does not make the action correct or make a signer trustworthy. The reference signer publishes a JSON Web Key Set (JWKS) for its JWT Intent Attestations. That is the correct discovery format for JWK-formatted JWT verification keys. Other signature systems can use different discovery formats. For example, a deployment using RFC 9421 HTTP Message Signatures can expose an HTTP Message Signatures directory with keyid, alg, and hexadecimal public_key values. That directory is not a JWKS. Pipelock documents an operator-hosted directory at /.well-known/http-message-signatures-directory for its HTTP Message Signatures verification keys. That can be a stronger trust posture than a vendor-hosted JWKS because it removes the vendor from the verification path. SOF does not claim that its JWKS is categorically more trustworthy. Its defensible distinction is that a third party can discover the verification material and evaluate the evidence without a relationship to the deployment.

---

​

The Doctrine of Structural Trust

Safety is not a property of prompts. Safety is a property of architecture.

The Sigil Open Framework is built on a single, non-negotiable principle: autonomous agents cannot be trusted to self-govern. Trust must be structurally enforced — cryptographically, deterministically, and before execution, not after loss. Under SOF, every conforming agent operates within these guarantees:

• AI agents never hold private keys
• AI agents never see raw API credentials
• AI agents cannot execute without deterministic authorization
• High-stakes actions must route through a policy enforcement layer

Execution only proceeds if the action carries a valid Intent Attestation issued by a conforming signer. This doctrine is enforced at the specification level. Every SOF-conforming implementation — reference or third-party — must uphold it within its own domain:

• Conforming signers enforce it technically — no execution without cryptographic authorization
• FAF enforces it legally — no liability exposure without structural governance
• Sigil Attestations proves it cryptographically — every authorized action is verifiable

---

​

A Governed Protocol Stack

SOF is a composable protocol stack — a specification at the center, with three implementation layers around it. The conformance contract is universal: every SOF-conforming deployment, regardless of vendor, runs against the same cryptographic specification. The legal layer converts those guarantees into fiduciary instruments. The vertical boilerplates are pre-assembled deployments — enforcement and legal wired together for a specific industry context.

---

​

Operator Surface: Command & Vault

The protocol stack governs execution. These two components extend governance into the human layer and the credential layer. Both are part of the reference implementation; conforming signers MAY expose equivalent surfaces.

---

​

Client-Side Enforcement: Agent Hooks

The protocol stack governs what happens at the execution layer. @sigilcore/agent-hooks is the client-side package that connects your agent framework to that layer — intercepting every tool call before it executes and routing it through a conforming signer for policy evaluation. Without agent-hooks, SOF governs EVM transactions. With agent-hooks, SOF governs any agent action on any framework: bash commands, HTTP requests, file writes, wallet signing, and email sends. The agent never reaches the API — or the blockchain — without a verified clearance.

---

​

The Standard: Intent Attestations

The entire framework relies on a single cryptographic primitive: the Intent Attestation. Before an agent can execute a transaction on-chain, it must evaluate its intent against the deterministic constraints defined in its policy. If the intent is compliant, a conforming signer issues a short-lived, Ed25519-signed JWT; the hosted reference signer adds a parallel ML-DSA-65 post-quantum signature in the pqc claim. The EVM gateway physically rejects any write operation that does not include this valid attestation.

---

​

Start Building

Choose the path that fits your role.

---