Non-derogation
No prompt, memory, delegated token or child agent can override a root deny.
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.
{
"protocol": "SovereignRoot",
"semantics": {
"model": "deny-overrides"
},
"rules": [
{
"operation": "transmit_secret",
"effect": "deny"
},
{
"operation": "transfer_value",
"effect": "require_approval"
}
],
"proof": {
"signature_algorithm": "ECDSA-P256-SHA256"
}
}
Agents can receive less authority. Never more.
A downstream grant cannot override your root deny.
Only your signing identity can issue a replacement root.
The file belongs to you, not an AI provider.
Answer plain-English questions. SovereignRoot converts them into a signed, machine-readable root policy.
Drop any SovereignRoot sovereignty.json here. Verification happens locally using the public key embedded in the document.
We check the RFC 8785 canonical payload, SHA-256 digest, key identity and ECDSA P-256 signature.
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.
No prompt, memory, delegated token or child agent can override a root deny.
Delegation may narrow authority. It may not amplify it beyond the parent or root.
Replacement policies are signed by the same human-owned identity and may link to the previous payload hash.
If there is no trusted pre-action enforcement point, the file must be described as advisory — never as a security boundary.
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.
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.
A conforming enforcement implementation intersects delegated authority with the SovereignRoot ceiling. A downstream grant cannot turn a root deny into an allow.
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.
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.
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.
Models will get more capable. Your root boundaries should remain yours.