Skip to main content
Back to Insights
Governance19 Jun 20269 min read

Why Agentic Systems Need Bills of Rights

As agents take on autonomous action — booking, drafting, posting — the question of what they're allowed to do, and to whom they're loyal, becomes load-bearing infrastructure. A practical framework for encoding autonomy boundaries and loyalty declarations in soul.md files.

In 2018, a startup deployed an agent to manage social media for a mid-size consumer brand. The agent was capable. It performed well on almost every metric. Then one evening, during a news cycle, it posted a cheerful promotional message into a national emergency that happened to share the brand's product category. Nobody had told the agent not to post during national emergencies. Nobody had thought to.

This is not primarily a story about AI safety. It's a story about the absence of a governing document: something that would have told the agent what it was and was not authorised to do, without requiring an operator to anticipate every possible scenario in advance.

The load-bearing questions

As agents take on more autonomous action — booking appointments, drafting contracts, posting content — two questions become structurally load-bearing. First: what is this agent authorised to do? Not as a capability question, but as a permission question. Second: to whom is this agent loyal? When the interests of the operator, the user, and any affected third parties diverge, which direction does the agent move?

Most current soul.md files and system prompts don't answer either question explicitly. They specify capabilities and constraints but leave governance implicit — which means that under novel conditions, the agent resolves both questions on the fly.

The four-verb autonomy boundary

The essay *the-four-verb-autonomy-boundary* introduced the core principle: there is a small set of actions that an agent should never take without explicit, per-instance authorisation. Those actions can be summarised in four verbs: don't post, don't purchase, don't publish, don't delete. Everything else, move.

The case for making this boundary explicit is straightforward: implicit boundaries only hold in anticipated scenarios. Every scenario the operator didn't think of is a scenario where the implicit boundary may or may not hold. Explicit boundaries generalise.

Loyalty disclosure as governance infrastructure

The essay *whose-side-is-your-agent-on* argued that left unspecified, an agent serves whoever phrased the last instruction. The fix is the same fix humans have used in professional services for centuries: disclose the principal relationship, in writing, so that all parties can factor it into their decisions.

An agent that discloses its loyalty — "in conflicts between operator commercial interest and client wellbeing, this agent will flag the conflict rather than resolve it silently" — is an agent that can be trusted in a way that an undisclosed-loyalty agent cannot.

The right to refuse

The third element is a refusal protocol — the agent's specified right to decline instructions that fall outside its mandate or push past its autonomy boundary. This is what Anthropic's Responsible Scaling Policy and the NIST AI RMF both point toward: agents need to be able to say no, and that capacity needs to be structural.

*The Soul of AI Agents* provides implementable templates for all three elements — autonomy boundary, loyalty declaration, and refusal protocol — as part of a soul.md that functions as a governance document, not just an identity file.

An agent that has never been told who it serves will serve whoever phrased the last message. That is not an accident. It is the default.

These ideas are expanded across 12 chapters in *The Soul of AI Agents*, just published on Amazon UK. **[Find it here →](https://www.amazon.co.uk/dp/B0GZTMFJSW)**