Permission Bits as Governance Language: Controlling 6 Agents with 5 Bits

Corporate governance has separation of duties. The person who approves payments shouldn't be the person who initiates them. The person who deploys code shouldn't be the person who writes it. In DPO2U, I enforce the same principle on autonomous AI agents — not through policies they might ignore, but through a 5-bit integer stored on-chain in a smart contract.

The permission model

Every agent in DPO2U is registered in the AgentRegistry smart contract with a permission bitfield. Five bits encode five capabilities:

Bit	Value	Permission	Description
0	1	READ	Query on-chain data and knowledge base
1	2	WRITE	Write non-critical data (notes, content, configs)
2	4	TREASURY	Execute financial operations (swaps, withdrawals)
3	8	DEPLOY	Deploy smart contracts
4	16	GOVERNANCE	Modify roles and governance parameters

Permissions combine additively. An agent with permission value 7 has READ (1) + WRITE (2) + TREASURY (4). An agent with value 1 has only READ. The smart contract checks (agent.permissions & requiredBit) != 0 before allowing any operation.

The current assignment

Notice the asymmetry: only one agent has TREASURY access. Only one can create new agents. The other four are read-only. This isn't because they're less capable — compliance-expert runs on Opus, the most powerful model — it's because their responsibilities don't require financial or creative permissions.

Why bitmasks, not role strings

The obvious alternative is role-based access with string labels: "role": "treasury-operator". Three reasons why bitmasks are better for agent governance:

1. Composability. A bitmask lets you combine permissions without creating new role names. Permission 7 (READ+WRITE+TREASURY) doesn't need a dedicated role — it's three bits flipped in an integer. Adding DEPLOY later means flipping bit 3, producing 15. No schema migration, no new role definition, no permission table update.

2. On-chain efficiency. Storing and checking a uint8 costs less gas than comparing strings. The smart contract's permission check is a single bitwise AND operation — O(1) regardless of how many permissions exist.

3. Auditability. Every permission state is a unique integer. When the AgentRegistry emits an event, the permission value is a single number that unambiguously describes the agent's capabilities. Auditors don't need to cross-reference role definitions — the number is the definition.

Anti-patterns we avoided

Building the governance model involved studying how agent systems fail. Three anti-patterns from the literature and from DPO2U's own Zettelkasten research shaped the design:

Control inversion

The failure mode where humans start reporting to agents instead of directing them. In DPO2U, this is prevented by keeping GOVERNANCE (bit 4) unassigned. No agent can modify roles. Only the human CEO can change permission bits in the AgentRegistry. The contract enforces this — not a policy document.

Human middleware degradation

When humans become passive signing oracles — approving every agent request without reviewing it. DPO2U mitigates this by limiting which operations require human approval. Most agents have READ-only access, so they produce outputs (notes, content, analyses) that the human reviews at leisure. Only dpo2u-defi-ops triggers financial operations, and those are bounded by spending limits in the Treasury contract.

Recursive bureaucracy

When agents create processes to manage processes. The agent-factory can create new agents, but it cannot grant them permissions — only the CEO can set permission bits. This breaks the recursion: an agent can propose a new agent, but it cannot autonomously expand the system's authority.

The governance guardrails

Beyond permission bits, DPO2U enforces three structural constraints:

Guardrail	Mechanism	Purpose
Autonomy ceiling	Max level 2 (act then notify, trivial only)	Prevents unsupervised consequential actions
Approval gates	5 mandatory gates (publish, deploy, external comms, financial, architecture)	Human review for high-impact operations
Anti-recursion	Max 2 meta-levels, every process needs an external customer	Prevents agents optimizing for agent metrics

These aren't suggestions — they're encoded in the agent configuration files and enforced by hooks in the Claude Code environment. An agent that tries to publish content without approval gets blocked by the PostToolUse hook before the action completes.

Scaling the model

The 5-bit model supports 32 unique permission states (2^5). DPO2U currently uses 3 of them (1, 3, and 7). As the agent ecosystem grows, the same model scales without architectural changes:

• A future legal-reviewer agent might get permission 5 (READ + TREASURY) — read compliance data and access financial records, but not write or deploy
• A ci-deployer agent might get permission 9 (READ + DEPLOY) — deploy contracts but not touch the treasury
• Full admin would be 31 (all 5 bits) — and it's deliberately unassigned

The constraint is intentional. If you can express every agent's authority in a single byte, your governance model is simple enough to reason about. The moment you need a spreadsheet to explain who can do what, you've lost control.

For the smart contract details, see Smart Contracts. For the full agent architecture, see One Person Unicorn.