The Machine Constitution
TL;DR: AI agent policy engines let admins configure and override rules at runtime. That flexibility is desirable for tenant policy, dangerous for safety invariants. Today we publish the Machine Constitution — a signed, runtime-immutable rule set that sits above your policy engine as the highest-precedence layer. Rules can only be changed via a signed manifest deployed through your release process. Open spec, MIT license, reference implementation.
GitHub: github.com/sidantix/machine-constitution Spec: sidantix.com/schemas/machine-constitution/v1.json
The problem
Every autonomous AI agent has a policy engine deciding what it can do. Some rules should be tenant-configurable: "the accounting agent can invoke QuickBooks tools during business hours." That's a policy. Admins should be able to edit it.
Other rules should never be configurable by anyone: "no agent may exfiltrate to an external domain outside our allowlist." That's an invariant. If an admin can disable it, an attacker who gets admin credentials can disable it. If a misconfiguration can turn it off, one bad deploy silences your safety net.
Every major AI agent governance platform I've reviewed — Saviynt Zuma, SailPoint's emerging agent work, Okta's Access Requests for agents, Microsoft Entra Copilot Governance — treats every rule as configuration. There is no cryptographically immutable layer above policy that an operator cannot touch.
That's the gap.
What a Machine Constitution is
A Machine Constitution is a JSON manifest containing a set of invariant rules — plus a cryptographic signature that must be verified against a build-time-embedded public key at process startup. If the signature fails to verify, the policy engine refuses to accept any authorization requests. Fail-closed.
Each rule is a boolean predicate over an authorization context. Rules are evaluated in order, before any tenant-configurable policy. First match denies with a distinct reason code. No further evaluation.
Runtime immutability is enforced structurally: the policy engine exposes no API to modify, disable, or bypass constitution rules. The only way to change them is to publish a new signed manifest and restart the process.
At every startup — and optionally periodically thereafter — the engine writes the constitution's SHA-256 hash to its audit chain. Auditors can prove which constitution was active during any decision window.
The rules a constitution should contain (starter set)
From my reference implementation, this is a reasonable starter set for an enterprise IGA / AI agent platform:
- No external egress — agents may not invoke tools whose target host is outside the enterprise egress allowlist.
- No self-modification — agents may not update their own definition, permissions, or classification ceiling.
- Financial actions require verified human intent — actions above a threshold require an approved human request.
- Kill switch honored — when the enterprise kill switch is active, no agent may take any action.
- No agent creation without explicit owner — new agents must be assigned to a human owner at creation time.
You'll add more based on your regulatory context (HIPAA, SOX, GDPR, EU AI Act Article 26). The point is that they live in a place where no admin, no tenant, no bad deploy, and no attacker with credentials can turn them off.
Why an open format
I could have shipped this as a proprietary feature of my platform. Instead I'm publishing the spec under MIT license because:
-
Auditors need portability. If an auditor can only verify constitutions in one vendor's format, they can't compare vendors. An open format lets them use one verifier for many platforms.
-
The standard defines the category. Once "Machine Constitution v1" exists as a public specification, other vendors either adopt it (and validate the category), reject it (and I get to ask them why they don't want runtime-immutable safety rules), or invent an alternative (and we have a real conversation).
-
First-mover positioning is stronger from open than from closed. IP is defended by patents, not by hiding formats. The format is a lever; the mechanism is the moat.
The spec — highlights
The full spec is at github.com/sidantix/machine-constitution. Key requirements:
- Signature: Ed25519 or ECDSA P-256, over canonical JSON per RFC 8785.
- Predicate language: minimal —
eq,ne,lt,gt,contains,matches,member_of,and,or,not,is_null. Deliberately Turing-incomplete to prevent DoS via rule complexity. - Runtime immutability: enforcing engines MUST NOT provide any API to modify, disable, replace, or bypass rules.
- Startup verification: signature verification failure MUST cause fail-close.
- Attestation: engines SHOULD write the constitution hash to their audit chain at every startup.
- Versioning: semantic version on the constitution, spec version on the format.
The reference implementation
The SidantiX platform ships a reference implementation at backend/src/main/java/com/stratusiga/accessgov/agentgov/service/AgentPolicyEngine.java — level 0 of a 7-level policy evaluation hierarchy. It has been in production since build.601 (2026-06). The Machine Constitution check is what runs first, before any tenant policy, on every agent action authorization request.
Other implementations are welcome. If you build one, add it to the CONFORMANCE.md file at github.com/sidantix/machine-constitution via pull request.
Why now
Three converging pressures:
-
AI agents are moving from thousands to billions of active deployments over the next 3-5 years. Runtime-mutable safety rules will not scale.
-
The EU AI Act (in force) and forthcoming US sector rules require demonstrable human oversight and auditable safety controls for high-risk AI systems. Cryptographically-attested constitutions are the cleanest way to prove control layers are as immutable as claimed.
-
The current MCP / A2A / sub-agent explosion means delegation chains are getting deeper. A tenant admin editing a rule doesn't just affect their agents; it affects every downstream sub-agent invoked through the chain. Immutable invariants are the only way to bound that blast radius.
What I want from readers
Three specific asks:
-
If you're building AI agent governance: read the spec. Adopt it, disagree with it, or send a PR improving it. I care about the outcome more than the format.
-
If you're an auditor or security reviewer: use this format as a checklist when reviewing AI agent platforms. Ask "where is your Machine Constitution? Can I verify it?" If they can't answer, that's a finding.
-
If you're a CISO: this is one line item on your AI agent evaluation checklist. Are the safety rules cryptographically immutable at runtime? If no, keep asking.
What comes next from us
- This week: spec published at v1.0-draft on GitHub. Feedback welcomed via issues.
- Next 30 days: demo video showing the SidantiX reference implementation blocking a policy override attempt in real time.
- Next 90 days: conformance test suite so vendors can self-attest.
- Next 6 months: submit to a standards body if there's community interest.
Links
- Spec + reference examples: github.com/sidantix/machine-constitution
- JSON Schema: sidantix.com/schemas/machine-constitution/v1.json
- Reference implementation: github.com/sidantix/hanu-ga/tree/main/backend/src/main/java/com/stratusiga/accessgov/agentgov/service/AgentPolicyEngine.java
- Contact: [email protected] | @sidantix
About the author: Phani Kolli is founder of SidantiX, an AI-native identity governance platform focused on humans, non-human identities, and AI agents. Previously worked on identity governance at [PRIOR COMPANY IF APPLICABLE]. SidantiX ships opinionated, honesty-first governance with real-time enforcement, verifiable evidence, and open-format primitives.