Each of these takes one thing a deployment actually does, shows the screen or the page it was read from, and follows it to where the accountability lands. Every claim carries a source and a date. Nothing is tested on anybody else's system, nothing is scored, and where a vendor's own pages disagree the article says so rather than settling it.
Some of what these articles say is also told as a story, with the same cast each time: the stories, storyboards first, pictures last.
OpenAI released dots on 29 September: always-on agents in ChatGPT with a cloud computer, a browser, and every app you ever connected, working while you are away. An introduction for readers who have not met one, from the vendor's own pages; then the Agent Behaviour Policy for one: twelve capability rows in the site's vocabulary, each with the vendor's sentence, a barrier and who holds it; the finding that the strongest barriers on the rows that matter are held by a reviewer model the vendor itself calls a judgement rather than a guarantee, and a request to the model site for a word for that; six questions the pages do not settle; a starting mandate with its delta derived; and five steps to write one for your own dot. Nothing tested, nothing scored.
Evidence: eight of the vendor's pages, quoted and dated 30 September 2026; the GPT-6 Astra system card's dots appendix · markdownThe guide to the figure on the role-ownership article, which draws one agent's risks live. Who it is for, in seven user stories; the six weeks as a story; how to read the six bands, two colours and a click; each connection on its own and then combined, where a risk appears that none of them has alone; eight controls one at a time and then all of them, each trading a red risk for a green one; what a business gets from the picture and the five questions to ask in a room; and how it works, down to the walk that goes one way per hop. Thirty-four captures of the figure, each in the state its caption names.
Evidence: the figure's own captures, 25 September 2026; an invented company and agent; two vendor facts, dated · markdownA reply to an infographic on LinkedIn that maps thirteen roles to what each owns in AI and what that protects. Every company will redraw a map like it, and so it should. The map runs sideways, and accountability runs upwards: its middle column says where a risk lands, and the organisation chart says where it goes when nobody decides. One invented agent worked from the nine rows of its behaviour policy to the board: the same exposure in thirteen voices, seven rules, six weeks, and the model in enough detail to build. Three figures are drawn by the page from its own data, and one can be played: connect the assistant and watch the risks travel up, add a boundary and watch them end.
Evidence: the infographic's rows, quoted and credited; an invented company and agent; one vendor fact, dated · markdownGoogle Calendar keeps a deleted event in a trash for 30 days and documents no way for a user to restore an edited one. An agent allowed to edit can leave fifty meetings that look right and are wrong, with nothing to restore them from, which makes edit the dangerous permission and delete the recoverable one. What Google keeps after each action, in its own words, for personal and Workspace accounts; three places where Google's pages disagree, published unresolved; and the draft Calendar rows of a behaviour policy, with recovery beside each.
Evidence: Google's help, Workspace and developer pages, read 24 September 2026; nothing tested on any account · markdownMost generative AI and agent pilots never reach production, and some that do are switched off again. The hypothesis: the business compares what the agent was meant to do with what it can do, at machine speed and on somebody's authority, and declines to sign for the difference. Fourteen surveys and forecasts with the causes each one names, seven cases where what a system said or did became the company's, five variables the lethal trifecta leaves out, and a plain account of what the data does not show. Then the fix: limits written in business units at design time, each beside what enforces it.
Evidence: published surveys, forecasts, rulings and statements, each read at source, 24 September 2026 · markdownA session that only reads still holds everything you ever allowed. Open a new chat, ask the agent to read your inbox, and nothing in that sentence authorises sending mail or changing labels — but a conversation is not an authorisation boundary. The session runs on the credential you granted months ago and the approvals you clicked in other conversations for other reasons. How the union forms at three layers, in each vendor's own documented words; the six questions a deployer would ask and the four the help page leaves silent; why “don't press Always allow” does not survive the mechanics; and the one lever a deployer still has when the credential has no per-session setting to offer.
Shape: Claude with the Gmail connector · Google's and Anthropic's own pages, read 20 September 2026 · markdownAn introduction to the Agent Behaviour Policy: the three answers people give today and why none of them survives contact; the four objects and the verb attached to each — the mandate elicited, the grant measured, the delta derived, the barrier recorded; the twenty-three primitives that let two policies be read side by side; the four kinds of barrier and the one test that separates a control from a rule in prose. Then one real deployment worked all the way through, with every number traceable to the record it came from.
Worked example: Claude with the Gmail connector · six capabilities, one wanted, four with nothing in the way · markdownA connector asks Claude wants to use Add labels to message from Gmail and offers Deny, Always allow and Allow once. It does not say which label, on which message, in which thread, or whether the agent was asked by the person or by an email it had just read. One of the three buttons removes the question permanently, and it is pressed by the account the prompt exists to protect. What the screen carries, what Google had already authorised before it appeared, and why the person clicking it ends up accountable for a decision they were not given enough to make.
Shape: Claude with the Gmail connector · three prompts captured on the deployer's own account, 16 and 19 September 2026 · markdownListed so the queue is visible rather than implied. None of these exists yet; each one already has its record behind it in a behaviour policy, which is the only reason it is on the list.
Attachment content is out of reach in this deployment because a client ships no tool for it — while the credential authorises the bytes. A block a vendor holds as a product decision moves in a release, with no consent screen and no notice. What that means for anyone relying on it.
Not writtenThree lines, each with its own tick box, all pre-ticked under Select all. What those three actually authorise, in Google's own words, against what the product then offers — and the distance between the two.
Not writtenThe mail in an inbox was sent to one person under one expectation. An agent that may read it may also forward it, and the authorisation the sender gave does not stretch that far. Whose rights are in play, and what the record can honestly say about it.
Not writtenA message sent through the connector carries no header naming the client. To the recipient it is the account holder's. What that does to attribution, measured on the sending side.
Not writtenPassword resets, one-time codes, invitations and recovery mail arrive by email, and reading messages reads those. A capability with no separate permission behind it, and no tool on either vendor's page that separates them.
Not writtenFor one agent in one deployment: everything it can do, what it was authorised to do, the gap between the two, and who holds each thing standing in the way. Read them with their keys, or have one corrected for your deployment.