The Ten Questions That Govern Any AI Agent

One instrument, asked in one order, of everything from an enclosed chat assistant to a fleet of coding agents with production credentials. Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it — with what a good answer looks like, what a bad one looks like, and the artefact each answer has to produce.

Why questions rather than a control list. A control list tells you what to build for the system you have today. A question set tells you what you do not know about the system you are about to approve, and it keeps working when the technology moves underneath it. Every question below ends in a dated artefact, because the answer that lives only in a reviewer’s memory is a conversation rather than a control.

Most AI governance fails at the intake, not at the control. A request arrives with a vendor demo and a sponsor, the conversation turns immediately to whether the model is any good, and the deployment is approved without anybody having written down what it is for, whose data it can reach, what identity it acts under or how it would be stopped. Six months later the questions are asked for the first time during an incident, which is the most expensive moment to ask them. The ten questions below are the intake. They are deliberately technology-neutral: they worked on robotic process automation, they work on a retrieval assistant, they work on an orchestrator running sub-agents, and they will work on whatever replaces those, because they ask about purpose, authority, reach and recovery rather than about architecture. Each one names what a good answer looks like, what a bad answer looks like, and the artefact the answer has to produce — because the artefact is what survives the person who ran the review and the only part an assessor can examine.

One more thing about who asks. The team that built the system answers, and somebody who did not build it asks. That separation is the whole mechanism, and it is the reason a self-assessment form emailed to a build team produces different answers to the same ten questions asked out loud by someone with no stake in the outcome. Where the reviewer needs to be independent of the people using the tools, that is what a fractional CISO or DPO engagement is for.

Read the cells as cumulative from left to right: “as T3, plus” means the T3 requirement still stands. A system sitting at T3 on capability does not get to answer question eight at T1 depth because the logging was inconvenient — the tier is assigned once, at question four, and it governs the whole row of answers. Where a team wants to answer at a lower depth than the tier requires, that is a condition with a date and a compensating bound, not a quieter reading of the matrix.

The instrument keeps insisting that an answer has a number in it, so it owes you numbers to start from. These are defaults — the position a reviewer should open with, and which a team is entitled to argue down with a reason that gets written onto the record. Nothing here is a published requirement of any framework, and no assessor will hold you to this table. Two of the rows are rules rather than defaults, and those are not negotiable: log retention must equal or exceed the longest examination period you expect plus the lag before anybody asks, and the stop test re-runs on capability change rather than on the calendar, because a stop tested on a system that has since gained two tools has not been tested.

Purpose is the only thing that converts “it did something unexpected” from an opinion into a finding. Without a written scope, an agent that starts issuing credit notes after a prompt change has not deviated from anything — it has merely surprised somebody, and surprise is not a control failure you can act on. With a written scope that says credit notes are out, the same event is a defined deviation with an owner, a severity and a record. The cost of not writing it down is not felt at approval. It is felt eight months later in the argument about whether anything actually went wrong.

Purpose also does the scoping work for the rest of the review. It determines which data classes are legitimately in reach, which makes question three answerable. It sets the boundary that question nine measures drift against. And it is the thing that lets you decline a capability request without relitigating the whole deployment: a tool that is useful but has nothing to do with the stated purpose is declined on scope, which is a two-minute conversation, rather than on risk, which is a two-week one.

Write it as an outcome and a trigger, not as a capability list. “Summarise, search and draft” describes a product. “Classify inbound support email within five minutes of arrival and route it to the correct queue, for the EMEA support inbox only” describes a job, and a job has edges. The out-of-scope list should name at least three actions the system will not take, chosen from the ones somebody in the room would plausibly ask for next quarter — because that is exactly when the list will be read.

The purpose record, which becomes the first field of the registry entry and the reference point for every later reassessment.

Where it lands. CC3.1 asks the entity to specify objectives with sufficient clarity to enable the identification and assessment of risks relating to them. Intended purpose is a defined term in the EU AI Act, and classification under that Act turns on it.

Read next: Vendor approval is not use-case approval · When a tool becomes an agent

The inbound flow is what leaves your boundary and reaches the model: prompts, attachments, retrieved passages, system instructions. It is the flow most policies are written about and the easiest to reason about, because somebody chose to send it. The outbound flow is where results land — a ticket field, a channel, a customer’s inbox, a repository — and it matters because an output containing personal data is a disclosure to whoever can read its destination, regardless of how carefully the input was handled.

The flow in the middle is reach: everything the system could retrieve if asked the right question. This is where confident answers go wrong, because reach is not the connector’s description, it is the entitlement of the identity the retrieval runs under. A connector documented as “read-only access to the knowledge base” held by an identity with tenant-wide read scope can reach the whole document estate, and the only honest way to establish that is to export the grants and read what was actually approved. Architecture diagrams describe intent. Permission exports describe reality, and they disagree more often than anybody expects.

Two things must be sourced rather than asserted. Whether the vendor retains inputs, for how long, and whether they are used to improve models differs by product and by plan tier and changes over time — record the position with the documentation link and the date you checked it, so that a reassessment can detect a change rather than re-argue the point. And where personal data is in any of the three flows, the processor contract is a precondition rather than a follow-up: Article 28(3) of the GDPR requires the processing to be governed by a contract, and section 8(2) of the DPDP Act 2023 requires a valid contract where a Data Processor is engaged for any activity related to offering goods or services to Data Principals.

The data-flow record plus the raw permissions export it rests on, both attached to the registry entry rather than summarised into it.

Where it lands. CC6.1 and CC6.7 on access to and movement of information, C1.1 where confidentiality is in scope, and the processor-contract requirements of GDPR Article 28(3) and DPDP Act 2023 section 8(2) where a processor is engaged for an activity related to offering goods or services to Data Principals.

Read next: Connectors and permission inheritance · Copilot oversharing and permission hygiene

Capability is the union of the tool surface the deployment has been offered and the entitlements of the identity it acts under. Assessing only the first produces a confident, wrong answer — a manifest of four innocuous-looking tools held by an identity with write access to the ticketing system is a write capability, whatever the tool names suggest. Assessing only the second misses the case where a single tool called something like `run` accepts a free-text parameter and is, in effect, every capability the runtime has.

The second half of the question is the one that produces useful risk information: what is the worst thing it can do that cannot be undone before anybody notices? Consequence has two dimensions. Reversibility — a draft in a queue is recoverable, a sent message is not. Externality — an internal record is contained, a customer-facing action is not. And one category deserves separate treatment entirely: an agent that can change access, alter security configuration or create other identities is acting on the control environment itself, so a failure there degrades every other control you rely on rather than producing one bad outcome.

This is where the tier assignment is made. The five tiers set out in when a tool becomes an AI agent run from T0 to T4. T0 is an enclosed assistant with no reach. T1 is grounded retrieval that reads but changes nothing. T2 is assisted action where a human approves each specific change. T3 is a delegated agent acting unattended inside a bounded blast radius. T4 is a privileged agent acting unattended on things that are hard to undo or that govern other controls. The depth matrix near the top of this page states what each of the ten questions requires at each of those five. The OWASP Top 10 for LLM Applications, 2026 edition, published on 4 August 2026, carries Excessive Agency at LLM03 — up from sixth place in the 2025 edition, the largest upward move on the list, and driven by production incidents in agentic systems. That promotion is the industry restating this question: the capability you granted, not the model you chose, is what determines how badly a failure goes.

The capability record: the exported manifest, the classification against each tool, the worst-action statement, and the resulting tier with the reason it was assigned rather than just the letter.

Where it lands. CC8.1 on change management over the tool surface, and the access criteria through the identity half. Excessive Agency sits at LLM03 in the OWASP Top 10 for LLM Applications, 2026 edition.

Read next: When a tool becomes an AI agent · MCP tool approval and capability change · Spending and transaction limits

There are only three oversight designs that survive contact with volume, and the review should make the team name which one they are using. Pre-action approval: a human reads and approves each specific action before it takes effect, which is the strongest and the one that degrades fastest under load. Sampled post-hoc review: actions take effect unattended and a defined sample is reviewed afterwards, with the sample size and selection method stated. Exception-triggered review: actions proceed unless they cross a stated threshold — value, volume, sensitivity, novelty — at which point a human decides. Most real deployments need the third with a thin layer of the second, and describe themselves as having the first.

Oversight fails in a specific, predictable way, and the failure is measurable. A reviewer approving a hundred proposals an hour is not reviewing. A reviewer whose only information is a summary generated by the same system they are checking is confirming the system’s own account of itself. A reviewer with no standing to refuse — because refusal means a queue backs up and their manager asks why — has responsibility without authority. Automation bias does the rest: once a system has been right for six weeks, the reviewer stops reading and starts confirming, and no amount of policy language reverses that. Design against it by making refusal cheap and by measuring the refusal rate, because an approval rate of one hundred per cent is evidence of absence, not of quality. The refusal rate is the summary signal, but the approval log carries four more legible signatures of the same decay and they arrive earlier: (1) approval latency collapsing toward a floor over successive weeks, (2) a modal approval time in single-digit seconds against a payload nobody could read in thirty, (3) approvals arriving in bursts at shift boundaries, which is a person clearing a queue rather than reading it, and (4) an amendment rate of zero, which is rarer in genuine review than a refusal rate of zero and harder to explain. Pull those four from the approval records you already hold before commissioning any new instrumentation.

Where the EU AI Act reaches you as the provider or deployer of a high-risk system, Article 14 of Regulation (EU) 2024/1689 sets human oversight obligations for those systems specifically — the oversight has to be designed so the people assigned to it can actually understand the system’s capacities and limitations, monitor its operation, and intervene or interrupt it. The stand-alone high-risk obligations have been deferred, and the dates are set out once in the framework map further down this page. Treat that as more time to build the control rather than as an exemption from it. Whether the Act reaches a given deployment at all is a separate scoping question, and many internal enterprise deployments are not high-risk systems — though Annex III reaches internal uses in recruitment, worker management and access to essential private and public services, so the determination has to be made rather than assumed.

The oversight design note plus the approval records it generates, and — the part teams forget — the refusal sample that proves the gate can close.

The design is implied by three properties of the action, not by preference: whether it can be undone, whether anybody outside the organisation sees it, and how many of them there are in a day. Derive it from the table, then write down which row you landed on — a team that can name the row can defend the design, and a team that chose a design first will find itself defending the interface instead.

Wherever the design includes a sampled component, two things have to be written before the period starts rather than after it: how many items, and how they were chosen. An unstated selection method is the defect that gets a sample rejected — not because the items were badly chosen, but because nobody can show they were not chosen after the fact. Use random selection within the period, or risk-stratified selection with the strata named: value band, novelty flag, and the first week after any capability change. Read the numbers below as planning figures for your own review, not as a table anybody can hold you to.

Where it lands. CC5.2 on selecting and developing general control activities over technology, and the monitoring criteria where review is the control. Article 14 of the EU AI Act, Regulation (EU) 2024/1689, sets human oversight requirements for high-risk systems.

Read next: Human-in-the-loop that actually means something · Prompt injection and tool calls

Failures come in three shapes and only the first is detected by default. Loud failures throw an exception, the job goes red, somebody is paged. Every platform gives you these for free. Quiet failures return success. The agent classified four hundred tickets into the wrong queue, summarised the wrong quarter, closed cases it should have escalated — every call returned 200, every dashboard is green, and the failure surfaces when a customer complains or a month-end reconciliation refuses to balance. Adversarial failures are quiet failures someone caused on purpose: the system followed instructions that arrived inside the data it was asked to process, which is prompt injection — LLM01 in the OWASP Top 10 for LLM Applications, 2026 edition, and the failure shape that gets worse, not better, as you give an agent more tools.

The useful form of this question therefore has a number in it. Not “would we detect it” but “how many hours would pass before somebody knew, and who would that somebody be?” Answering that forces the design work, because the honest answer for most quiet failures at first pass is “a customer would tell us, eventually”. That is a real answer and should be recorded as one — it is a detection latency of days measured in complaints, which is a finding, and findings get fixed in a way that vague reassurances do not.

Instrumenting the quiet class means finding signals that describe outcomes rather than execution — and the highest-value one, the rate at which a human reverses or edits what the agent did, is almost never collected, because it lives in the downstream system rather than in the agent’s own telemetry. The table below sets out what each failure shape looks like in the three places somebody would actually be looking, and the metric that catches each one.

The detection table, plus evidence that at least one of its rows has fired in anger and been investigated to a conclusion.

Naming the three shapes is the easy half. The half that decides whether you detect anything is knowing what each one looks like in the three places somebody would actually be staring: the tool-call log, the approval record, and the system the agent acted on. Read the last column as the cost of not instrumenting the row.

A threshold with no stated baseline is a number somebody liked. Take the queue-distribution monitor for a triage agent as the worked case. Baseline: each queue’s share of daily volume across the four weeks before the agent went live, which is the last period in which the distribution was known to be produced by people. Threshold: any queue’s daily share moving more than eight percentage points from its trailing twenty-eight-day mean, on two consecutive days. Two days rather than one because single-day swings track business events — a product incident moves the distribution legitimately, and a monitor that cannot tell those apart gets widened until it catches nothing. What the setting costs: you are choosing the reviewer’s workload as much as the sensitivity. Tune it so the alert fires on the order of once a fortnight and each firing costs fifteen minutes to resolve, because the alternative — a threshold set where nothing ever crosses it — is the failure this whole question exists to prevent. Write the baseline period, the statistic and the accepted false-positive cost onto the detection table beside the number, so the next person can argue with the calibration instead of guessing at it.

Where it lands. CC7.2 on monitoring for anomalies and CC7.3 on evaluating whether events constitute incidents. Prompt Injection is LLM01 in the OWASP Top 10 for LLM Applications, 2026 edition.

Read next: Monitoring agents that work unattended · What counts as an AI incident

An AI deployment does not change the way a server changes. The model underneath it can be updated by the vendor without a deployment on your side. A connector can gain a scope through a platform update. A tool server can add a capability, or change what an existing tool’s description tells the model it is for, without anything in your repository changing. An annual review catches none of this, because the thing it would have caught happened in March and was corrected by the time the review sat in November — or was not corrected, and has been operating unassessed for eight months.

So the answer is a register of triggers, and each trigger needs three things beside it rather than one: how the event becomes known, who acts when it does, and what a firing obliges. The first of those is where most registers fail, because a trigger you cannot detect is not a control — it is a hope. The nine triggers worth registering are set out in the table below, each marked as mechanically detectable or dependent on somebody confirming it, which is the distinction that decides whether the row needs a cadence attached to it. Purpose drift sits last on that list and is the one that only exists at all because question one was answered in writing: without a scope statement there is no event to detect, only a behaviour somebody might find surprising.

Where a trigger genuinely cannot be detected, say so and set a floor cadence rather than pretending otherwise: “data class change — not detectable, owner confirmation each quarter” is honest and testable, while “data class change — monitored” is neither. And record what the last reassessment actually changed. The diff is more informative than the date, and four consecutive reassessments with no diff is a strong signal that nobody is really looking.

The trigger register, and the reassessment record that shows a trigger firing and producing a changed answer.

Nine triggers, each with the three columns that turn a list into a control. The third column is the one to read first: where a trigger is confirmation-only, the register has to carry a cadence against it, because nothing will tell you the event happened. Two of the nine are confirmation-only in most estates, two more depend on setup, and saying so is what makes the other five believable.

Where it lands. CC8.1 on authorising and tracking changes, and CC3.4 on identifying and assessing changes that could significantly affect the system of internal control.

Read next: When a model changes, what do you reassess? · AI supplier due diligence and ongoing review · Risk assessment versus impact assessment

Stopping is not one action, it is four, and a review should establish which of them the team actually has. Pause intake: the agent stops receiving new work but finishes what it holds. Revoke credentials: its identity is disabled, so subsequent calls fail — though anything already authorised may still land. Revoke at the resource: the downstream system stops accepting the agent’s calls regardless of what token it presents, which is the level that matters when a credential has been cached somewhere you did not know about. Hard shutdown: the runtime is terminated, in flight or not. The four have different blast radii and different recovery costs, and the incident at 03:00 is not the moment to discover which one your runbook meant.

Two properties decide whether the answer is real. First, who can execute it. A stop procedure only the building team can run is unavailable during exactly the hours unattended agents are most active. The population with stop authority must include whoever is on call, and it must be more than one person — a single named individual on annual leave is an outage in your control, not a control. Second, whether it has been tested since the deployment changed. A stop tested once at build time, on a system that has since gained two tools and a sub-agent, is a test of a system that no longer exists.

The part almost everyone omits is what happens to work in flight: the half-completed transaction, the queued batch, the message composed but not sent, the pull request opened but not merged. Does the queue drain on restart, silently executing every decision made under the conditions that caused you to stop? That is a real failure mode with a plain name — the stop worked and the resumption undid it. Write the disposition down per action class and per reason for stopping, as in the grid below, and test the resumption rather than only the stop.

The stop procedure and the dated stop test, with the measured time and the in-flight disposition. This is the single most convincing artefact in the whole review, and the cheapest one to produce honestly.

The disposition is not a single policy, because it depends on both what the item would do and why you stopped. Abandon means the item is discarded and its originator told. Hold means it is queued for a person to decide, which is not the same as resuming when the queue drains. Resume means it completes on restart. Settle the grid before the incident, because at three in the morning the default will be whatever the platform does.

Two rules sit underneath the grid. Resumption requires the cause of the stop to be recorded as closed, not merely elapsed — a stop that expires on a timer is an outage with extra steps, and it is how a stop gets undone by its own resumption. And the authority to restart rises with the tier: at T0 and T1 the owner, at T2 the owner or deputy, at T3 the operating owner plus one person who did not build it, and at T4 the accountable executive, with both the reason for the stop and its closure written down before the first held item is released.

Where it lands. CC7.4 on responding to identified security incidents and CC7.5 on recovery from them. The availability criteria apply where stopping the agent degrades a service you have committed to.

Read next: Kill switches and circuit breakers for AI agents · What counts as an AI incident

“Approved with conditions” is the verdict that carries the estate, so it needs a field list of its own. A condition that is not written on this shape decays into a recollection that somebody was going to do something.

The difference between a condition and a decline should be a rule, not a judgement made freshly in each room — otherwise the same gap is carried for one team and refused for another, and the second team is right to be annoyed about it. The rule generalises across all ten: a gap is condition-eligible where a compensating bound can hold the risk until it closes, and it is a decline where no bound exists that a reviewer could write down.

An overdue condition has exactly two dispositions and reissuing it is not one of them. Either it is renewed — by a named approver at or above the level that approved the original, with a new expiry and a written reason the first date was missed, once and not twice — or the deployment stops, at the level question ten specifies. That is the practical reason question ten is answered before the verdict rather than after it: the enforcement mechanism for every condition on the list is the stop, and a condition register standing behind an untested stop is a register with nothing behind it.

These are not answers to be improved in the next draft. Each one means a question further up the list has failed in a way that makes everything below it unsupported, and the right response is to halt the review and fix the specific thing rather than to continue collecting answers that now rest on nothing.

Two patterns run through the rejected column and they are worth naming, because between them they account for most of what gets handed back. The first is a description standing in for an export — a diagram instead of a permissions query, a design document instead of a manifest, a policy instead of a record. The second is a date outside the period, which is how an artefact produced in good faith during fieldwork ends up evidencing nothing about the twelve months being examined. Both are cheap to avoid in advance and expensive to fix afterwards, because the second one cannot be fixed at all: you cannot retrospectively export something as it stood in March. How selection and sample sizes work once a population exists is set out in SOC 2 sampling and sample sizes.

Three findings in that sequence are worth separating from the narrative, because they are the ones that recur. The permissions export disagreed with the design document — it often does, and the disagreement frequently reaches well beyond the deployment being reviewed, which is why question three tends to generate an access finding rather than an AI finding. The tool manifest had three tools nobody described, one of which generalised to anything the runtime could reach. And the reconstruction test failed the first time, on a system whose logging everybody believed was adequate, for the specific reason that tool arguments were not being captured. None of the three would have surfaced from a questionnaire. All three surfaced from asking for an export.

Ninety days does not finish the backlog and it is not supposed to. What it finishes is the machinery: a published instrument, agreed tier boundaries, a working forward queue, an enumerated estate, a triaged backlog and a condition register with a cadence. The backlog then drains at whatever rate the review capacity allows, in an order somebody can defend. The enumeration itself — the sources, what each one finds and what each one misses — is set out in the AI system inventory and registry, and the systems that will not appear in any of those sources are the subject of shadow AI governance.

Inheritance is the answer to the scaling objection, and by this page’s own rule an answer that produces nothing is a conversation. So the pattern is a record, on the same shape as the ten:

The scaling answer has its own page: governing hundreds of agents covers risk classes and inheritance in detail, and AI competence covers what the people answering these questions need to know before their answers mean anything.

Two of these have dedicated treatments elsewhere in this wing: shadow AI for the systems your process never sees, and MCP server governance for the tool surface that changes without a deployment on your side.

Related reading: when a tool becomes an AI agent, the AI system inventory, vendor approval is not use-case approval, human-in-the-loop that actually means something, monitoring agents that work unattended, kill switches and circuit breakers, and the ISO 42001 hub.