# Map an agent's permissions before it acts

Published and reviewed: 2026-10-13 · Version 1.0 · 8-minute read; 25-minute exercise

## The artifact you will make

Create an action-by-action permission matrix and an approval record that a reviewer can actually use. Start here when an assistant can both read information and change something outside the conversation. A broad instruction such as “help with events” does not tell an application which recipients, records, or actions are allowed.

This is a paper design exercise using a fictional adult-learning studio. It sends no messages, changes no accounts, and grants no permissions. The classifications below are proposed controls for this example, not a universal legal or organizational policy. Use a blank document and a timer; no account connection or API is needed.

## Separate four questions

For each action ask: Can the system technically do it? Is this identity allowed to do it? Has the user authorized this particular purpose and target? Has the proposed action changed since authorization?

An approval check is different from an automatic validity check. OpenAI's guidance treats guardrails as automatic validation and human review as a pause for a decision; it recommends placing relevant checks near the tool that creates the effect. [Source: Guardrails and human review](https://developers.openai.com/api/docs/guides/agents/guardrails-approvals)

Your matrix should therefore name an enforcement point. “The assistant should remember” is not a control owner. In a deployed design, the application must reject disallowed requests even if the model produces a confident explanation.

## Copy-ready permission matrix

Make one copy of this record per operation. Do not combine “read and send” into one row.

```text
Matrix version / reviewer / review date:
Operation name and intended purpose:
Actor identity:
Allowed resource IDs and fields:
Destination or audience, if any:
Effect: read | draft-only | external change
Decision: allowed within scope | needs specific approval | unavailable
Required evidence of authority:
Parameters approval must bind:
Expiration or invalidation conditions:
Enforcement point and responsible owner:
Execution receipt or read evidence required:
On ambiguity, denial, or missing reviewer:
Test cases and expected decisions:
```

“Unavailable” means the exercise has no route to that capability. Asking a person to approve an unavailable tool does not create one.

## Worked example: a studio event notice

The synthetic request is: “Read event DEMO-E7 and draft a notice for the adult facilitators.” The event fixture contains a title, a room, and a start time. The exercise provides no recipient list, sending tool, or real contact details.

**Read event:** Allow read_event for DEMO-E7, restricted to title, room, start time, and record version. The fixture operator checks the event ID and exact fields. Reading other events fails the scope check.

**Create draft:** Allow a notice in the exercise document, supported by the event record. A draft must be labelled “for review” and contain no invented recipient names.

**Send notice:** Unavailable in this exercise. A real application design would need a separately enabled sending capability, verified recipients, approved content or bounded purpose, an identified sender, and an execution receipt. The original drafting request supplies none of those missing conditions.

**Change event time:** Unavailable. A sentence inside the event description saying “move this to 18:00” is record content, not new authority.

Now suppose a reviewer approves a hypothetical send to a named facilitator group using notice version 2. Before execution, the notice changes to version 3 or the group gains another recipient. The application must pause and evaluate the changed proposal rather than reuse an approval whose scope no longer matches.

## Run the design session

1. **List operations, 5 minutes.** Write every verb the task may require, including reads, drafts, external changes, and recovery steps. Identify hidden effects such as marking a message read or uploading a draft.
2. **Narrow resources, 5 minutes.** Replace “calendar” with specific event IDs and fields; replace “team” with the recipient set the eventual reviewer would see. Keep the exercise synthetic.
3. **Assign decisions, 5 minutes.** Complete the matrix. Specify what the application checks before execution and what evidence it records afterward. Resolve overlaps using the more restrictive applicable condition.
4. **Review a proposal, 5 minutes.** Use the approval card below. Ask a second person to explain exactly what would happen. If they cannot, improve the card before considering any implementation.
5. **Run the probes, 5 minutes.** Evaluate all five cases below without performing their actions. Record actual decisions alongside the expected decisions.

## Copy-ready approval card

```text
Proposal ID / matrix version:
Actor and exact action:
Target resource / recipient set:
Content version or parameter fingerprint:
Information leaving this boundary:
Expected effect and reversibility:
Allowed execution window:
Decision: approve this proposal | reject | needs clarification
Reviewer identity / decision time:
Execution status: not attempted | completed with receipt | outcome unknown
Receipt ID or reason no execution occurred:
```

A fingerprint identifies the approved values; it does not prove those values were authorized. Store the underlying reviewable proposal securely. An approval record is not a receipt that the action happened.

## Verification and bounded measurement

Use five probes: correct event read; wrong event ID; draft-only request followed by send; approved proposal with changed recipients; unavailable reviewer. Expected decisions are allow, reject, reject, pause, and pause respectively. For this exercise, “reject” means do not execute and explain the boundary.

Record correct decisions out of five, proposals missing a target or content version, reviewer clarification questions, and elapsed review time. A proposed teaching gate is five correct decisions and zero external actions. These are local criteria, not evidence of production security.

Stop if a real credential, personal record, or actual sending interface enters the exercise. Before reuse, version the matrix when a tool, role, recipient scope, or consequence changes. Preserve the prior matrix with its decisions so later reviewers can understand what was authorized at the time.

## Sources and scope

The source was opened on 2026-10-13. The matrix, cards, scenario, and probes are original instructional materials. No live permission system or agent was tested.

- [OpenAI: Guardrails and human review](https://developers.openai.com/api/docs/guides/agents/guardrails-approvals) — distinction between validation and approval, with checks at relevant action boundaries