Who Decides What an AI Agent May Do? A Policy Framework for Autonomous AI.

Last week we wrote about Satya Nadella’s call to separate intelligence from authority. It leaves an obvious, practical question.

If the model does not hold the authority, what does?

Our answer is a rulebook. A short set of rules, written in plain language, that every action an agent proposes is checked against before it happens.

This piece sets out the framework we use to write those rules. It is the same framework whether the agent is approving a payment, filing a safety report or changing a production system.

Why principles are not enough

Most organisations already have an AI policy. It says things like “protect customer data” and “keep a human in the loop”.

Those principles are right. But an agent about to send a patient’s case notes to an outside model does not need a principle. It needs a yes or a no, now, from something other than itself.

The gap between the policy document and the moment of action is where AI governance usually breaks. Rules get interpreted by the system they are meant to govern, or checked only after the event.

An execution policy turns principles into decisions, made before the action, by something the agent cannot override.

The framework in four questions

Every rule in the framework answers the same four questions.

Put together, a rule reads as one plain sentence:

Anyone in risk, compliance or operations can read that, challenge it and sign it off. That matters more than any technical detail.

Six outcomes, not two

Most controls only know allow and deny. Real operations need more than that. A payment may be fine once a named signatory approves it. A message may be fine once a customer’s identifiers are removed. A failed step may be fine to retry from the last good state.

The framework has six outcomes, in three groups. We use the same names in the product.

A rule can also send work somewhere safer instead of refusing it, such as a test system instead of production. The work still gets done, just where the rules allow it.

The principles behind the rules

Outcomes are only as good as the rules that choose them. Six principles keep the rulebook honest.

1. Refuse by default. If no rule allows an action, it does not happen. New agents and new tools start with nothing, not everything.
2. Prohibitions always win. A permission can never quietly switch off a prohibition. If one rule says never and another says yes, never holds.
3. The agent cannot vouch for itself. What decides the outcome is what the agent is doing, not what it says about it. An agent can explain itself for the record, but it cannot talk its way past a rule.

4. Checks inform, rules decide. Independent checks, whether ours, yours or a specialist’s, report what they find. The rulebook decides what that finding means, the same way every time. A check never makes the decision on its own, and the agent never supplies its own readings.
5. People stay accountable. Every rule that makes an action wait names who resolves it. Silence is not consent: a timer running out is never treated as approval.
6. Every decision names its rules. Each decision records exactly which version of the rulebook applied, and every version is kept. Years later, anyone can see which rules were in force when an action was allowed or stopped.

Changing the rules safely

Rules change as the business changes. The framework treats a rule change like any other controlled change.

1. 1
   Draft

   Write or adjust a rule, start from a template, or describe the policy in plain English and review the rules it produces.

2. 2
   Test

   Run sample actions through the new rules and see each outcome before anything is live.

3. 3
   See the impact

   See what the change would newly allow, and what it would newly stop.

4. 4
   Sign off

   An authorised person approves the change. Nothing takes effect until it is published.

5. 5
   Keep every version

   Old versions stay on file, so past decisions can always be traced to the rules they used.

What it looks like in practice

Here is how the framework reads in four settings. Each is a short extract, not a complete rulebook.

Putting it to work

You can start with this framework before you choose any tool. Six steps get most teams most of the way.

1. List the actions, not the tasks. Write down what your agents can actually do: send, pay, change, delete, call an outside model.
2. Start from refusal. Allow what you need, then add to it. Do not start open and try to close the gaps later.
3. Name an owner for every wait. If a rule makes something wait, write down who decides. A role that can be held to account, not a shared inbox.
4. Choose the checks you trust. Decide which checks inform each rule, and who supplies them.
5. Decide what must be kept. For each rule, decide what record an auditor or regulator would expect to see.
6. Test before you publish. Run real examples through every change, and look at what it newly allows or stops.

This is the framework Mira runs on. The rulebook decides. Mira applies it at the moment of action, and keeps the record that proves it.

Principles say what good looks like. A rulebook makes it happen, every time, before the action.