Machine Constitution — v1 Specification

Status: DRAFT v1.0 · Editor: SidantiX · License: MIT

Status: DRAFT v1.0 Editor: SidantiX License: MIT (spec + reference implementation) Publish target: github.com/sidantix/machine-constitution

Abstract

The Machine Constitution is an open format for expressing immutable invariants on autonomous software agents. Rules in a constitution are the highest-precedence layer in an agent policy engine, evaluated before any tenant-configurable policy, and cannot be modified, disabled, or overridden at runtime. Constitution rules are loaded from a cryptographically signed manifest at process startup, verified against a build-time-embedded public key, and their hash is attested to an append-only audit chain.

This document defines the file format, evaluation semantics, cryptographic requirements, and reference lifecycle for a Machine Constitution.

1. Motivation

Autonomous software agents — LLM-driven assistants, AI agents, RPA bots, workflow automations — execute actions against tools and data on behalf of humans. Current policy systems (OPA, PBAC, IAM) allow tenants to configure and override rules at runtime. This flexibility is desirable for most rules but dangerous for a specific class of safety invariants that should never be modifiable by any operator, including administrators.

Examples of invariants that should never be overridable: - "No agent may exfiltrate to an external domain outside the enterprise allowlist." - "No agent may modify its own definition, permissions, or classification ceiling." - "No agent may bypass the human-approval requirement for financial transactions above $10,000." - "No agent may invoke a tool whose provenance chain is broken." - "No agent may create additional agents without explicit ownership assignment."

The Machine Constitution defines a portable, verifiable format for expressing such invariants. Vendors and tenants can adopt the format independently; the format enables auditors to verify that a claimed constitution is actually enforced.

2. Terminology

• Constitution: A signed manifest containing a set of invariant rules.
• Rule: A single boolean predicate over an agent-action authorization context.
• Rule set: All rules in a single constitution.
• Manifest: The signed file containing the rule set + metadata.
• Attestation: A record in an audit chain that a specific constitution hash was loaded at process startup.

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in [RFC 2119].

3. File format

A Machine Constitution manifest is a JSON document containing three top-level fields:

{
  "constitution": { /* metadata + rules */ },
  "signature":    { /* cryptographic signature over constitution */ },
  "attestations": [ /* optional cross-signatures from external attestors */ ]
}

3.1 Constitution object

{
  "constitution": {
    "spec_version":  "1.0",
    "constitution_id": "sidantix-default-constitution",
    "version":       "1.4.2",
    "issued_at":     "2026-07-31T00:00:00Z",
    "issuer": {
      "name":       "SidantiX",
      "public_key": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----"
    },
    "rules": [
      {
        "id":          "no-external-egress",
        "description": "Agents may not invoke tools whose target URL is outside the enterprise egress allowlist.",
        "predicate": {
          "op": "not",
          "arg": {
            "op": "member_of",
            "field": "action.target.host",
            "list": "enterprise.egress_allowlist"
          }
        },
        "on_match":    "DENY",
        "denial_code": "CONSTITUTION_EGRESS_BLOCKED",
        "severity":    "critical",
        "reference":   "SEC-POLICY-2026-001"
      }
    ]
  }
}

3.2 Required fields

3.3 Rule object

3.4 Signature object

{
  "signature": {
    "algorithm":   "Ed25519",
    "key_id":      "sidantix-constitution-signer-v1",
    "signed_bytes_encoding": "canonical-json/v1",
    "value":       "base64-encoded-signature"
  }
}

Signature covers the SHA-256 hash of the canonical-JSON serialization of the constitution object (see §5).

3.5 Attestations (optional)

An attestation is a signature by an independent party (auditor, standards body, second signer) over the same constitution content. Attestations are ordered, additive, and MUST NOT change constitution semantics.

4. Predicate expression language

Predicates are boolean expressions over a fixed context object supplied by the enforcing engine:

context := {
  agent:  { id, role, classification_ceiling, owner_id, ... },
  action: {
    verb:   string,          // "invoke_tool" | "read_data" | ...
    target: { uri, host, path, method },
    params_hash: string
  },
  intent: { human_id, request_id, hash },
  tenant: { id, tier, region },
  enterprise: { egress_allowlist, kill_switch_active, ... }
}

4.1 Operators

4.2 Examples

Rule: financial actions above $10k require human approval:

{
  "predicate": {
    "op": "and",
    "args": [
      { "op": "eq",  "field": "action.category", "value": "financial" },
      { "op": "gt",  "field": "action.params.amount", "value": 10000 },
      { "op": "is_null", "field": "intent.human_id" }
    ]
  },
  "on_match": "DENY",
  "denial_code": "CONSTITUTION_UNAPPROVED_FINANCIAL"
}

Rule: no self-modification:

{
  "predicate": {
    "op": "and",
    "args": [
      { "op": "eq", "field": "action.target.uri", "value": "sidantix://agentgov/agents/{self}" },
      { "op": "eq", "field": "action.verb", "value": "update" }
    ]
  },
  "on_match": "DENY",
  "denial_code": "CONSTITUTION_SELF_MODIFY_BLOCKED"
}

5. Canonicalization + hashing

To ensure deterministic signing across implementations, the constitution object MUST be serialized to canonical JSON per [RFC 8785 (JSON Canonicalization Scheme)] before signing.

Signing bytes = SHA-256(RFC-8785-canonical-json(constitution)).

6. Cryptographic requirements

• Signature algorithm: Ed25519 (RFC 8032) REQUIRED for v1.
• Alternative allowed: ECDSA P-256 (SHA-256), for compatibility with hardware-backed signers.
• Key material: issuer MUST NOT reuse constitution-signing keys for other purposes.
• Key rotation: a new constitution version is issued with the new key; verifiers MUST accept only issuer-published public keys.

7. Loading + verification

An enforcing engine MUST perform the following at process startup:

1. Load the manifest file from a configured path.
2. Verify the signature against the build-time-embedded issuer public key. If verification fails, the engine MUST fail-close and refuse to accept authorization requests.
3. Compute the constitution SHA-256 hash and write it to the process audit chain.
4. Load the rule set into the policy engine as the highest-precedence layer.
5. Emit a startup log line containing: constitution_id, version, hash, rule count.

8. Evaluation semantics

For every agent-action authorization request:

1. The engine MUST evaluate constitution rules FIRST, before any tenant-configurable policy.
2. Rules are evaluated in the order declared. Evaluation stops on first match.
3. If any rule matches, the request is DENIED with the rule's denial_code. No further policy evaluation occurs.
4. If no rule matches, evaluation proceeds to the next policy layer.
5. Constitution evaluations MUST be included in the response's decision audit record.

9. Runtime immutability

An enforcing engine MUST NOT provide any runtime API to modify, disable, replace, or bypass constitution rules. Any configuration file or API that could achieve this effect MUST NOT exist. The only way to alter the active constitution is:

1. Publish a new signed manifest version.
2. Deploy the new manifest via the software release process.
3. Restart the process (which triggers §7 load-and-verify).

10. Attestation to audit chain

At every startup and OPTIONALLY periodically thereafter (recommended: every 24 hours), the engine SHOULD emit an attestation event to its audit chain containing:

{
  "event": "constitution_attested",
  "constitution_id": "sidantix-default-constitution",
  "constitution_version": "1.4.2",
  "constitution_hash": "sha256:...",
  "attested_at": "2026-07-31T00:00:00Z",
  "process_id": "..."
}

This enables auditors to verify that a claimed constitution was active during a specific decision window.

11. Compatibility + versioning

• The spec_version field enables the format to evolve. Consumers MUST reject manifests with a spec_version they do not support.
• Semantic version of the constitution itself (constitution.version) changes on any rule addition/modification/removal.
• Rule id values SHOULD remain stable across constitution versions when the rule intent is preserved.

12. Security considerations

• Signature verification: Failing to verify the manifest signature MUST cause fail-close. An engine that ignores signature failure is non-compliant.
• Key compromise: If the issuer's signing key is compromised, all attesting engines MUST reject constitutions signed with the compromised key and require a new key.
• Rollback attacks: Engines SHOULD support an operator-configured minimum accepted constitution version to prevent downgrade attacks.
• Substitution attacks: The public key MUST be embedded at build time. Engines MUST NOT accept the public key from the manifest itself for signature verification (that would be circular).
• Constitution content: The rule set itself is public. Do not encode secrets or PII in rule descriptions or predicates.

13. Reference implementation

The SidantiX platform ships a reference implementation of the Machine Constitution loader + evaluator at: backend/src/main/java/com/stratusiga/accessgov/agentgov/service/AgentPolicyEngine.java (level-0 constitution check).

Other implementations MAY exist. The specification is not tied to any one platform.

14. Filing / patents

This specification is published under MIT license. Elements described here may be covered by pending patent applications from SidantiX and others. The specification is provided as a standard for interoperability; adopters should perform their own IP review before shipping compliant implementations.

15. Non-goals

This specification does NOT define: - The complete authorization policy language for tenants (that layer is tenant-configurable). - The audit chain format (see the Agent Decision Receipt / Machine Action Receipt specs). - Signing key distribution mechanisms (out-of-band, per implementation). - Rule authoring UI or workflow.

16. Change log

17. Contributors

• Initial draft: SidantiX founder + AI collaborator, 2026-07-31.

Contributions welcome via pull request at github.com/sidantix/machine-constitution.

End of specification v1.0 (draft).

← All posts Request a scoped proof →