The permissions review that did not happen

What it says#

The situation below is invented and generic. No organisation, product, vendor or person is described, and none of it is a case report. It is written because the shape recurs.

A team wires an assistant into a work queue. It reads tickets, looks things up, drafts replies and closes the simple ones. The engineer setting it up connected it with the credential already open on the desk: their own. The assistant now reaches the mailbox, the ticket system, the document store, the search index and two admin consoles.

Then the change ships as a configuration change, because that is what the pull request showed: a new integration, a settings page, a switch turned on. Access management saw no new account, so it provisioned no rights. Change control saw a low-risk edit. Risk saw nothing, because nothing was raised. Nobody accepted anything, because nobody was asked.

That failure is administrative rather than technical. An agent is a new subject inside an old control domain. Filed as configuration, it never meets the controls a new subject would trigger.

What we take from it#

The review below is what should have run before the switch, and none of it is new work.

Whose identity, and what it reaches. The first question is not what the agent can do, but who it is. Access rules are derived from business needs and information security requirements, and rights under them are granted, reviewed, changed and withdrawn as that policy directs ¹. An identity produced by an integration wizard has met none of that.

The other half is reach. Privileged rights are kept restricted and under active management. What an identity may open follows the access-control policy already written ². So the review asks for a list rather than an assurance: every system the credential reaches, and the rights it holds in each.

The tool list against the task. OWASP names the root causes of excessive agency: too much function, too much permission, too much independence ³. That is three columns per tool. Is it needed for this task? Does its credential hold more than the task needs? May it act without a person? A tool failing a column is removed, scoped down or gated, and the decision written beside it.

What content can steer it. An agent that reads is an agent that can be instructed by what it reads. Prompt injection is the case where input changes a model's behaviour in ways its developer did not intend ⁴. That input can arrive through retrieved content, a tool's output or stored memory, not only from somebody typing. The review lists the sources the agent will read, and marks which a stranger can write into.

The other half is what an attacker gains by asking. Hidden context exposure covers recovering the instructions and tool descriptions an application assembles behind an assistant ⁵. One rule follows: nothing that must stay secret goes there, and no permission decision rests on it staying hidden.

The reversibility line. Which actions may run without a person is a governance choice, not an engineering default. GRCIDE's working view, set out in Governing AI and agents, is that the line worth drawing is reversibility: what can be undone may auto-approve, what cannot goes to a named human. The review makes that a classified list of action classes, not a slider labelled autonomy.

Where a system is high-risk under the AI Act, a statutory floor sits beneath that choice. The person holding oversight must, where appropriate and proportionate, be able to set the output aside, reverse it, or bring the system to a halt. The deployer assigns that role to someone with the competence, training and authority to use it ⁶. A stop nobody has rehearsed is not oversight.

Who accepts what is left. Every honest review leaves a remainder: a tool broader than ideal, or a source nobody can fully vouch for. That is residual risk, and the method for closing it is the ordinary one. An approver holding authority at that level, the compensating controls that hold meanwhile, and an expiry that forces a re-decision. The steps are in Risk acceptance and residual risk.

The record sits where an assessor will look. The agent belongs on the AI system register as a system in its own right, with its owner, its oversight owner and the triage row that let it in. An agent missing from the register is one nobody reviews again.

Where we would push back#

The obvious objection is that this is an access review with the word agent in front of it. That is correct, and it is the point. The method already exists and runs every week for human joiners. The change simply did not look like a joiner.

A second objection is fairer. Reversibility is a clean line in prose and a blunt one in use. Sending a message is technically reversible and socially not. Reading a record changes nothing and discloses everything. So the classification needs a second test beside undo: is the action visible to somebody who could object? Where both fail, a person approves.

Our own weakness is the one every checklist carries. A short list is finished in an afternoon, and can be finished dishonestly. What keeps it honest is the artefact, not the ceremony: a list of systems reached, a dated decision per tool, and a signature on the acceptance. Without those three afterwards, the review did not happen, whatever the ticket says.

The review, in one page#

This checklist is GRCIDE's working practice, not a requirement of any standard. Eight questions, answered in writing before an agent holds a production credential.

1. Whose identity does it use, its own or a person's?
2. Which systems does that identity reach, and with what rights in each?
3. Which tools are on the allow-list, and what makes each necessary for this task?
4. Where does a tool's credential hold more than its task needs?
5. What content will it read, and who can write into that content?
6. What sits in its hidden context, and would exposure cost anything?
7. Which action classes may run unattended, and which need a named person?
8. Who accepted the remainder, at what level, and when does that acceptance expire?

Two rules hold the eight together. The answers attach to the change, so record and grant travel as one artefact. And the review runs again whenever the tool list changes.

Related on GRCIDE#

• Agent governance is a permissions problem before it is a model problem, the reading this note works from.
• Governing AI and agents: who decides what, the decision table these questions come out of.
• GRC automation patterns, on where an agent estate sits among the automation already running.