A practical way to decide what an AI agent may do on your behalf, what it must ask before doing, and what should stay with a human.
An agent does not become safe because it sounds careful. The question is what it can reach, what it can change, and who takes the loss when it is wrong.
1. Smart is not the dangerous axis. A mediocre agent with permission to send a message or delete a record can cause more harm than a better agent that can only draft.
2. Reversibility matters. Reading can usually be contained. A wire transfer, signature, or deleted record can be costly or impossible to undo.
3. Other people raise the bar. If an action changes somebody else’s record, money, access, or reputation, your own comfort with the agent is not enough.
4. A log is not permission. Logging helps reconstruct a mistake. It does not stop an agent from making one. Use it after a low-risk action, not instead of a control.
5. The matrix is a recommendation. It turns published risk-management guidance into a conservative control choice. It is not a law, audit, or certification of any product.
Choose the row closest to what the agent can actually do. Then read across the evidence you have about its operating controls. Click a cell for the reason, the framework basis, and whether the choice is an explicit judgment call.
The four columns describe the controls around the agent, not a claim about any model’s intelligence. These six rows are this project’s control framework, synthesized from the cited publications; they are not a MITRE ATLAS table. No vendor is represented as certified or audited against this matrix.
| Capability class | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|
No rows match this filter. Choose another capability view.
These publications do not publish this exact six-row table. They support risk mapping, least privilege, privacy, security, oversight, and control of excessive agency. The table is an explicit synthesis, not a quotation from any one standard.
Do not start with the prompt. Start with the connections, credentials, APIs, browser sessions, and people the agent can already reach.
Write down every connected inbox, drive, CRM, payment account, calendar, database, browser session, API key, and shared folder. Include indirect reach: a connected tool can often expose more than its name suggests.
For each connection, test the actual permission: read, draft, send, create, edit, delete, approve, spend, or impersonate. A draft permission is not a send permission. Do not collapse them.
Ask: if the agent misread one instruction, followed a malicious prompt, or used the wrong record, what would happen next? Name who is affected, whether the change can be undone, and how long discovery would take.
Set the required control for each permission. Where you decide to allow more, document the owner, expiry date, dollar or record limit, rollback path, and who receives the log.
There is no single published standard that assigns these six capabilities to these four controls. That gap matters.
The supplied standards support risk management and action controls, but none publishes this exact matrix. The row-level recommendations are a conservative synthesis and should be reviewed against your sector, contracts, and jurisdiction.
This page does not determine what any agent product can actually access, log, delegate, isolate, or stop. Verify a product’s live permission boundaries and failure handling in your own environment.
The EU AI Act and other regimes classify risks differently from this operational matrix. A control that is prudent here may not satisfy a duty imposed by privacy, financial, employment, health, or records law.
The first film assumes you have never thought about any of this before, and takes it from the beginning — what an agent actually is, and why permission is the whole question. The second one goes into the six capability classes, the four controls, and the self-audit, in detail. Watch either. Watch both, in that order, if you want the full picture.
No background needed. What separates an agent from a chatbot, why the interesting question is never how clever it is, and what to ask before you hand one a key to anything that matters.
Read access, external action, reversibility, third-party impact, and the point at which a human must stay in the loop.
Model quality changes what an agent can attempt. Permission determines what the attempt can do to the world.
Keep logs, but do not use a clean audit trail to justify an authority the agent should never have had.
When an action changes another person’s money, data, access, or reputation, the comfort of the deploying team is not the only interest at stake.
The uncomfortable conclusion for teams chasing full automation is that a well-placed approval step is not a product defect. It is a refusal to turn speed into unchecked authority.
It is a statement about accountability, reversibility, and the kind of loss that cannot be repaired by saying the system made a mistake.
