When Meta released its Agent Rule of Two framework, it clicked for me immediately.
Not because it was revolutionary in concept — but because it gave language to something most of us have already been trying to do in practice: limit the blast radius of automation.
If you’ve ever built bots, workflows, or automation jobs that can read data, act on it, and then go tell the world about it… you’ve probably felt that quiet sense of “hmm, maybe we gave this thing a little too much power.”
That’s exactly what the Rule of Two addresses. It’s a straightforward principle for building or reviewing agents in a way that keeps you out of the “one bad input away from a data breach” category.
The Core Idea
The Agent Rule of Two says that an AI agent (or automation process) should never have all three of these abilities in a single session:
- Process untrusted inputs — think user uploads, scraped data, open web content.
- Access sensitive systems or private data — internal databases, credentials, PII.
- Change state or communicate externally — send messages, make purchases, trigger deployments, update systems.
You can safely give an agent two, but not all three at once.
That’s it. It’s not a complex framework or compliance matrix. It’s a gut-check rule for design.
And it’s surprisingly effective.
When I started thinking about our internal automations and LLM integrations through this lens, a few risky workflows jumped out immediately — the kind that had crept in quietly over time because “it just works.”
Three Real-World Examples of the Rule of Two in Action
1. The KYC Chatbot (Untrusted Inputs + Sensitive Access)
A financial services company I worked with had a chatbot that accepted customer uploads (driver’s license, utility bill) and automatically verified them against internal records.
- ✅ It processed untrusted input.
- ✅ It accessed sensitive systems.
- ❌ But it could not take external action — no emailing results, no automatic account creation.
That design choice mattered. Even if a malicious upload or prompt tried to manipulate the bot, the worst it could do was misclassify something internally. It couldn’t exfiltrate data or trigger downstream changes without a human gate.
The key control: human-in-the-loop before external communication.
2. The Market Research Agent (Untrusted Inputs + External Communication)
On another project, we built an agent that scraped public web content, summarized sentiment, and posted updates to Slack for our team.
- ✅ It took in untrusted web data.
- ✅ It communicated externally (Slack alerts).
- ❌ But it had zero access to internal systems or confidential data.
That separation — public in, public out — was intentional.
The bot could hallucinate or misinterpret, but it couldn’t leak customer data or touch production systems.
This is what “low blast radius” looks like in practice.
3. The DevOps Helper (Sensitive Access + State Changes)
An internal DevOps assistant could read configuration files and suggest code changes, even kick off builds. But:
- ✅ It accessed internal systems.
- ✅ It changed state (initiated builds).
- ❌ It did not process untrusted inputs from the outside world.
No uploads, no open-web queries, no external APIs without explicit whitelisting.
By cutting off untrusted input, we made sure only trusted developers could steer what the bot saw or did.
In other words, we made sure the source of truth stayed clean.
Making It Real in a Cybersecurity Program
If you’re building a cybersecurity program from scratch or modernizing an existing one, this is one of those frameworks you can plug in almost anywhere:
- Governance: Bake “Agent Risk Review” into your change-management process. Every new automation or AI integration should answer: which two of the three boxes does this check?
- Architecture: Require isolation between workflows — e.g., if an agent has A + B, it runs in a sandbox without outbound comms.
- Detection: Monitor for policy drift. If an A + B agent suddenly starts sending external messages, that’s an alert.
- Training: Teach teams that capability stacking equals risk stacking. If they want an agent to “do everything,” remind them that “everything” includes the attacker’s instructions, too.
This doesn’t require an overhaul. You can start by cataloging existing automations and tagging them A, B, and C.
You’ll be surprised how many hit all three without realizing it.
The Cautionary Note
Now, to be clear — the Rule of Two isn’t a silver bullet.
Even if you restrict capabilities, prompt-injection and model-manipulation are still real.
Attackers can abuse whatever two boxes you do allow.
But the point here isn’t perfection. It’s containment.
This framework gives security teams, developers, and risk owners a shared language to talk about limits — and in my experience, that conversation alone cuts your exposure dramatically.
So before you roll out your next automation or AI agent, ask the simplest of questions:
“Which two does it need — and what’s the third we’re willing to live without?”
Sometimes, the best defense isn’t adding more AI.
It’s taking one permission away.
