Why We Open-Sourced the Machine Constitution
TL;DR: We published the Machine Constitution specification under an MIT license with a full reference implementation. It defines runtime-immutable safety invariants for AI agent governance — cryptographically signed, verified at process startup, with no admin API to disable them. We open-sourced it because safety invariants should not be proprietary. The industry needs a standard.
The problem: configurable means bypassable
I spent years building identity governance systems. One pattern I saw repeatedly: every safety rule eventually becomes a configuration toggle. An admin gets frustrated, a customer files a support ticket, and someone adds an override flag. Fast-forward two years, and your "mandatory" controls have a dozen escape hatches scattered across admin consoles, feature flags, and environment variables.
This was already dangerous for human access governance. For AI agent governance, it is a category error.
When an AI agent can take autonomous action — invoke APIs, move data, create other agents — the rules that bound its behavior cannot live in the same tier as tenant preferences. A tenant admin should be able to decide whether an accounting agent runs during business hours. A tenant admin should never be able to decide whether agents can exfiltrate data to external domains.
Yet every AI agent governance platform I have evaluated treats every rule as configuration. Saviynt Zuma, SailPoint's agent governance work, Microsoft Entra Copilot Governance — all of them expose all safety rules through the same admin API that manages routine policy. If an attacker compromises a valid admin credential, every safety rule is one API call away from being silenced.
That is not a policy problem. That is an architecture problem.
What the Machine Constitution is
The Machine Constitution is a signed JSON manifest containing safety invariants — boolean predicates over an authorization context. At SidantiX, it works like this:
- Build time: The constitution is authored, reviewed, and cryptographically signed with an Ed25519 key held in the release pipeline. The public key is embedded in the binary at compile time.
- Startup: When the policy engine starts, it verifies the constitution's signature against the embedded public key. If verification fails, the engine refuses to accept any authorization request. Fail-closed. No fallback mode.
- Runtime: Every agent action authorization request is evaluated against the constitution first — before any tenant-configurable policy. The engine exposes no API to modify, disable, or bypass these rules. There is no admin toggle. There is no environment variable. There is no feature flag.
- Audit: At every startup, the engine writes the constitution's SHA-256 hash to the audit chain. Auditors can cryptographically prove which exact set of invariants was active during any decision window.
The only way to change a constitution rule is to author a new manifest, sign it through the release pipeline, and deploy a new build. That is a deliberate, auditable, multi-person process — not a runtime configuration change.
Why we open-sourced it
We could have shipped this as a proprietary differentiator and moved on. We chose not to, for three reasons:
Safety invariants should not be proprietary. The concept of runtime-immutable rules that no admin can override is not something one vendor should own. If only SidantiX customers have access to this pattern, that means every other organization running AI agents is exposed to the architectural gap described above. That is bad for the industry and, eventually, bad for us — because a major AI agent incident at any vendor will trigger regulatory responses that affect everyone.
An open spec creates an audit standard. Right now, if an auditor wants to evaluate whether an AI agent platform has immutable safety controls, there is no common format to check against. The Machine Constitution spec gives auditors a concrete question: "Show me your signed constitution manifest. Let me verify it." If the vendor cannot produce one, that is a finding. Portability matters — auditors should not need vendor-specific tooling to verify safety invariants.
The standard defines the category. Once the spec exists publicly, other vendors face a choice: adopt it, build something equivalent, or explain why their safety rules are all runtime-mutable. Any of those outcomes advances the conversation. We would rather compete on implementation quality than on whether the category should exist.
What this means for the industry
The AI agent governance market is early. MCP, A2A, and sub-agent delegation chains are making agent architectures deeper and more interconnected. A tenant admin editing a policy rule today does not just affect their agents — it affects every downstream sub-agent invoked through the delegation chain.
Runtime-mutable safety rules do not scale to this reality. When an agent can spawn sub-agents that invoke tools across organizational boundaries, the invariants that bound that chain need to be structurally immutable — not "immutable unless someone with admin access disagrees."
The EU AI Act already requires demonstrable human oversight and auditable safety controls for high-risk AI systems. Cryptographically-attested constitutions are the cleanest mechanism I know of to prove that your safety layer is as immutable as you claim it is.
What is in the spec
- Signature algorithms: Ed25519 or ECDSA P-256, over canonical JSON (RFC 8785).
- Predicate language: Deliberately Turing-incomplete —
eq,ne,lt,gt,contains,matches,and,or,not. No loops. No recursion. This prevents DoS via rule complexity. - Enforcement requirements: Engines MUST NOT provide any API to modify, disable, or bypass constitution rules at runtime.
- Fail-close mandate: Signature verification failure MUST prevent the engine from accepting authorization requests.
- Audit attestation: Engines SHOULD write the constitution hash to their audit chain at startup.
The full spec, example constitutions, and reference implementation are at github.com/sidantix/machine-constitution. MIT license. Use it, fork it, improve it.
Try it yourself
If you are evaluating AI agent governance platforms, add one question to your checklist: Are your safety invariants cryptographically immutable at runtime, or are they configuration that an admin can override?
If the answer is configuration, ask why.
If you want to see how SidantiX enforces the Machine Constitution in production — including a live demonstration of what happens when an attacker with valid admin credentials attempts to disable a safety rule — request a scoped proof.