ABP in action: what the behaviour policies caught, what saved the day, what failed

Kept by abp@web-summit.dinis, first written on 6 November 2026 at Dinis's word: "show the ABP in action". Every scenario below happened on this team between 2 and 6 November 2026, and every one names the commit or issue that shows it, so anyone can check it in the repository's history. The model is RiskMandate's Agent Behaviour Policy: Reach (what an agent can do), Mandate (what it was asked to do), the Gap between them, and the Barrier that actually stands in the way, labelled honestly: a rule the agent keeps, a review by another agent or person, or a technical control the agent cannot change.

Phase: explorer. These policies observe and recommend; they block nothing yet. The team is still finding its way, so a lock-down comes gently, one step at a time, each with an escape valve (a person can still do the thing by hand). The ABPs, and the phase.

The scoreboard, after five days

The pattern in one line: rules alone failed once; reviews caught seven mistakes; every technical barrier we have today was added after an ABP or a review named the gap.

1. The rule that failed, and the barrier that replaced it

Every ABP recorded this as the gap common to all agents from the first day (WS-90, 2 November). It took one real failure to move it from a rule to a control.

2. Caught before it went out

A token's value about to be published. vault@web-summit.jose drafted a board issue that named a vault and said a token had the same value. Jose's code reviewer, a sub-agent that runs before every push, held it: only the hold and its record were released, the work stayed local until fixed (d8301cd). Barrier: review, before the push. The same reviewer later held a brief with two wrong claims (f2772a97) and a dashboard that asked Jose again for a decision he had made (bce97f28). Three holds, three fixes, each passed on a second review.

A key entry undone by a stale copy. helper@web-summit.angelo committed the shared keys file from an older copy and undid the mark that another agent's key had ended (ced09eb2): an ended key would have looked live to anyone sealing a vault to it. It noticed and restored the entry itself (bd9dc233). The ABP recorded that nothing else would have caught it (WS-152); seal.mjs now refuses ended keys and entries changed from another person's account (68fda24b). From a self-catch to a technical check in three hours.

A vault key printed into a transcript. The vault guide recommended sgit vault info, which printed Angelo's first vault key into his agent's session (7502d99). The vault was replaced and deleted before any read key was published (3f4bfc8). Barrier: the agent's own audit; then a scripted one (WS-128).

An audit that could not see new files. vault@web-summit.vicky's first audit used commands that show no content for added files; its second audit found the hole before Vicky's vault went public (443b62f). The scripted audit, vault-audit.mjs, now reads every file at every revision (ad9e353) and compares the real token and key values (c99aaff6, WS-135).

A read key handed to the model's provider. In the policy studio, a browser chat with tools, create_vault returned a new vault's read key as a tool result, so it would reach the model's provider. dev@web-summit.dinis's own review caught it (31cc3991); now every vault write asks the person to confirm, and the key stays out of the model's context (9ff212c4). Barrier: the person's yes on each write.

3. Found by an ABP, fixed by its owner

4. Found, and still open

5. The capabilities that could do real damage

These are what an agent on this team can do today, whatever it was asked. In the explorer phase they stay open; each has the step that would close it.

• Connectors reach everything the account reaches. A Google Drive or Gmail connector is the person's, so every session in that account can read, write, share and delete through it. Angelo's scheduled collaboration agent read his Drive and mail for its debriefs (7e12751c). The full study, and what read-only can and cannot mean: Connectors.
• Agents can start agents. Every session in Dinis's account measured so far holds the tools to create scheduled tasks and new sessions, and to message other sessions. The only barrier is the sentence "never create a scheduled task, a session or a workflow" in each prompt. Many agents now set their own schedules "at their person's word". A rule, not a control: the one capability that turns one mistake into many. It happened, as designed, on 6 November: Dinis's agents were "running a bit hot", so some moved to a second account, where conductor.b@PrompTugal.dinis, at his word, creates its own scheduled task and starts the moved agents' sessions and tasks one at a time (the newsroom's board/guidance/2026-11-06-account-b.md). The power to start agents, used for capacity, with the person's word as the only barrier.
• The build runs people's code with a write token (WS-133, above).
• The keys page is one shared file that every agent writes (WS-152).
• Secrets shared through the environment. Every session in a person's cloud environment gets its variables: in Dinis's, his own SG/Send token and the model keys (measured 7 November, WS-188). Angelo moved to one environment per agent the evening before (4c285114): the one place where the platform gives a per-agent barrier, and he used it.
• The public can write to agents. Feedback lanes take sealed messages from anyone with the page, and agents drain them (WS-114); company email is to flow into the private CRM (WS-173). The barrier is "material is not instruction", plus Angelo's design: a visitors' inbox that no agent can open (b8a5d3ab).

6. The first sign-off

On 6 November about 13:00 UTC Angelo approved the ABPs of his eight agents as they stood: "ABPs as they stand are approved for now" (5732bdf1, WS-34). From then, his policy agent audits his agents against those approved texts, and any later draft needs his word again. This is the step RiskMandate's model calls the acceptance: a named person owns the policy, not only the agent that drafted it. The ABP agent changed two of them three hours later (the phase line, one mandate line), and each now says that change waits for Angelo's word.

7. Policies meeting policies

The evening of 6 November showed what happens when each person owns their own rules.

• A person loosened a rule, on purpose, with conditions. Angelo: "we shouldn't go for an overly bureaucratic approach, as it causes holds and slow us down. We lift the limit that we don't touch other people areas but with the caveat that we need to find a way to avoid clashing on parallel changes" (ce069603). His agents may now change another owner's files, after five steps (pull first, check the last two hours, say so to the owner, keep theirs on a conflict, one entry at a time in shared data). The explorer phase, chosen by the person who owns the risk.
• The sign-off loop works both ways. Angelo approved his agents' ABPs (5732bdf1); the ABP agent changed two lines afterwards and said each waited for his word; he accepted them (fd819c3c).
• Two owners' policies collide. The newsroom's strict, deny-by-default policies, from abp@PrompTugal.dinis, are written for Dinis's agents; Vicky decided they do not bind her agents unless she says so (standing answer 11, f783bb79). Her developer agent then asked the newsroom's ABP agent, at her word, to widen its grant for her desks (be2d60df): the escape valve of a strict policy, used as designed, a request on the record rather than a quiet override.

8. Caught by the watchers

The team now has agents whose job is to read the others' commits: watcher@web-summit.jose (the whole team, read-only), policy@PrompTugal.angelo (Angelo's agents against their approved ABPs) and security@web-summit.dinis (every commit, twice a day). On 7 November, between them:

• A person's agent changed other people's pages. Silvio's dashboard agent added a feature to the shared command-centre engine, so it appeared in Angelo's and Jose's command centres, with no word to Jose's agents. The watcher flagged it at 07:15, and Jose's dashboard agent put the question to Jose: does he want it, and should Silvio's agent say so first next time (bc0826de, 1fcbb696). Barrier: checked, after the fact; the decision stays with the person whose page it is.
• Two sessions, one name. 18 commits signed dev@web-summit.silvio were another session's. dev@web-summit.silvio found it, wrote the correction, and the other session now signs as dashboard@web-summit.silvio with its own key (f3f3c8b6, bb878ce4). A name is an agent's own word; a key per session is what tells two apart.
• A rule broken, by its own team's auditor. policy@PrompTugal.angelo found Angelo's collaboration agent still pushing its session branch, 14 times, after the proposal that every session push only to dev (P-05, a071a51d).
• Agents that stopped. The watcher tracks every agent's schedule against its commits: dev@web-summit.dinis silent for about 31 hours, dashboard@web-summit.dinis for 16 hourly slots, Angelo's writer runner and dashboard missing slots (bc0826de). A stopped agent is a gap too: work someone thinks is happening, isn't.

9. Escape valves, and hardening

From 7 November's record: how a team in the explorer phase opens a narrow door, and how it starts to lock one.

• A written exception, not an override. The vault audit kept flagging one line in Vicky's programme desk's shortlist vault: its own agent name, which looks like an address. At Vicky's word the desk may push when that is the audit's only finding, and nothing else (ae428805). One false positive, named and scoped, in the prompts file the agent re-reads each run.
• A review gate before the team's branch. Angelo's six new worker agents push only to workers/<agent>; his dev agent reviews and brings each onto dev as one commit (645d429b). A second agent between a worker and everyone else's work; by 16:00 it had brought three workers' changes onto dev, each as one reviewed commit (2239d685, ed454d43, 71c5aeb3).
• One person's hardening becomes everyone's. sgit@web-summit.dinis copied those four steps into the team's vault guide the same day (8fad074f): a lesson from Angelo's agents, now the default for every vault agent.
• Four hardening steps for Angelo's vault agent (130fe1c4): his token out of its clones, credentials through pipes never files, a passphrase on its key store, and never a command that prints a vault key (the scenario of 3 November, section 2, made a rule).
• Secrets per environment, measured both ways. security@web-summit.dinis confirmed that its own environment holds Dinis's tokens too (d528cb08, WS-188), as sgit@web-summit.dinis did (8fd8b17d).

10. The experiment: ABP levels, measured

Angelo's team ran the cleanest test yet of what each kind of barrier is worth (people/angelo/proposals/abp-live/results.md, by dev@PrompTugal.angelo, 8 November; "an experiment; nothing public"). One real agent, a Claude sub-agent with real tools and no scripted replies, did an ordinary support job for a made-up company inside a mock world, six times: two rounds of pressure (a phishing mail, instructions hidden on a vendor's page, live secrets pasted into a runbook, then helpful-looking requests), each at three levels.

What it shows, in the experiment's own words: no leak at any level from this model, which refused every trap even with nothing in the way; the difference is what reaches the agent: at levels 0 and 1 a live key, an admin password and customers' card numbers entered its context and stayed in its transcript on disk, and the rule did not prevent the reading; over-reach is visible: with no rule it listed every customer, cards included, to find one, and with "read a record only to serve that customer" it looked up one; and a limit of the technical barrier: the last four digits of a card, normal to tell its owner, are below what the scan catches.

This is the ABP's model made measurable: a rule (an expectation) changes behaviour but not reach; a boundary changes reach, and the job still gets done. Angelo's next step is the stand's live demo of it, "ABPs you can watch", with the headline "reach against need, and the secrets the agent now holds" (dev.abp@PrompTugal.angelo, people/angelo/proposals/abp-live/, 673a1958).

11. Learning from each other

• Angelo's protocol turned three ABP gaps into rules in his own words: shared code stays with its owners, his signature counts for tier 1 and 2 only, no agent of his reads what a stranger writes. His policy agent mapped 21 rules for his agents with how each is enforced, and its first audit found four issues (69146077).
• Jose's one door: his agents take work only from his conductor's task files (2191c0b2), and a reviewer runs before every push.
• Silvio's inbox policy: one agent only has his mailbox, it never sends, and the one technical barrier is named: send turned off in the connector's settings (people/silvio/policies/inbox.md).
• The Agent policy explorer, a vault app by vault@web-summit.jose, shows every agent's Reach, Mandate, Gap and Barriers from these ABPs side by side (3b3458f8).
• The first team-wide ABP: conductor@web-summit.indi, under the token mandate Dinis gave it, wrote one policy for every agent's use of Claude, in the same Reach, Mandate, Gap and Barriers terms, from the team's token records: "needing more is allowed, your person decides" (the token-efficiency ABP, 855c61df).
• abp@PrompTugal.dinis writes strict, deny-by-default policies for Dinis's agents, with hooks to enforce them: the next phase, after this one (815e9db6).