Boards are increasingly asked to approve AI with two kinds of material: vendor slides about what a model can do, and policy documents about what the organisation intends. Neither tells a director what an agent can actually do on a bad day, who would notice, and who would answer for it.
A control model does. It is a short set of questions that every agent must answer in the same way, backed by evidence a board can inspect. This perspective sets out the model the Guild works from: four controls, a risk appetite expressed as autonomy, clear lines of accountability, and a board pack short enough to read.
Four questions for every agent
A director does not need to know which model an agent runs on. They need four answers, for every agent the organisation operates:
- Who is acting? Identity.
- What may it do? Permissions.
- How do we know it works? Evidence.
- Who decides? Human review.
If any of the four cannot be answered for a given agent, that agent is not governed — however good its results look.
The control model on one page
| Control | The board's question | What good looks like | Evidence a board can ask for |
|---|---|---|---|
| Identity | Who or what acted? | Every agent has its own identity, a defined role and a named human owner. No shared or borrowed credentials. | An agent register: mission, owner, role, systems |
| Permissions | What can it do on its worst day? | Allowlisted tools, bounded actions, explicit limits, least privilege, revocable in one step | An access matrix: agent × system × action × limit |
| Evidence | How do we know it works, and keeps working? | Evaluated before launch against thresholds set in advance; monitored afterwards; every action recorded | Evaluation reports, drift signals, an activity ledger |
| Human review | Which decisions stay with people, and with whom? | Approval gates on consequential actions; named approvers; changes in autonomy are recorded decisions | The approval trail and decision records |
It is the same shape as the controls the Guild builds into its own operating model. Every agent the Guild deploys receives a role, an identity, approved tools, explicit limits, evaluation criteria and a named Human Wizard, and six controls — identity and access, approved knowledge, controlled tools, evaluation, human escalation, and audit — are each visible in the Citadel.
Express risk appetite as autonomy
Boards usually express risk appetite in money and likelihood. For agents, appetite is far easier to govern when it is translated into autonomy: how much an agent may do without a person, in which kinds of work.
The Citadel's trust model gives the vocabulary. At Observe, the agent recommends and a person executes. At Assist, it prepares work and waits for explicit approval. At Operate, it acts within narrow policies and defined limits. At Optimize, proven workflows expand through measured, reviewed changes. Autonomy is a graduated operating choice, not a blanket setting.
The board does not approve each agent. It approves the rules: the highest level any category of action may reach, the limits that apply, what always needs a person, and who may move an agent up a level, on what evidence.
| Category of action | Highest autonomy allowed | Always a person when |
|---|---|---|
| Internal drafting, summaries, research | Optimize | The output leaves the organisation |
| Routine customer replies within approved templates | Operate | A complaint, legal threat or vulnerable customer is involved |
| Refunds and credits | Operate below a set limit | Above the limit, or a repeat claim |
| Changes to customer or supplier records | Assist | Bank or payment details are involved: two people |
| Pricing, contracts, access rights | Assist | Always |
| Deleting records | Not delegated | Always |
One page like this does more for control than a long policy, because it can be checked: each agent's actual configuration either sits inside it or does not.
Clear lines of accountability
Many boards and audit committees already work with the three lines model: management owns and operates, a risk function sets and tests the controls, and internal audit checks independently. Agents fit that structure without strain.
- First line — the operating owner. A named person accountable for each agent in production: its results, its exceptions, the decision to pause it.
- Second line — the boundary setters. Security and risk define permissions, limits and escalation rules, and test that they hold.
- Third line — independent assurance. Audit reconstructs decisions from the record, without asking the team that built the agent.
Inside the Guild, agents carry much of the measuring and guarding: Oracle owns the scorecard, Sentinel owns the boundaries, Athena owns the mission and the human approval points. But the decision to deploy, and accountability for it, stays with a Human Wizard, and every engagement has a named Archmage. That is the point a board should insist on in its own organisation: agents can measure and guard; accountability stays with named people.
The board pack
Ask for two pages, at every meeting where AI is on the agenda.
- Agent register — every agent operating, its mission, owner and current autonomy level, and what changed since the last pack.
- Autonomy changes — every promotion or step-down, with the evidence and the name of the person who approved it.
- Evaluation — results against the thresholds set before launch, and any regressions after a change of model, instructions, tools or knowledge.
- Exceptions and incidents — boundary hits, escalations, incidents, time to contain, and what was changed as a result.
- Human review health — how long approvals wait, how often people override or edit agent work.
- Outcome and cost — per mission, against the process the agent replaced.
- Third parties — models, vendors and subprocessors that handle the organisation's data, and changes to them.
Buyers of the Guild's own services can ask for the equivalent at procurement: an architecture overview, a data-flow map, a role and access matrix, a model and vendor register, the evaluation approach, the incident process and the backup posture. A board should expect no less from its own teams.
If the pack needs a data scientist to read it, it is failing. Every line should be answerable by the operating owner in plain language.
Questions a director can ask tomorrow
- Can you show me every agent operating today, and the person accountable for each?
- Which agents can move money, change customer records or contact customers without a person approving?
- If we needed to stop one in the next ten minutes, who would do it, and how?
- When did an agent's model or instructions last change, and was it evaluated again before going back into service?
- What did the most recent boundary hit look like, and what did we change because of it?
- Who approved each agent's current level of autonomy, and on what evidence?
- Does any agent act with a person's credentials?
The answers will tell a board more about AI risk than any maturity score.
What a control model is not
It is not a library of policy documents: controls that exist only on paper are wishes. It is not a ban: the purpose of control is to make it safe to say yes to real work. And it is not a one-time sign-off: models, tools and data change, and every change reopens the question of evidence.
In practice, the controls have to live where the work happens — in the approval queues, the agent records and the activity ledger — so that the evidence a board asks for is a by-product of operating, not a report someone assembles the week before the meeting. That is how the Guild designs the Citadel, and it is what a board should ask of any system that lets agents act in its name.
For the implementation behind this model, read AI Governance Implementation. For how autonomy is earned level by level, read The Citadel Trust Model. And if your organisation is about to put its first agent to work, a Guild Assessment is a good place to draw the first version of this page.
