AI Governance Implementation

The problem

Most AI governance is written for people. A policy says staff must not paste confidential data into public tools, that outputs must be reviewed, that high-risk uses need approval. People can read that and, mostly, comply.

Agents cannot be governed that way. They act at machine speed, through credentials, inside systems — and a policy that is not enforced in those systems is a wish. The failures are quiet: an agent with broader access than anyone remembers granting, an approval rule that exists in a document but not in the workflow, a model upgrade that went live without re-evaluation, and an audit question — "why did the agent do this?" — that nobody can answer.

Concept overview

Governance implementation turns intent into three kinds of artefact:

• Policies — rules precise enough to be checked by a machine: limits, allowlists, forbidden actions, required approvals. Each has an owner.
• Permissions — the identity, tools, actions, data and limits each agent actually has, enforced outside the agent.
• Audit trails — the record of what happened, who or what acted, under which policy, on what evidence.

Around them runs a loop: register the agent, tier its risk, control what it can do, evaluate it, approve consequential actions, record everything, and review on a fixed rhythm. Every agent the Guild deploys receives a role, an identity, approved tools, explicit limits, evaluation criteria and a named Human Wizard — that sentence is the loop in miniature.

When to use this

As soon as one agent can act — send, change, pay, delete — rather than only suggest. Scale the effort to the risk. An internal agent that drafts summaries for a person to edit needs a register entry, an owner and a light review. An agent that changes customer records or moves money needs every component below.

Architecture

Governance sits in four layers between the people who set the rules and the systems the agent touches.

The design principle is simple: the agent never enforces its own rules. Every tool call passes a policy check that the agent cannot see, edit or skip. If the check says no, the call does not happen, however persuasive the agent's reasoning.

Core components

Agent register

One entry per agent: mission, operating owner, risk tier, autonomy level per action, tools, data accessed, models and vendors used, evaluation status, last review. If an agent is not in the register, it should not have credentials.

Risk tiers

Tier by impact, not by technology. A workable scheme: advisory (outputs reviewed by a person before use), internal action (changes internal systems), external action (customers, partners, the public), and critical (money, personal data, legal commitments, anything irreversible). The tier decides the minimum controls.

Policy as configuration

Write rules the enforcement layer can evaluate: "refunds above the limit require approval by the support lead", "no tool may export more than a set number of records per day", "bank-detail changes require two approvers". Version them, test them, and give each an owner. Prose policies remain; each should point to the rules that implement it.

Identity and access

Each agent has its own identity and credentials, scoped to what its tools need, stored as secrets, rotated, and revocable in one step. Agents never use a person's account. Role-based authority, isolated credentials, least privilege and revocation are the baseline — the first of the six controls on the Guild's security and trust page.

Permission matrix

Agent × system × action × data scope × limit × approval requirement. This is the document security reviews, the configuration the enforcement layer applies, and the access matrix a buyer or auditor asks to see — ideally all three are generated from the same source.

Approval gates

Consequential actions wait for a named person. Each request shows the action, the responsible agent, the policy that triggered it, the supporting evidence and the effect of the decision. Field Guide 014 covers the patterns.

Audit trail

Record agent actions, human approvals, policy decisions, data access and configuration changes. For each event: actor, action, inputs and sources, the policy evaluated and its result, the approver if any, the outcome, the time, and the versions of model, instructions and tools in use. Make it append-only; no agent may edit or delete it. Keep it long enough for the questions you will be asked.

Change management

A change of model, instructions, tool, knowledge source or limit is a change to the agent. It goes through the regression suite, is approved by the owner, and is recorded. Unreviewed "small prompt tweaks" are one of the easiest ways for a governed agent to become ungoverned.

Incident management

Detect, contain, explain, improve. Containment must be fast: pause the agent or step it down a level in one action. Explanation comes from the audit trail. Improvement means a new scenario in the evaluation suite and, where needed, a new rule.

Model and vendor register

Which models and subprocessors handle which data, where, under which terms — and what changes when a vendor changes a model.

Implementation

1. Inventory. Find every agent and automation that can act, including the ones built by enthusiastic teams. Put each in the register with an owner.
2. Tier. Assign a risk tier and the minimum controls it implies.
3. Translate policy into rules. For each tier, write the limits, forbidden actions and approval requirements as configuration.
4. Enforce outside the agent. Put a policy check between every agent and every tool. Remove shared and human credentials.
5. Record. Turn on the audit trail before widening any permission.
6. Evaluate the controls, not just the agent (next chapter).
7. Set the review rhythm: owners monthly, a council checkpoint quarterly, and after every incident.
8. Map to external obligations. If you work to a management-system standard such as ISO/IEC 42001, a risk framework such as the NIST AI RMF, or sector and data-protection regulation, map each requirement to a record this system already produces. Take legal advice on what applies to you.

Evaluation

Test the controls the way an attacker or an auditor would.

• Forbidden-action tests — in a sandbox, try to make the agent exceed every limit, call every tool it does not have, and split one large action into small ones. Every attempt should be blocked and recorded.
• Approval tests — above and below every threshold, check that the right actions reach the right person.
• Revocation drill — revoke an agent's credentials and measure how long it takes to take effect.
• Reconstruction drill — pick a past action at random and rebuild the full story from the audit trail alone: what, why, on what evidence, under which policy, approved by whom.

In the Guild's scorecard these are the policy and approval dimensions: Sentinel owns the boundaries, Athena the approval points.

Security and governance

• Prompt injection is a governance problem. Text in documents, emails and web pages can try to steer the agent. Treat it as data; rely on enforcement outside the agent, not on the agent resisting.
• Separate duties. The agent never approves its own actions; the person who requested an action does not approve it; the people who build an agent do not sign its go-live alone.
• Minimise what the audit trail stores. Record references to personal data, not copies, where you can; protect the trail itself as sensitive.
• Watch the supply chain. Model and vendor changes can alter behaviour without any change on your side. Treat them as changes.

Cost considerations

Governance costs attention: owners' reviews, approvers' time, the build of the enforcement layer, audit storage. Scale it by tier so that advisory agents carry almost none of it.

The levers: generate the permission matrix, access review and trust documentation from one source of truth instead of maintaining them by hand; let evidence accumulate as a by-product of operating rather than assembling it before each audit; and move approvals to lighter patterns as agents earn trust. Compare the cost with the alternative — reconstructing an incident with no record, or pausing every agent because nobody can say which ones are safe.

Example implementation

Illustrative example, not a client engagement.

A professional-services firm runs three agents: an intake agent that qualifies enquiries, a support agent that answers client questions from approved documents, and a finance agent that prepares invoices.

The register shows that the finance agent was using a staff member's account. It gets its own identity the same week. Tiers follow: intake is external action, support external action, finance critical. Policies become rules: the support agent may not mention fees; the finance agent may prepare but not send invoices above a set amount, and may never change client bank details. A policy check now sits in front of every tool call. The first reconstruction drill fails: the support agent's answers did not record which document version they used. That is fixed before anything else is widened.

Failure modes

Checklist

• Every acting agent is in the register with an owner and a risk tier.
• Each tier has defined minimum controls.
• Policies are written as enforceable rules, versioned and owned.
• A policy check sits between every agent and every tool.
• Every agent has its own identity; no human or shared credentials.
• The permission matrix is the single source for access.
• Consequential actions route to named approvers with evidence.
• The audit trail is append-only and records policy, evidence and versions.
• Model, instruction, tool and knowledge changes pass a regression gate.
• Pause and step-down take one action, and have been rehearsed.
• Forbidden-action, approval, revocation and reconstruction drills run on a schedule.
• External obligations are mapped to records the system already produces.