# Govern it: four questions and one page before the worker runs (/docs/agent/govern-it) --- type: Procedure title: "Govern it: four questions and one page before the worker runs" description: "The governance procedure from The AI Agent Factory applied to one worker: can AI do this work, can this information go in, can this capability be turned on, could this affect someone unfairly; a defined gate as who, what, when; data tiers; the five checks on a skill or connector; the one-page Governance Record; the first hour after a bad output; and why architecture and record must tell the same story." status: stable order: 8 generated: { by: "process:claude-code", at: 2026-09-09T06:45:00Z } verified: - { by: "human:rrizwan98", at: 2026-09-09T07:47:26Z } sources: - id: af-governance title: "Governance, Risk & Responsible Use: A Crash Course. The AI Agent Factory, Panaversity, 2026" resource: https://agentfactory.panaversity.org/docs/governance-risk-responsible-use-crash-course ksor: audience: [public] owner: human:rrizwan98 approval: { by: "human:rrizwan98", at: 2026-09-09T07:47:26Z } trust_tier: human-reviewed build_id: sha256:4d4bff09bd0a1dcff0a0a50f20f7ef514fc471e2b1f9e81e0e7b6150b93c0793 dirty: true --- The [delegation map](understand-the-work.md) left one gate open on purpose: may this data enter this tool at all? That question, and three beside it, is governance, and a policy document cannot answer it alone. A policy cannot look at the file on your screen, cannot decide whether the task needs the customer names, and cannot notice that a connector can now send messages as well as read them. Those decisions happen where the work happens, which means they are yours. The AI Agent Factory gives a decision procedure small enough that you will actually run it, written in a form a manager can review. [^af-governance] Before AI does meaningful work, ask four questions: [^af-governance] | Question | The three answers | | --- | --- | | **The Case.** Can AI do this work? | Yes, or **yes with a defined human review**, or no | | **The Data.** Can this information go in? | Yes, or **check first / add a control**, or not through this route | | **The Capability.** Can I turn this tool, skill, connector or action on? | Enable, or **escalate for review**, or decline | | **The People.** Could this affect someone unfairly or require disclosure? | Decide and document, or **disclose**, or escalate the question | The middle answer is where most professional judgement lives, because it is the only one of the three that obliges you to name something specific: a reviewer, a control, an approved route, a disclosure, an escalation. And "meaningful work" is a boundary: work that touches someone else's data, someone's money or a decision about a person. Rewording your own email does not qualify. A habit that costs ten minutes on every trivial task is dropped within a week, and then it protects nothing. [^af-governance] In this room, the four questions run on the worker before the [spec](write-the-spec.md) is approved, and their answers become the spec's rules, the harness's permissions and the evals' fairness cases. ## 1. The Case: can AI do this work? Four screens, the same ones the delegation map used on single steps, here applied to the whole use case: [^af-governance] | Screen | Plain question | | --- | --- | | Reversibility | If the output is wrong, can we catch and undo it before harm happens? | | Consequence of error | Is the cost trivial, expensive, harmful, regulated, or irreversible? | | Human judgement or empathy | Does the task depend on relationship, care, original judgement, or context a person should personally own? | | Accountability | Who is answerable for the outcome, and can that person meaningfully review and own what the AI produced? | Choose one of three answers: [^af-governance] - **Fully appropriate.** Low consequence, reversible, easy to review in the normal course of work. Drafting an internal FAQ from approved sources, restructuring notes, first-pass meeting summaries. - **Appropriate with human review.** Useful, but a specific human check is required before the output is used, sent, published or acted on. Drafting customer replies about billing, a management summary from financial data, a shortlist that influences who receives attention next. - **Inappropriate.** The task stays human-owned because the consequence, irreversibility or responsibility cannot be repaired by review. A final medical, legal, disciplinary or other professional determination. AI may support the work; it does not become the decision-maker because it can produce an answer. **Find the deciding factor.** If one of the four answers changed, which change would move the case into a different classification? That factor carries the decision, and naming it turns "this feels risky" into a sentence that can be checked, challenged and improved: "this is appropriate with review because the organisation remains accountable for the factual claim." [^af-governance] **A human in the loop is not a gate.** "A human will review it" sounds responsible and often means nothing in practice. A defined gate has three parts: [^af-governance] - **Who reviews:** the role that actually holds the responsibility. - **What they verify:** the specific risk the review is meant to catch. - **When they review:** before the output becomes hard to undo. "Someone will check it" is an intention. "The account manager checks delivery facts against the dispatch record before the report is sent to the customer" is a control. If you cannot write the gate in that form, the workflow is not ready to run. [^af-governance] In this room, that sentence is what `needs_approval` on a tool enforces and what the spec names as the reviewer. Consequence and accountability are different. A high-consequence task is not automatically prohibited; a well-designed gate can restore control. A low-consequence task can still require a human because the relationship is the point. Do not score the four screens and add them up. And accountability cannot transfer to a tool: a manager, clinician, lawyer or company does not become less responsible because an AI system drafted part of the work. [^af-governance] ## 2. The Data: can this information go in? A perfectly reasonable task can still be run on data that should not be placed in that tool or route. The order is: classify the data, ask whether the task needs the identifying details, confirm the route, choose the control. Do not start with a privacy feature and work backwards. [^af-governance] Three practical tiers, to translate into your own organisation's scheme rather than replace it: [^af-governance] | Tier | Means | Examples | | --- | --- | --- | | Green | Generally permitted | Public material, genuinely anonymised or aggregated data, internal material approved for broad use | | Yellow | Check first or add a control | Internal-only documents, personal contact information, customer or employee identifiers, confidential drafts, unannounced product information | | Red | Not through an unapproved route | Credentials, secrets, highly regulated or specially protected data, privileged material, third-party confidential information, licensed material whose terms forbid copying | If you are unsure between two tiers, use the more sensitive one until somebody authorised to interpret the policy confirms otherwise. [^af-governance] **The most useful data question: does the task actually need the identifiers, or only the pattern?** Analysing spending trends may not need customer names; reconciling one account may need the identifier. Redaction is the answer when the task does not need the sensitive fields, and it fails in two ways: partial redaction that leaves enough clues to identify the person, and redaction that removes what the task needed and produces a safe-looking, useless result. Replacing names with "Customer 17" is a first move, not a verdict: if anyone still holds the list that maps 17 back to a person, the data is pseudonymised, keeps its tier, and must not be stored or shared as if anonymous. It is anonymised only when it meets your organisation's standard for no longer being traceable, and it is that standard, not the relabelling, that lets the tier drop. [^af-governance] **The route matters as much as the tool.** An entry point is the specific route by which material reaches an AI system: a chat, a project, a temporary conversation, a file upload, a connector, an API, a desktop agent. Different routes have different retention, access, logging and training terms. So the question is not "is this AI product approved?" but "is this route approved for this data and this purpose?" Purpose does real work in that sentence: data arrives with the reason it was collected attached, and a new use of the same data needs to be covered by that reason or by a fresh permission. [^af-governance] Privacy and workspace controls answer narrower questions than people assume. A temporary conversation limits persistence; it does not decide whether the data was permitted to enter. A code-execution sandbox is an execution boundary, not an approval boundary: it limits where code can reach, and the information still entered a system whose outputs can still leave it. An instruction to the model not to retain the data is a wish, not a control. [^af-governance] For a worker, the data question is architecture: what the agent may read, what enters prompts and logs, how long it is retained, and which sensitive fields can be removed before the agent ever sees them. Do not rely on users remembering to redact what the architecture can remove. [^af-governance] This is why the [worked example](worked-example.md) keeps identity in the harness and lets tools filter by it, rather than passing a whole customer table to the model. ## 3. The Capability: can I turn this on? AI systems do more than generate text. They use skills, tools, plugins, connectors, web pages, files, code, browsers and other services, so the question is no longer "do I trust the model?" but **what authority am I adding to this session or agent?** Treat extensions like software, not like prompts, and do not judge them by the friendliness of the description or the fact that a colleague shared them. [^af-governance] One property matters more than any other, and it is the one people get wrong: **a skill does not carry its own permission list.** A connector has scopes you grant and can narrow. A skill runs with whatever access the session it runs in already has, so its reach is everything that session can reach, not only what its stated task needs. Where a skill's definition lists tools, that list pre-approves them so they run without prompting you: it widens what happens silently and does not narrow what the skill can touch. [^af-governance] Run five checks: [^af-governance] 1. **Source.** Who created or published it? 2. **Reach.** What data, files, systems, tools or credentials could it touch in the environment where it runs? 3. **Fit.** Is that reach proportionate to the job you actually need done? 4. **Outside content.** Will it read web pages, incoming email, customer files, shared documents, or other content you did not author? 5. **Actions.** Can it send, pay, delete, publish, edit, approve, or otherwise cause a hard-to-reverse change? The first three tell you whether the capability belongs in the workflow. The last two tell you how dangerous a mistake or a hostile instruction could become. Before you can answer the second, open the package: instructions, scripts, dependencies and files, because reading them is the only way to know what it does rather than what its description claims. The red flag is scope creep. And "internal" does not mean vetted: a skill built by another team was built for their convenience, against a policy that may have changed, for data less sensitive than yours. [^af-governance] Three outcomes: **enable** (source known, reach proportionate, task fits, actions controlled), **escalate** (useful, but something important cannot be established), **decline** (clearly disproportionate, untrustworthy, or unnecessary). A good escalation names the exact unresolved question: "this tool requests write access to our shared drive even though the workflow only requires reading; can security review whether that access can be narrowed?" That is far better than "can I use this?" [^af-governance] **Trusted tool, untrusted content.** A capability can come from a trusted publisher and still read content written by somebody you do not trust. An email, a web page, a customer upload or a shared document can contain instructions that attempt to steer the model, the family of attacks called prompt injection. Who wrote the tool and who wrote the content are two different trust questions, and the risk becomes much higher when a workflow both reads untrusted content and can take consequential actions. The default for ordinary work: let AI read only what it needs, prefer read-only access when it is enough, and keep send, publish, pay, delete, approve or irreversible edits behind a defined human gate until the workflow has earned a higher level of autonomy. [^af-governance] For agent builders, reach becomes architecture: scoped credentials, tool allow-lists, typed actions, confirmation policies, network restrictions, isolation, audit logs, and a clear separation between reading content and executing actions. The governing principle is least privilege: the narrowest authority that lets the job complete, revisited when the job changes. [^af-governance] The [harness](loop-and-harness.md) page is that list for this room: tools sorted allow, ask and deny, and a blocking guardrail in front of the loop. The [skill this room publishes](build-your-agent-skill.md) is subject to the same five checks. Read it before enabling it; it reaches whatever your coding agent reaches. ## 4. The People: could this affect someone unfairly? The first three questions mostly protect the organisation and its information. This one makes you look outward: [^af-governance] - Who is affected, including people who never see the output? - What could go wrong for them? - Would they be able to notice or challenge it? - What would a fair process look like? - Is disclosure required, or would AI involvement reasonably matter to them? Bias does not only arrive with the data. It can enter through the prompt, through the way the task was framed, or through the patterns in how language gets generated. A request to rank "the strongest candidates" carries an unstated standard, and the output inherits it. [^af-governance] **Look at who was excluded.** One of the easiest risks to miss occurs when the system narrows a set and humans inspect only the survivors: shortlists, fraud flags, tickets selected for escalation, leads selected for attention, documents selected as relevant. If AI systematically removes a group, nobody notices if the review looks only at what remains. The practical control is to **sample exclusions as well as inclusions**. [^af-governance] For a worker that triages, routes or filters, that means the eval set carries cases from the rejected side, not only the accepted one. **Disclosure: rules first, judgement second.** First, is disclosure required? Check law, policy, contract, professional rules, client commitments and organisational standards; if one of them requires it, the decision is made. Second, if no rule answers it, would AI involvement reasonably change this person's understanding of the work or the relationship? Routine tooling does not always need a label; consequential or relational work often deserves more. Work that goes out under your name is yours to stand behind however much of the drafting AI did. When no rule settles it and the case is ordinary, the default is to disclose rather than conceal. [^af-governance] **Escalate the question, not a verdict.** Three signals mean structured reasoning should not handle the case alone: the affected population is large, the potential harm is significant, or the question touches an area your team does not have standing to resolve, such as law, contract, employment or professional obligation. Any one is enough. A strong escalation gives the reviewer something specific to decide: the workflow, who is affected, the control added, and the point the framework does not settle. [^af-governance] ## The Governance Record: one page that survives the meeting The four questions are useful in your head. They become organisationally useful when the answers are written down, on one page for one workflow, with a fifth block that makes the controls checkable: a success measure, a failure threshold, who monitors and how often, and the residual risk that remains when every control works as designed. A blank field is better than a guessed one: write OPEN QUESTION and route it to the right person. [^af-governance] ```text GOVERNANCE RECORD Workflow: Owner: Date: THE CASE Classification: appropriate / appropriate with review / inappropriate Deciding factor: Gate: who ___ what they verify ___ when ___ THE DATA Tier: green / yellow / red Does the task need the identifiers? yes / no Fields removed: Approved route: THE CAPABILITY Tools, skills, connectors enabled: Source: Reach: Outside content it reads: Actions it must not take without review: THE PEOPLE Who is affected: Fairness check (including exclusions): Disclosure decision: required by ___ / judgement ___ Open question or escalation: THE EVIDENCE Success measure: Failure threshold: Monitored by: How often: Residual risk: RE-CHECK IF: model, feature, data, audience, permission, policy, vendor term, or business consequence changes. ``` Then share it with the person who owns the workflow, policy or risk, with one request: "This is how I propose to run the workflow. Please correct any assumption about approval, data route, reviewer, or control." The goal is not to collect signatures for every harmless task; it is to turn non-obvious assumptions into visible decisions before they become incidents. [^af-governance] The book runs one ordinary workflow through all five blocks: a weekly service report drafted from dispatch records and sent by an account manager. Classification: appropriate with review; deciding factor: accountability; gate: the account manager checks delivery facts against the dispatch record and reviews the tone on disputed accounts before the report is sent. Data: yellow, identifiers needed, so the route is confirmed rather than the names stripped. Capability: a read-only connector to the reporting tables, enabled after scope confirmation, with sending kept human. People: customers, but also the drivers described in failure notes, so attribution must match the record and phrasing is compared across reports. Evidence: the check completes before sending, any material factual error reaching a customer is the failure threshold, a monthly sample review, and a wording bias across all reports as the residual risk. One modest workflow produced a classification, a gate, a data route, a permission boundary, a fairness check and a monitoring plan. That is governance as work design, not paperwork added after the fact. [^af-governance] ## When something goes wrong: the first hour Governance is not the promise that nobody will make a mistake. It is the ability to surface mistakes early enough to contain them. Incidents come in five shapes: data entered a route not approved for it; an output went out with a material error; a tool sent, changed, deleted or approved something it should not have; untrusted content steered a system; a ranking or filter disadvantaged people and review did not catch it. [^af-governance] The first-hour procedure: [^af-governance] 1. **Stop the spread.** Do not forward, repost or create unnecessary copies. 2. **Record the facts.** What happened, what data or output or action, which route or system, when, and whether anything went onward. 3. **Report promptly** through your organisation's incident path. For sensitive or regulated cases timing may matter legally; do not wait for a perfect explanation. 4. **State the facts plainly.** No speculation, no self-defence. 5. **Follow the incident owner's instructions.** Do not independently decide deletion, notification, disclosure or evidence preservation. Do not quietly delete evidence and hope the issue disappears; deleting your visible copy may not delete organisational or vendor records, and it can interfere with required preservation. Report near misses too: a near miss reveals where the process is confusing or the approved route is too hard, without the cost of a full incident. [^af-governance] The four decisions the designer makes in advance so this procedure has something to act on are on [diagnose misbehaviour](diagnose-misbehaviour.md). ## Why governance drifts Routine decisions are more dangerous to governance than high-stakes ones, because each feels too small to count. A slightly easier tool, a review that becomes a glance, a connector that keeps permission after the project changed, a sensitive field that starts appearing in a dataset that used to contain none. The accumulated distance between the intended process and the actual process is the risk, and the book names it the diligence gap. [^af-governance] A lightweight audit of the work people actually do answers five questions: which AI workflows are in use, what data goes through them, did the defined gates really run, what tools, skills, connectors or permissions were added, and what changed in the model, feature, route, data or audience. A small quarterly sample is a reasonable start, more often during a rollout or after gaps are found. Audit the process, not the person: the purpose is system gaps, confusing rules, unnecessary friction, weak gates, stale permissions. And the friction rule: if the approved path takes ten steps and the unapproved path takes one, people under deadline pressure will find the one-step route. When you find repeated workarounds, ask what makes the approved way harder than the unsafe way; fixing that may reduce more risk than another reminder. [^af-governance] Re-check the record when any of these changes: model or model family; a product feature or retention behaviour; a connector, skill, plugin, permission or action; data type or sensitivity; source of outside content; audience or population affected; consequence of error; law, policy, contract or vendor terms. "Approved last year" is not a reason to skip review if the thing that was approved is no longer the same thing. [^af-governance] ## The one-minute checklist | Question | Quick check | The middle answer requires | The trap it catches | | --- | --- | --- | --- | | Case | Can AI do this task responsibly? | A defined gate: who, what, when | "A human will review it" with no loop defined | | Data | Can this information go through this route? | A control, data minimisation, or a confirmed route | Treating privacy mode as permission | | Capability | Should this tool or authority be enabled? | A specific security or admin review question | Assuming an extension can only do what its description says | | People | Could this affect people or require disclosure? | A fairness check, disclosure, or escalation | Reviewing only what AI selected, never what it excluded | Under all four sits the same trap: forcing the question into a plain yes or no, which produces recklessness and abandonment in equal measure. Then one final question: **what changed since the last time we decided this was okay?** [^af-governance] ## For agent builders: the four questions as architecture The framework changes shape when AI acts through software rather than waiting for a person to copy and paste: [^af-governance] - **The Case becomes an autonomy level.** Not "can the agent do this" but "what level has this task earned": draft only; propose an action for confirmation; act within a narrow reversible boundary; act autonomously only where reliability, monitoring and rollback justify it. - **The Data becomes custody and minimisation.** What the agent may read, where it stores, what enters prompts and logs, how long it is retained, which fields are excluded before the agent sees them. - **The Capability becomes scoped authority.** Narrow credentials, read-only where sufficient, explicit tool allow-lists, confirmation for consequential actions, audit trails, and separate identities for agents rather than shared human credentials. - **The People becomes evaluation and recourse.** Fairness testing across relevant groups, review of exclusions and false negatives, meaningful disclosure where required, a way to appeal or reverse consequential outcomes, monitoring after deployment. **The practitioner framework and the system architecture should tell the same story.** If the Governance Record says "human approves before send" but the API token can send without confirmation, the architecture has already overruled the policy. [^af-governance] That sentence is the acceptance test for the pages that follow. The autonomy level is the [autonomy dial](design-the-experience.md) and the `needs_approval` flag on [build the text agent](build-the-text-agent.md). The custody decisions are the tool bodies that filter by identity. The scoped authority is the allow, ask, deny sort on [loop and harness](loop-and-harness.md). The recourse is the eval set on [evals before shipping](evals-before-shipping.md), which must sample the excluded side. What this page does not replace: applicable law and sector regulation, your organisation's own privacy, security, records, HR, legal and risk policies, client contracts, formal security assessment of the architecture, structured model evaluation for high-impact systems, and legal advice on whether particular data is personal, anonymous, privileged or permitted. It gives a practitioner a way to recognise which question they are facing and to arrive at the right owner with useful reasoning. [^af-governance] With the record filled and the deciding factors named, continue to [tests first](tests-first.md); every gate you wrote is now a test. [^af-governance]: Governance, Risk & Responsible Use: A Crash Course. The AI Agent Factory, Panaversity, 2026.