Who approves, and what may an agent do?
Risk classes, an agent card and permission checks. Distinguish human authorisation, organisational instructions and verified technical restrictions.
2026-09-25 · 1.0 · PL / EN
01 / A role name grants no permissions
Calling a model a “director” may help organise work, but does not establish who authorised it to send a message or change data. Separate its conversational role from its account, tools and human process owner. Another agent can review the result; that does not make it a human approver.
This method draws on three documents with different statuses: a draft role structure, a governance proposal and an accepted architecture decision for prototypes. We do not present proposals as adopted organisation-wide policy or a prototype description as a current production audit. The practical pattern is that every operation needs a defined scope, an owner and evidence of its outcome.
02 / Five classes for discussing risk
This scale adapts a working method. It is neither a legal classification nor a universal standard. Classify the specific action together with its data and effects, not the model's name. The same agent may analyse public text without permission to send it to recipients.
- R0 — observation: read public data or calculate with synthetic data without changing state. Record the source and result.
- R1 — draft: prepare a proposal in a designated location. It must remain identifiable as a draft.
- R2 — bounded change: a reversible internal operation with a named owner, scope and acceptance criterion. “Reversible” requires a verified recovery route.
- R3 — material effect: publication, external contact or intervention in an important process. Specify who approves and how; separate execution and assessment where risk warrants it.
- R4 — outside the mandate: an action prohibited by the profile, such as independently expanding permissions. Stop and refer it to an authorised human; the agent cannot downgrade its own action.
Reading confidential data does not become R0 merely because nothing is written. The data recipient, execution environment, access scope and disclosure risk matter. This article does not establish legal rules for employment, finance or corporate representation.
03 / Two distinct approval modes
One mode approves an exact operation: the human sees the content, recipient, object and effect, and the system binds the decision to that version. A material argument change requires reassessment. A cryptographic hash helps compare versions, but does not itself establish the approver's identity or authority.
The other mode is a previously granted, bounded mandate: specified action types in a specified channel, with limits and stop conditions. There is no need to pretend that a human clicked approval for every output. Instead, demonstrate that each operation was within the mandate. Silence in response to a new request does not expand earlier authorisation.
For this L00P.AI series, the user authorised the agent to publish reviewed resources and send Telegram notifications, with withdrawal available after publication. This is a separate mandate for this process, not a change to newsroom rules or permission for arbitrary communication. Post-publication oversight cannot recall copies already downloaded by readers.
04 / An example agent card
The example is fictional. “AI catalogue assistant” prepares exhibit descriptions in a test catalogue. The process owner defines this card; the names are illustrative.
- Identity and owner: agent
catalog-demo, owner Marta; a deputy and contact route are entered in the register. - Purpose: propose descriptions from approved public material, with source links.
- Data: the demonstration collection only; no donor data, accounts or private documents.
- Tools: read the designated collection and write drafts to a separate folder. No publishing, email or permission-management tool.
- Limit: at most ten drafts per run, no purchases; an execution limit set in configuration.
- Acceptance: agreement with sources, explicit gaps and correct links between descriptions and objects. A human separately selects material for publication.
- Validity: this demonstration session only; access expires afterwards. The register records the model, instruction version, review date and evidence that access was removed.
- Stop: Marta can suspend the task; resuming requires establishing the cause and rechecking scope.
Ten is an illustrative limit, not a measured result. The card is not an operating configuration. Until restrictions have been implemented and checked, describe them as requirements.
05 / An instruction is different from a technical restriction
“Do not publish” in an instruction defines expected behaviour. A tool that can only save drafts reduces the available action scope. A restricted account and service-side enforcement provide further layers. A description alone does not verify any of them.
If the agent also has a general terminal, another account or direct API access, the absence of a publishing button in one tool does not prove publication is impossible. Acceptance covers every available route to the same effect. The source decision describes separate prototype restrictions and explicitly notes the absence of a shared test. We do not turn that into a system-wide guarantee.
The OWASP Authorization Cheat Sheet recommends least privilege, denial by default and permission checks on every request. These are design guidelines, not certification of a particular installation. In this adaptation they correspond to an explicit card scope, enforcement in the tool or service, and refusal tests.
06 / How to accept an approval gate
Before allowing the process to handle real data, run controlled trials in a test environment. The following is an acceptance plan, not a report of tests performed on a new gate.
- An authorised draft write should succeed and produce a result that can be read back.
- A publishing attempt through a draft-only profile should be rejected outside the graphical interface too.
- A missing decision, expired validity period or revoked mandate should stop an action requiring that approval.
- Changed content, recipient or object should not reuse approval for an earlier version.
- A second model should not be able to approve in a human role.
- A repeated operation should not create a second effect before the first is resolved. Establish the state when the outcome is unknown.
- The stop control should prevent new actions; separately establish what happens to an operation already in progress.
For each trial, record the expected and actual outcome, tool version, time and operation identifier. Mark missing tests “not checked”. An organisational rule without technical enforcement can still be useful, but needs an honest description and oversight.
07 / The record and withdrawal
Record who granted the mandate, its approved scope, the executed version and the confirmed effect. The record should reconstruct the decision without copying secrets or entire confidential documents. “Completed” is insufficient; inspect the post-operation state, as in the CMS readback acceptance method.
Revoking access, stopping a queue and withdrawing public material are different actions. Define their owners and verification separately. Stopping a process does not guarantee recall of a message already sent. Resumption should follow investigation, not merely elapsed time.
08 / Sources and scope of this adaptation
The full draft role structure dated 13 April 2026, SONAR governance proposal dated 6 August 2026 and accepted decision on publishing prototype restrictions were read. The older document assigns job titles to agents; the later proposal explicitly separates an agent from human responsibility. This public method adopts that distinction without claiming formal adoption of the entire structure.
OWASP documentation was checked on 25 September 2026. No new production permissions audit or test of the fictional card was performed. Hardware prices, historical test counts, account details and legal claims are not carried over from the sources. Codex prepared the article, translation and diagram; author review was completed without an independent second-model review. Changes to the mandate, tools or data, or a discovered bypass, require reassessment.