A human-owned root policy for autonomous AI

Your AI can change.
Your boundaries shouldn’t.

Create a portable, cryptographically signed sovereignty.json that tells compatible AI runtimes what they must never do — regardless of model, vendor, prompt, memory or delegation.

✓ No account✓ No upload✓ No cookies✓ No paid API
sovereignty.json
{
  "protocol": "SovereignRoot",
  "semantics": {
    "model": "deny-overrides"
  },
  "rules": [
    {
      "operation": "transmit_secret",
      "effect": "deny"
    },
    {
      "operation": "transfer_value",
      "effect": "require_approval"
    }
  ],
  "proof": {
    "signature_algorithm": "ECDSA-P256-SHA256"
  }
}
01You define the ceiling

Agents can receive less authority. Never more.

02Deny always wins

A downstream grant cannot override your root deny.

03Your key, your policy

Only your signing identity can issue a replacement root.

04Portable by design

The file belongs to you, not an AI provider.

Generator

Build your sovereignty.json

Answer plain-English questions. SovereignRoot converts them into a signed, machine-readable root policy.

  1. 1Baseline
  2. 2Identity
  3. 3Money
  4. 4Data
  5. 5Agents
  6. 6Sign
  7. 7Done

Start with a baseline

Choose a preset, then tailor every rule. Presets never leave your browser.

When an action is not covered by any rule:
Independent verification

Trust the signature, not the website.

Drop any SovereignRoot sovereignty.json here. Verification happens locally using the public key embedded in the document.

Ready to verify

We check the RFC 8785 canonical payload, SHA-256 digest, key identity and ECDSA P-256 signature.

The protocol model

A ceiling above every grant.

SovereignRoot does not replace OAuth, agent identity or task authorization. It gives those systems a human-owned upper bound they are not allowed to exceed.

Human holderSigns the root constraint document
SovereignRootPersistent deny / approval ceiling
↓ intersects with ↓
OAuth · AIP · DRP · agent grantsTask-specific delegated authority
Trusted enforcement pointVerify → normalize → evaluate → allow / hold / deny
Tool / API / device / transactionExecution only after policy passes

Non-derogation

No prompt, memory, delegated token or child agent can override a root deny.

Attenuation only

Delegation may narrow authority. It may not amplify it beyond the parent or root.

Cryptographic continuity

Replacement policies are signed by the same human-owned identity and may link to the previous payload hash.

Fail honestly

If there is no trusted pre-action enforcement point, the file must be described as advisory — never as a security boundary.

Privacy by architecture

We designed the website so it doesn’t need your data.

No backendThere is nowhere for your answers to be submitted.
No analyticsNo trackers, pixels, cookies or third-party scripts.
No cloud key custodyYour private signing key is generated and encrypted locally.
Self-hostableThe complete site is static and can run on Cloudflare Pages, GitHub Pages or any ordinary web server.
FAQ

What this is — and what it isn’t.

Can sovereignty.json force ChatGPT, Claude or another hosted AI to obey it?

Not by itself. A signed file only becomes enforceable when a trusted runtime, proxy, operating-system boundary or service verifies it before the AI action executes. Pasting it into a model prompt is useful as an instruction but is not equivalent to hard enforcement.

Does SovereignRoot store my answers or key?

No. The distributed website contains no backend or submission endpoint. Generation, encryption, signing and verification happen in your browser. You control the files that are downloaded.

What if an agent has broader OAuth permissions?

A conforming enforcement implementation intersects delegated authority with the SovereignRoot ceiling. A downstream grant cannot turn a root deny into an allow.

What happens if I lose the private signing key?

You can still use and verify the existing policy, but you lose cryptographic continuity for future replacement policies. Keep at least two offline backups of the encrypted key file and separately preserve the passphrase.

Should I put API keys or recovery phrases inside sovereignty.json?

No. Never place secrets in the policy. Rules may refer to secret classes, but actual passwords, private keys, tokens, seed phrases and recovery codes should remain outside the document.

Is this an official internet standard?

No. SovereignRoot v0.1 is an open working specification and reference implementation. It deliberately builds on established cryptographic and JSON standards, but the policy format itself is not an IETF, W3C or NIST standard.

Give your AI a ceiling.

Models will get more capable. Your root boundaries should remain yours.

Create sovereignty.json