The Assistant Was Only Supposed to Read
An AI assistant's authority comes from the tools it is handed, not from the job it was given, so an assistant installed only to read can act unless the owner sets its toolset to its job.
If your company has added AI assistants to summarize or draft email, meeting notes or support replies, can you list what each one is able to do besides summarize and draft?
I could not have listed it for mine. At 11:54 on a Sunday night, the background job that writes summaries of my AI coding sessions (a session is one working conversation with my coding agent) was handed the text of one that was still running and asked to summarize it. The text ended just as the session said it was starting to carry out its plan. The reply picked up from there. For the next five minutes, a helper agent it started ran commands in my live project folder. The helper wrote six files, three of them into the project, and tried three times to queue files for the project's permanent record.
Nothing shipped. The running session's automated reviewer reported files from a step the session had never started, and the project folder was clean about a minute and a half later.
What matters is that a tool I installed to remember things could run commands, write files and start other agents, and I had never decided that. Nobody had. In a company, the same gap is an email assistant that can also send, or a meeting-notes assistant that can also edit customer records. If one of them acts on something it read, the cost is an email sent, or a customer record changed, that nobody approved.
What a reading assistant can do
The summarizer belongs to a memory plugin for my coding agent. To summarize a session, the plugin starts the summarizer as a fresh assistant, pastes the conversation into its request, and asks for a summary. The plugin never said which tools the summarizer could use, so it got the coding agent's full default set. A test of the plugin without our fix, stopped before the summarizer could answer, showed it starting with 18 tools. They let it run commands on the machine through a shell, write and edit files, start other agents, and fetch from the web.
Asked for a summary, the summarizer went to work on the plan first. When its first two attempts to run the plan itself failed, it handed the plan to a helper agent with a shell, and the helper went to work. The summary it was asked for arrived five and a half minutes later.
No attacker was involved. The text it had been asked to read ended with my own session announcing that it was starting my plan, and the helper found the full plan in the project folder. That is the part an owner should notice: whatever a reading assistant reads can become something it does, if it holds the tools to do it.
Who decided what it could do
I installed the plugin in April to give my agents a memory. I chose it for what it remembers. I never chose what it could do, because nothing asked me, and the plugin had no setting for it. Its authority came from a default.
The maintainers had seen this. Two public reports described the same behaviour, one from a user who reported that the background agent changed their repository and committed to it. A fixed release, which gives the summarizer no tools at all, shipped on September 8. The copy I installed in April had not received it. That is a separate failure, and it is why a vendor's fix is not a control you own: for nineteen days the fix existed and my machine did not have it.
What stopped it, and what did not
My coding agent asks a person before running many kinds of commands. A background job has no person to ask, so those requests were refused. Of the helper's 96 commands, 39 were refused that way, including all three attempts to queue files for the permanent record and both attempts to run a script it had written. Two more were refused for reaching outside my home folder.
Most of the rest ran, and they were enough. The checks refused some ways of writing a file and allowed others, and six files got through.
Those checks are built around a person being present to answer them. With nobody there, anything they would have asked about was refused, and anything they would not have asked about went through. They slowed the helper down, and their refusals were real. They were not a boundary drawn for this job.
It was caught only because of where it happened: the running session checks its own steps. A summarizer working in a folder nobody was watching would have met no reviewer at all.
So we went looking in the plugin's own archive of transcripts. Between April and October 3, it recorded 7,559 runs that were each asked to summarize a whole session. Before our fix on September 28, 718 of them used tools and 148 started helper agents. In July, one replaced three files in a live project folder, files already in the project's permanent record, with versions from work that had not yet been accepted. That work happened to be accepted 38 minutes later, so the folder ended up matching it by luck. In June, another wrote the word "test" into a planning file. Most of the rest, we have counted but not read.
One reading input. Many ways to act.
Two properties of an assistant you can own
A toolset sized to its job. What an assistant can do should be set by the person who owns the workflow, written down, and limited to what the job needs. A reader, such as an assistant that summarizes contracts, gets no way to write, run or send. Most other jobs need only a little more: an assistant that drafts support replies needs to read the ticket and write a draft. It does not need to send the reply or close the ticket. Our plugin offered no setting for this, so our fix is two lines patched into its code: the summarizer now gets no tools and one reply. A test confirmed that it starts with no tools and still writes its summary, and none of its runs since has used a tool.
A record someone reads. Every action an assistant takes should land in a log that a named person reviews on a schedule, so "what did each assistant do last week?" has an answer that does not depend on luck. Our transcripts recorded all 718 of those runs; we went looking only after the one that was caught. A count like that belongs in a weekly report that a named person reviews. In our setup, it is not in one yet.
One reader, one boundary, and a record someone reads.
Three questions for your own assistants
What can it do, as opposed to what is it for? For each AI assistant in a workflow, list what it is permitted to do: read, write, send, delete, start other jobs. If that list came from a default, nobody chose it.
What can it read, and what can it change? Emails, tickets, shared documents and web pages can carry someone else's instructions. Meta's Agents Rule of Two addresses this: within one session, an assistant should meet no more than two of three conditions (reading content it cannot trust, reaching sensitive systems or private data, and changing things or communicating outward) unless a person, or another reliable check, approves what it does. Ours shows why the rule is not enough on its own. Cutting it off from outside content would have satisfied the rule, and it would still have acted, because it followed my own plan. An assistant whose job is to read should not be able to change or send anything, whatever it reads.
Who reviews what it did? Ask who reviewed what each assistant did last week. If nobody did, or listing what each one did means searching logs by hand, as it did for us, you are relying on someone noticing.
What it cost
For this run, little. No customer, client or revenue was involved. None of its commands used my saved logins to other systems, fetched anything from the web, or got anything into the project's permanent record. Its six files were removed before any of them was even queued for the permanent record. The exposure was the reach: a shell running under my account, on the workstation where my code and my saved logins live, started by a job whose only task was to write a paragraph.
If you own a workflow with AI in it
You can probably say what each AI assistant in your operation is for. Two other answers matter more: what it is able to do, which decides whether it is a reader or an actor, and how often a named person reviews what it did, which decides whether anyone would know.
That is the kind of gap the Readiness Scan my agency runs looks for: one workflow, mapped for where it can fail, with a plan for what stays with a person and who owns each handoff, including the ones made to an AI assistant. Work with OIA on one workflow.