RiskMandate v1.34.10
ARTICLE · 24 SEPTEMBER 2026

Who owns what in AI. And how accountability holds on the way up.

An infographic shared on LinkedIn, Who owns what in AI (By Role), maps thirteen roles, from the board to all employees, to what each one owns in AI and what that protects. It is a good place to start, and every company will redraw it for itself. What a one-page map has no room for is the other direction: how a risk that begins with one agent’s access travels to the board, in whose words, accepted by whom, and until when. This article adds that direction, works it through on one agent, and ends with the model in enough detail to build.

Responding to: “Who owns what in AI (By Role)”, by Alex Miguel Meyer, shared on LinkedIn and sent to us on 24 September 2026. Its rows are quoted in section 01 so the argument can be followed; the image is the author’s and is not reproduced here.

The worked example: an invented company and an invented agent. Nobody’s system was tested. The one product fact used is quoted from the vendor’s own page, with its date.

The figures: three on this page are drawn by script from the article’s own data, and one of them can be played and changed. The page loads nothing from anywhere and sends nothing.

This page as markdown: article-who-owns-what-in-ai.md

01 · The map

Thirteen roles, what each owns, and what it protects.

The infographic’s subtitle is “Different roles. Clear ownership. Better outcomes.” It reads left to right: a role, an arrow to what that role owns in AI, and an arrow to what the ownership protects. Its thirteen rows, as written:

RoleWhat they ownWhat it protects
CEO / LeadershipAI vision, strategy and business outcomesLong-term value and competitiveness
BoardOversight, risk appetite and accountabilityTrust, compliance and sustainable growth
CFOInvestment, ROI and financial controlsFinancial discipline and value creation
COOOperational integration and process changeEfficient, scalable operations
CTO / ITTechnology infrastructure, security and system reliabilityStable, secure and resilient systems
CIO / DataData quality, access and data governanceAccurate, trusted data for better decisions
CISOThreat management and data protectionReduced risk and organisational safety
LegalRegulatory compliance, contracts and IP rightsLegal protection and responsible use
HRPeople readiness, upskilling and change managementA future-ready workforce and higher adoption
MarketingResponsible content use and brand consistencyBrand trust and customer confidence
SalesEthical use in customer engagement and pipelinesCustomer trust and revenue growth
ProductAI features, user experience and model performanceCustomer value and product-market fit
All EmployeesResponsible day-to-day use and feedback from the fieldSafe, practical and high-impact adoption

Source: “Who owns what in AI (By Role)”, Alex Miguel Meyer, LinkedIn. Text transcribed from the image on 24 September 2026.

Why we are building on it. The lead’s reaction on seeing it was that it is a very good mapping, and the reason is specific: it is about levels of responsibility. It puts AI on every role’s desk rather than on IT’s alone. It gives the board “oversight, risk appetite and accountability”. And it ends with all employees, who are the people actually connecting agents to their mail, their calendars and their customers’ records. Everything below depends on those three things.

What it is, and what it is not. Across its thirteen rows, the word risk appears twice, in the board’s row and the CISO’s, and accountability once, in the board’s. No row mentions an agent. None of that is an omission to point at: a one-page map of who owns which area is a different object from a record of who answers for a given risk. The second is what this article is about, and it needs the first.

02 · Every company redraws it

A generic map, and yours will differ.

Every company that uses a map like this will have its own levels of responsibility. In a twenty-person startup the CEO is also the CFO and signs for security. A bank adds a chief risk officer and a data protection officer. A UK government department has a senior information risk owner. That is how it should be. Our own framework is generic in the same way, and it is adjusted everywhere it is used. So the useful question is not whose map is right. It is which parts a company may change and which parts must stay fixed, so that accountability still holds after the adjusting.

Each company sets

The people, the lines and the limits.

  1. The roles, and what the company calls them.
  2. Who reports to whom, up to the board.
  3. What each role may accept, and for how long: the board’s risk appetite, handed down.
  4. The words each role uses for a risk.
  5. How long silence is allowed before a risk moves up. A week, in the example below.
Stays fixed everywhere

The grammar.

  1. Every risk has one holder at a time.
  2. Every holder answers to somebody, and every path ends at the board.
  3. Nothing is denied. A risk is accepted for a stated interval, the work to end it is funded, or it is fixed.
  4. Silence is not a decision. An unaccepted risk moves up.
  5. Every risk names the facts that make it true and the facts that would end it.
  6. The behaviour policy scores nothing.
03 · Sideways and upwards

The map runs sideways. Accountability runs upwards.

Every arrow on the map points to the right: a role, what it owns, what that protects. That is the right shape for describing areas. A risk does not stay inside one area, though. It starts at a fact somewhere low, such as a connector’s scope or a setting nobody changed. From there it has to travel until it reaches somebody with the authority to accept it, fund the work that ends it, or fix it.

Sideways

The middle column is a routing table.

When a risk appears, “what they own” says whose area it touches. Customer data leaving the company is the CIO’s and the CISO’s. Mail to customers is Sales’. What goes out under the company’s name is Marketing’s. Read this way, the map already does half the work: it says where a risk lands.

Upwards

The organisation chart is the escalation path.

Each holder answers to somebody, and the chain ends at the board. Three verbs travel along this path that the map does not draw: accepts, for a stated interval; answers to, when the holder cannot or does not decide; and can stop, which says who can switch the agent off, and how quickly.

Both directions are needed, and joining them is the whole design. The map says which holder a risk goes to. The chain says where it goes next when that holder has no authority to accept it, or simply does not decide. What keeps accountability intact on the way up is that the risk is carried: the same exposure, in each holder’s own words, linked to the one below it and not retyped.

04 · Where a risk starts

One agent, and its Agent Behaviour Policy.

The example is invented, and deliberately ordinary. A company of about two hundred people sells software to other businesses. A sales representative connects an AI assistant to their own email, calendar and customer relationship management system (the CRM), so it can draft follow-ups and suggest meeting times. Their manager says yes. Nobody else is asked, because nothing about it looks like a decision.

An Agent Behaviour Policy (ABP) is the record of one agent in one deployment. It lists everything the agent can do (the grant), what it was authorised to do (the mandate), the gap between the two, and what stands in the way of each thing in the gap. It scores nothing. For this agent it has nine rows. One of them, the last, is the reason the table is worth reading twice: the mandate says my own mail, and the grant does not know the difference.

What it can doAuthorised?What stands in the wayCan it be undone?In the vocabulary
1 · Read the rep’s own mail, including mail from anybody outside the companyyesnot needednothing changesread.message.tenant
2 · Write drafts for the repyesnot neededyes: a draft is not sentoutside the 23 primitives; recorded as written
3 · Send mail as the rep, to anybodyno: drafts onlyan expectation: its instructions say “always ask before sending”no, once sentsend.message.world
4 · Read every CRM record the rep can seeyesnot needednothing changesoutside the 23; recorded as written
5 · Update any CRM record the rep can update, not only the rep’s own accountsonly logging calls on the rep’s own accountsnothingas far as the CRM keeps historyoutside the 23; recorded as written
6 · Export CRM records in bulknonothingno: data that has left cannot be recalledoutside the 23; recorded as written
7 · Create, edit and delete events on every calendar the rep can edit, including the shared calendar the company books customer meetings onno: it suggests times, and the rep booksnothinga delete often goes to a trash; an edit often cannot be restoredoutside the 23: no primitive names a calendar event
8 · Act in each account as the repyes: it has tonot needednot an actionauthenticate-as.credential.tenant
9 · Read the shared sales inbox that every rep is delegated to, so every customer’s mail to the whole teamno: my own mail onlynothing: the mail scope covers every mailbox the account can opennothing changesread.message.tenant
9in the grant
4in the mandate
5excess: can, and was not asked to
5unbounded excess: nothing out of the agent’s reach in the way
0shortfall: asked to, and cannot

How to read the barrier column. What stands in the way is one of four kinds, weakest first: nothing; an expectation, a rule in prose that nothing enforces, such as a line in the agent’s instructions; a setting the agent’s own account could switch off; and a boundary, enforced by something the agent cannot reach. Only a boundary is a control. That is why row 3 counts as unbounded even though the instructions forbid it. Unbounded excess is the one number a control can move: each real control turns a row into a boundary, and the count falls.

On row 7: in Google Calendar, for example, a deleted event stays in the trash for 30 days, and Google’s pages document no way for a user to restore an edited one (read 24 September 2026; the details are in a separate article). On row 8: unless the product marks what an agent did, every record shows the rep did it.

Rows 1, 3 and 4 together are what Simon Willison named the lethal trifecta: “Access to your private data… Exposure to untrusted content… The ability to externally communicate in a way that could be used to steal your data” (16 June 2025). This agent has all three, and an instruction is the only thing in the way. Row 9 widens the first of them from the rep’s mail to the whole team’s.

From rows to risks. Each row is a fact, with its source, and rows in the mandate establish risks too: the difference is that those are inside the authority of the person who connected the agent, and they accept them by connecting. That is the level the business already lives with, and it belongs in the record so that the line between it and the gap is visible. The facts establish seven risks. At first each is written the way the rep would say it:

The risk, as the rep would say itEstablished byEnded by
R0 · “It reads everything in my inbox, including what is not about work.”row 1, which is in the mandatenothing, while reading is what it is for. Inside the rep’s own authority: the rep accepts it on connecting, for a month at a time
R1 · “It can send as me, to anybody, before I have read it.”row 3, with only an expectation in the waysending that needs approval the agent cannot give itself (a boundary), or sending removed from the grant
R2 · “An email from a stranger could tell it to send our customer data out.”rows 1, 3 and 4, all togetherany one of the three removed, or bounded
R3 · “It can take the customer list out.”row 6export removed from the grant, or bounded
R4 · “It can change accounts that are not mine.”row 5the CRM limiting the rep, and so the agent, to the rep’s own accounts
R5 · “It can rearrange the shared calendar, and nobody could see what it said before.”row 7calendar access narrowed to the rep’s own calendar, or a copy of every event kept before each edit, somewhere the agent cannot write
R7 · “It reads every customer’s mail to the whole team, not only mine.”row 9the shared inbox out of the agent’s reach, which the mail scope cannot do by itself: the delegation would have to be removed from the account
RL · “Customer mail goes to the model provider, and what we tell customers does not say so.”row 1: everything the agent reads is sent to the provider to be readprocessing terms with the provider, and a notice to customers that says so. Legal holds it
RC · “Nothing in our cover says whether an act of the agent, as the rep, is covered.”row 8: it acts as staffthe insurer confirming, in writing, what it covers. The CFO holds it

A control does not make a risk zero. It trades a red risk for a green one. Every control in this article carries a residual risk of its own, smaller, inside somebody’s authority, and accepted the day the control lands: an approval step is a person clicking, and people get worn down (the CISO’s); a message approved in a hurry still goes out (the rep’s); a CRM that limits reps to their own accounts still takes wrong entries at machine speed (Sales’); a proxy that carries out every write under the ABP’s rules is now the thing that can fail, and its log is a copy of customer data (the CTO’s, and Legal’s). These belong in the record beside the risks they replaced, because they are what the business is actually running once the controls are in, and because the ABP is where the controls are written down: each one is a barrier on a row, with who holds it. The figure in section 05 draws them in green.

05 · One exposure, thirteen voices

The same agent, in each role’s own words.

Here is the agent’s exposure as each of the map’s thirteen roles would put it, from the bottom of the company to the top. The map’s middle column decides whom it reaches. Its right-hand column says what each of them stands to lose, quoted as written. Each statement is linked to the risks below it and never retyped, so when those end, the ones above know.

RoleThe exposure, in their wordsWhat the map says it protectsComes from
All Employees“It can do more than I asked it to, and it all looks like me.”Safe, practical and high-impact adoptionR0, and R1 to R7
Sales“Mail can reach our customers that nobody in the team wrote or read, and account records can change without the account’s owner knowing.”Customer trust and revenue growthR1, R4, R7
Marketing“Messages can go out in the company’s name that nobody reviewed.”Brand trust and customer confidenceR1
CIO / Data“Customer records can be changed or exported through an agent, and the record says a person did it.”Accurate, trusted data for better decisionsR3, R4
CISO“A stranger’s email reaches an agent that holds customer data and can send mail anywhere, with nothing but an instruction in the way.”Reduced risk and organisational safetyR2
Legal“Personal data about customers can leave through an agent, and a message nobody approved can say something to a customer we then have to stand behind.”Legal protection and responsible useR1, R2, R3, R7
COO“The calendar the company books customer meetings on can be rearranged, with no way back, and the day runs on it.”Efficient, scalable operationsR5
CTO / IT“We allow a connector that grants more than this use needs, and nothing we run narrows it.”Stable, secure and resilient systemsR1 to R5, and R7
HR“We encourage people to adopt agents without telling them what an agent can do beyond what they ask of it.”A future-ready workforce and higher adoptionthe rows, not one risk
ProductNot on this path. It would be if the agent were part of what the company sells.Customer value and product-market fitnone
CFO“A customer relationship we paid to win can be damaged in an afternoon, and we have not asked whether our cover responds to something an agent did.”Financial discipline and value creationR1, R2, R3
CEO / Leadership“Customers can hear from us in ways we did not decide, and I could not say who accepted that.”Long-term value and competitivenessR1, R2, R5
Board“We cannot say what our agents can do beyond what they were authorised to do, or who accepted the difference, and until when.”Trust, compliance and sustainable growthevery open risk

Now follow one risk up. R2, the stranger’s email, starts with the rep. The rep has no authority to accept it, so it goes at once to the role whose area it touches, the CISO. From there it follows the reporting lines. The chart below is this example company’s; yours will differ.

Board

“We cannot say what our agents can do beyond what they were authorised to do, or who accepted the difference.”

sees it from the day it is established, with its holder and its expiry; holds it only if the CEO does not decide
CEO

“A customer could learn from somebody else that their data left us in an email we never meant to send.”

receives it if the CTO does not decide within a week
CTO / IT

“A connector we allow lets an outside sender steer an agent that holds customer data.”

receives it if the CISO does not decide within a week; in this company the CISO reports to the CTO
CISO

“Untrusted input reaches an agent with private data and a way out, and only an instruction stands in the way.”

placed here: the map gives the CISO “threat management and data protection”
The rep

“An email from a stranger could tell it to send our customer data out.”

where it starts; the rep may accept risks inside their own work, and customer data leaving is not, so it moves on at once
The facts

Rows 1, 3 and 4 of the ABP: reads mail from anybody; reads the CRM; sends to anybody, with only an expectation in the way.

recomputed whenever the grant or the mandate changes

Read from the bottom. Each arrow is a named edge: a fact establishes a risk, a risk is translated into the holder’s words, a holder answers to the role above.

Figure · the blast radius

Connect the assistant, and watch the risks travel up. Then end them.

Drawn from the article’s own data. Play the six weeks of section 07, or change the record yourself: connect and disconnect, add the controls, and see which facts stop holding. A risk lights up when every fact it needs holds and none is bounded; it drifts to the role that holds it, and lights the whole path above that role to the board, because a risk never stops with its holder: everyone above carries it. The colour travels up the path too: while anything below a role is unaccepted, that role’s path is red, whatever else it holds. The circles on a role are how many risks reach it, held or carried: red for the unaccepted, black for the accepted, both when both arrive. A risk ceases when one of its facts changes, citing the ABP version that changed it, and what takes its place is the control’s own residual risk, in green: smaller, inside its holder’s own authority, accepted when it appears. That is what a control does to a risk. It does not make it zero; it turns a red one into a green one that somebody can live with. Put every control on and every path to the board is green, and the risks that remain are the ones the business runs the assistant to take. Colour is the state of an acceptance, never a rating. Click a role, a risk, a connection or the assistant and everything it touches keeps its colour while the rest fades: the facts below it and how far it goes up. The panel under the figure says what it is, and what holds because of it. Click it again, or the background, to see everything. Only the roles this agent’s path touches are drawn: Marketing, Product and HR are in the tables and not here.

The six weeks
Connections
Controls, as boundaries: out of the agent’s reach
Expectations: in the agent’s instructions
Not connectedNothing is connected, so nothing holds.

Every risk that holds right now
0in the grant
0in the mandate
0excess
0unbounded excess
0open risks
0unaccepted: red
0accepted: green
–ABP version
row in the gap, nothing in the way an expectation in the way a boundary in the way in the mandate risk, unaccepted risk, accepted or funded role informed role carrying a risk held below it 3 unaccepted risks reaching the role 3 accepted risks reaching the role a larger circle needs more facts the residual risk of a control a path carrying an unaccepted risk

Try the last switch on its own. Connect the mail and the CRM, then tick the instructions. Every row in the gap changes from nothing in the way to an expectation, the mandate is now precise about the business process, and the risks stay lit: unbounded excess does not move. That is the honest picture of an instruction. It is worth writing down, because it says what the agent was told, and the ABP is where it is written. It is not a control. The mail connector in the example, like the real ones we have recorded, grants the whole mailbox: on our Gmail record, Google’s consent screen offers three lines to tick, each for the whole account, and none for one folder, one customer or one business process (read 16 September 2026). So the mandate can say only follow-ups on my own accounts, and the grant cannot. The gap between those two sentences is the risk, and the boundary switches above are what end it.

06 · Holding it on the way up

Seven rules that keep accountability intact.

These are what join the map to the chart. They are how Risk Mandate works: the acceptance loop, with the ABP underneath it supplying the facts. Most are published on this site already, and are gathered here so that the article stands on its own: the three doors and their intervals, silence, facts that end risks, and the stop. Two are new in this article: authority delegated from the board, and placing a risk by the map.

The board’s risk appetite becomes authority to accept.

The map gives the board “oversight, risk appetite and accountability”. Appetite becomes usable when it is handed down, one role at a time, as a limit on what that role may accept and for how long. In the example: the rep may accept what stays inside their own mailbox, calendar and drafts, for up to a month. The head of Sales may accept what touches the team’s customer mail and records, for up to a month. The CIO and the CISO may accept customer data at risk, inside the company or leaving it, for up to three months. The CEO may accept what reaches customers at scale or cannot be undone across the company. The board keeps whatever its appetite statement reserves to itself.

Authority is written as kinds of consequence and lengths of time, not as scores. Both can be argued with, and both can be checked.

A risk is placed by the map, and moves by the chart.

A new risk is offered first to the nearest holder, usually the person who connected the agent. If it is outside their authority, it goes straight to the role whose area it touches: the map’s middle column. From there it follows reporting lines until it meets an authority that covers it. It has one holder at a time. Everyone else it touches is informed, and informed is not the same as holding.

There is no deny. There are three doors, each with an interval.

A risk exists as soon as the facts do, whether or not anybody has signed for it. So the choice is never yes or no. It is: accept it for a stated interval; fund the work that will end it, and accept it for as long as that work takes; or fix it now. The interval is the decision. Anything under a week is an incident, and should be treated as one. A month is a piece of funded work. Six months, near the line of what the business finds acceptable, is a named decision to wait.

Silence goes up.

A risk nobody has accepted is critical for whoever holds it, because until somebody accepts it that person is accountable for it. If the holder does nothing within the time the company has set (a week, in the example), the risk moves to the person they answer to. When an acceptance expires, the same decision comes back to the same desk with whatever has changed since. If it is not renewed, it goes up.

Translate, never retype.

Each holder receives the risk in their own words, as a new statement linked to the one below it. The CISO’s sentence and the rep’s are different sentences about the same facts. When the lower one ends, the upper one ends too, unless another source still holds it up. A retyped risk is disconnected the moment it is written; a translated one knows when it is over.

Facts end risks. People do not close them.

The ABP is recomputed whenever the grant or the mandate changes. When a row moves to a boundary, or leaves the grant, the facts it established end, and every risk that needed them ceases. The new ABP version is the evidence. Nobody closes a risk by saying it is closed.

Somebody can stop the agent, within the shortest interval accepted.

If a holder accepts a risk for four hours, somebody must be able to switch the agent off within four hours. Every chain records who can stop the agent and how long it takes: the rep can disconnect it, and IT can revoke the connector for the whole company. An interval nobody can honour is a finding. The plug profile is where that gets written down.

07 · Six weeks, one agent

The five risks, from the day it was connected.

Invented dates, and the mechanics are the point. Watch where each risk goes, who decides, and what ends it.

Day 0

Connected. Nine rows, five in the gap, none bounded.

The ABP is written from the connector’s consent screen, the products’ own pages and ten minutes with the rep about what they want it for. Nine risks are established. The person who connected the agent can accept one of them, R0, which stays inside their own work, and they do, by connecting. Every other one reaches past it. R1, R4 and R7 go to the head of Sales, R2 to the CISO, R3 to the CIO, R5 to the COO, whose map row is “operational integration”, RL to Legal and RC to the CFO. Each of them also lights the path above its holder to the board, in red while it is unaccepted: the CTO carries what the CIO and the CISO hold, and the CEO carries all of it. The board’s view shows eight new risks with holders and none accepted, and one accepted by the rep.

Day 2

Sales accepts one, funds one, and asks for a fix.

The head of Sales accepts R7 for a month: the team’s customer mail is inside Sales’ own authority, and reading it is a risk the team can live with while it decides whether the delegation should stay. Then Sales funds R1: accepted for two weeks while IT adds an approval step to sending that the agent cannot give itself. For R4 they choose fix: they ask the CRM administrator to limit reps to their own accounts.

Day 3

The CISO, the CIO, Legal and the CFO accept, with actions.

The CISO accepts R2 for two weeks and records why that is enough: R2 needs rows 1, 3 and 4 together, so R1’s fix ends it too. The CIO funds R3: accepted for a month while export is removed from the connector’s scope, a change IT has to schedule. Legal funds RL for three months: processing terms with the model provider, and the notice to customers rewritten to say where their mail goes. The CFO funds RC for three months: the broker is asked, in writing, what the cover says about an agent acting as staff. Neither of those is a technical control, and both end a risk, because each changes a fact the risk was established on.

Day 4

R4 ceases, on evidence. Its residual takes its place.

The CRM now limits the rep to their own accounts. ABP version 2 is recomputed: row 5’s barrier is a boundary, held by the CRM administrator, out of the agent’s reach. The fact behind R4 no longer holds, and R4 ceases, citing version 2. Sales’ and the CIO’s statements lose that source. What is left is G2: wrong entries on a rep’s own accounts still happen, at machine speed. It is inside Sales’ authority, and Sales accepts it the same day.

Day 7

Silence: R5 moves up.

The COO has not acted on R5 in a week. It moves to the CEO, whom the COO answers to, and it is now critical there.

Day 10

The CEO fixes R5, and a smaller risk takes its place.

The CEO asks IT to narrow the agent’s calendar access to the rep’s own calendar. ABP version 3: R5 ceases. The agent can still edit the rep’s own events, which is more than suggesting times, so a smaller risk is established: “it can change my own meetings”. That one is inside the rep’s authority, and the rep accepts it for a month.

Day 15

The approval step goes live. R1 and R2 cease together; two residuals appear.

Sending now needs the rep’s approval, somewhere the agent cannot reach. ABP version 4: row 3’s barrier is a boundary. R1 ceases. R2 needed all three rows, loses the sending one and ceases too. The lethal trifecta is broken on evidence, not on an instruction. Two residuals are established and accepted the same day: G1, a message the rep approves in a hurry still goes out as them, which is the rep’s; and G4, that an approval is a person clicking and people get worn down, which is the CISO’s.

Day 33

Three acceptances run out, and are renewed.

The scope change was scheduled and has not shipped. R3 returns to the CIO, who renews for one more month with a date for the change. R0 came back to the rep on day 30 and R7 to Sales on day 32, and both were renewed. Each renewal is a new acceptance, and the old ones stay in the record.

Day 42

What the board sees.

Nine open risks, each with a name and a date, and none unaccepted, so every path to the board is green. Four are still funded or accepted from the gap: R3, held by the CIO until day 63 with the work scheduled; R7, held by Sales until day 62; RL, Legal’s, and RC, the CFO’s, both until day 93. Five are inside their holders’ own authority: R0 and R6, the rep’s; and the residuals of the two controls that landed, G2 with Sales, G1 with the rep and G4 with the CISO. Four risks ceased, each citing the ABP version that ended it. For the agent, unbounded excess went from five to three. That is not a score. It is a count anybody can recompute from the ABP versions.

Figure · six weeks on one strip

Who held each risk, in which state, and what ended it.

The same six weeks as a strip: one line per risk, day 0 to day 42. A hatched bar is a funded acceptance; the small arrow on R5 is the week of silence that moved it from the COO to the CEO; each ending names the ABP version whose facts ended the risk. The last three lines start where a control lands: they are its residual risks, accepted by their holders from that day. R0 is the one inside the rep’s own authority from the day the agent was connected, which is the level the business already lives with. Everything that runs past the edge was renewed, and carries a date.

08 · The map, with four more columns

The same thirteen rows, with what a one-page map has no room for.

For the example company and this one agent. The first column is the map’s; the other four are what the acceptance loop adds. Another company would fill them differently, and another agent would change the second column entirely.

RoleHolds, in the exampleMay acceptAnswers toCan stop the agent
CEO / LeadershipR5, after the COO’s silence, until it fixed itwhat reaches customers at scale, or cannot be undone across the companythe boardby telling IT
Boardnothing directly; sees every risk and its expirysets the appetite; keeps what it reservesthe ownersthrough the CEO
CFORC, funded for three months while the insurer answersfinancial exposure within budget, up to three monthsthe CEOno
COOR5, for a week, then let it go uphow the company’s shared operations run, up to a monththe CEOno
CTO / ITnothing; did the work behind two of the endings, and has the third scheduledchanges to technology, up to three monthsthe CEOyes: revokes the connector for the company
CIO / DataR3, renewed oncecustomer data at risk, inside the company or leaving it, up to three monthsthe CTOthrough IT
CISOR2, until it ceased; G4, the residual of the approval stepthreats to data and systems, up to three monthsthe CTOyes, through IT, and may order it in an incident
LegalRL, funded for three months while terms and the notice are done; informed of R1, R2, R3 and R7legal exposure; would hold a risk that a message could commit the companythe CEOno
HRnothinghow people are asked to adopt agentsthe COOno
Marketingnothing; informed of R1what goes out under the company’s namethe CEOno
SalesR1 and R4, until they ceased; R7, renewed once; G2, the residual of the CRM limitthe team’s customer mail and records, up to a monththe CEOyes: can tell the rep to disconnect it
Productnot on this pathwhat the product does to a customerthe CEOno
All EmployeesR0 from day 0, R6 from day 10 and G1 from day 15, all inside their own authoritywhat stays inside their own mailbox, calendar and drafts, up to a monththeir manageryes: disconnects it

Read down the last column. Of thirteen roles, four can stop this agent, and only two can do it without asking anybody: the rep and IT. That is normal. It becomes a finding only when an acceptance is shorter than the time the stop takes, or when nobody on the risk’s path can stop it at all.

09 · To build it

The model, in enough detail to implement.

Everything above fits in a semantic graph: nodes, and edges that are verbs. Every verb has a named inverse, so each link reads correctly from either end. There is no generic “relates to”, because an edge without a verb constrains nothing. Nothing is deleted: a new version supersedes the old one, and both stay.

NodeWhat it holdsWho writes it
Rolethe company’s name for it; what it owns (the map’s middle column), used to place risksthe company
Personwho holds which roles. One person may hold several: in a startup the CEO is often the CFO toothe company
Authorityfor one role: the kinds of consequence it may accept, and the longest intervaldelegated down from the board’s appetite
Agentone agent in one deployment, and who connected itwhoever connects it
ABP versionthe grant, the mandate, the gap and the barrier for each row, with sources and dates; the four counts; never editedthe grant is read from the deployment and the vendor’s pages; the mandate comes from the person who connected it; the gap is computed
Facta statement one or more rows make true, with its sourcederived from the ABP; never typed
Riska statement in one role’s words; the facts it needs; the facts that would end it; its state (open, accepted, ceased)the holder, in their words, linked to the risk below
Acceptancewho, on which date, which door (accept, fund, fix), for how long, with what action; its expirythe person who signs it, never somebody on their behalf
EdgeInverseFrom → to, and what it means
recordsrecorded_inABP version → fact: a row makes this true
establishesestablished_byfact → risk: needed for the risk to hold
endsended_byfact → risk: if this holds, the risk ceases
translates_intotranslated_fromrisk → the same exposure in a higher role’s words
held_byholdsrisk → role: exactly one at a time
informsinformed_byrisk → role: its area is touched, and it does not hold the risk
answers_tooverseesrole → role, ending at the board: the escalation path
delegated_fromdelegatesauthority → the authority above it, ending at the board’s appetite
empowersempowered_byauthority → role
acceptsaccepted_byacceptance → risk, for its interval
signed_bysignedacceptance → person
can_stopstoppable_byrole → agent, with how long the stop takes
supersedessuperseded_byABP version → ABP version; acceptance → acceptance
Figure · the ontology

Eight node types, thirteen verbs, every verb with an inverse.

The tables above, drawn. The bottom row is the evidence: an agent, the versions of its behaviour policy, and the facts each version records. The middle is the risk and its acceptance. The top is the people: roles, the authority delegated to each, and the person who signs. A dashed edge is one of the two that can end or inform without holding. Hover a verb to read it from both ends.

Hover or focus a verb.

Placement

When a risk is established, offer it to the role of the person who connected the agent. If its consequence is outside that role’s authority, place it with the role whose owns matches the consequence. If that role’s authority does not cover it either, walk answers_to until one does, or until the board. Add informs to every other role whose area it touches.

The clock

An open risk with no acceptance starts the silence timer the company set. When the timer runs out, move the risk one step up answers_to and restart the timer. An acceptance sets an expiry. At expiry, return the risk to the same holder with what has changed since. If it is not renewed within the silence timer, move it up. An acceptance longer than the holder’s authority allows is refused, not trimmed.

Cease

On every new ABP version, re-derive the facts. A risk ceases when a fact it needs no longer holds, or when a fact that ends it now holds. Record the ABP version that ended it. Then walk translates_into: a risk above ceases when none of the risks it was translated from still hold.

The stop check

For each acceptance, compare its interval with the fastest can_stop on the risk’s path. If the acceptance is shorter than the stop, raise a finding. The same finding stands if nobody on the path can stop the agent at all.

The board’s view

A list, never a score: every open risk, its holder, the door chosen, the expiry and the action, with unaccepted risks first. Then the ceased ones and the ABP versions that ended them. For each agent, the four counts: grant, mandate, excess, unbounded excess. Whatever the board has reserved to itself comes first.

Nothing in this model scores anything. Kinds of consequence and lengths of time do the work a score usually does, and unlike a score, a person can argue with them. The ABP never rates the agent; it says what the agent can do, on a date, with sources.

10 · What exists, and what does not

What runs today, and what this article proposes.

Exists

The record, and the loop on paper.

  • The ABP format, and sixteen example ABPs, free, with the grant, the mandate, the gap and the barriers computed for each.
  • The 23 capability primitives and the four barrier kinds used in section 04.
  • A risk engine behind our business cases. It computes which risks hold from facts, and carries them up ten roles to the board.
  • What acceptable means, the intervals, and why an unaccepted risk is critical.
  • The question of who can stop an agent, and how fast.
Does not exist yet

The engine, and seven of the thirteen roles.

  • Software that records acceptances, runs the clocks and moves silence upwards.
  • Authority as data. Delegating the board’s appetite into kinds of consequence and lengths of time is proposed here for the first time.
  • Seven of the map’s roles. Our model has ten: the CEO, the board, the CFO, the CTO, the CISO and Product are in it, alongside roles the map does not have, such as a data protection officer. The COO, CIO / Data, Legal, HR, Marketing, Sales and all employees are not.
  • Translation. Each role’s wording is written by hand today.
  • Real grants at scale. The ABPs are templates, read from vendors’ own pages, with some rows measured on accounts we are entitled to use.

What we would ask of anybody who draws a map like the one in section 01, including its author: keep the middle column, because it is what places a risk. Then add one arrow pointing up. And if you have drawn your company’s version of the map, we would like to see which of the four extra columns you could fill in today.

One agent, one deployment

Start at the bottom of the chain: what can your agent do?

Every risk in this article came from eight rows. The free prompts have your agent list its own reach in about twenty minutes, with nothing collected. The ABP puts that next to what you authorised, and the gap is where the acceptance loop begins.

Try the promptsTell us how your company draws it