Permissions are part of the product, not just the prompt
Telling a model “do not touch anything else” is useful guidance. It is not an access-control system.
If an agent can operate files, browsers, terminals, APIs or devices, the execution layer should enforce boundaries even when the model misunderstands the task.
Start with least privilege
The useful default is the smallest permission set that still lets the task succeed. That does not mean asking for confirmation every second. It means defining a bounded operating space.
| Permission dimension | Weak design | Better design |
|---|---|---|
| Filesystem | Whole disk by default. | Specific workspace roots; separate read/write grants. |
| Processes | Run arbitrary commands. | Allowed tools or explicit execution approval. |
| Browser | All sessions and sites. | Named domains, profiles or task-scoped sessions where possible. |
| APIs | Broad token reused everywhere. | Minimum scopes, bounded credentials and revocation. |
| Devices | Every hardware capability exposed. | Explicit capabilities such as screen, files or UI control. |
| Time | Permanent access. | Session or task-scoped grants where practical. |
Separate capability from authority
An AI may technically be capable of deleting a file while lacking authority to do so automatically. That distinction is valuable.
For example:
- inspect files automatically, but ask before destructive changes;
- prepare an email automatically, but keep sending approval-gated;
- analyse a repository automatically, but ask before pushing or publishing;
- navigate a site automatically, but stop before a purchase or irreversible account action.
The guide on approval-gated AI agents covers this decision boundary in more detail.
Permission should include the target, not only the verb
“May write files” is too broad. A better grant is closer to “may write inside this workspace for this task”.
Useful permission dimensions include:
- capability: read, write, execute, browse, capture screen, control UI;
- target: folder, repository, domain, API, device or account;
- duration: one action, one task, one session or persistent;
- consequence: read-only, reversible, externally visible or destructive;
- approval: automatic inside boundary or human-confirmed.
Denied paths need testing too
A permission system is not proven because allowed actions work. Try to cross the boundary intentionally.
Can the agent write outside the approved folder? Can it use a capability that was not granted? Can it continue after permission is revoked? Does it fail closed when state is uncertain?
These negative controls belong in the same test suite as successful operations. See How to Test an AI Agent Properly.
Verification comes after permission
Permission answers whether an action is allowed. Verification answers whether the action produced the intended result.
If the agent was allowed to rename a file, read the resulting directory. If it was allowed to change a setting, inspect the post-change state. If it was allowed to call an API, validate the server-side result.
Human control is much stronger when approval is based on evidence rather than a model-generated status sentence.
Revocation and recovery matter
Permissions should be removable without leaving the system in an undefined state. If a task is interrupted, the agent should know which operations completed, which are unknown and which permissions no longer exist.
This is where access control meets failure recovery: a revoked grant should not become an excuse for blind retries.
How this maps to ARKTOR
ARKTOR is designed around the separation between human goal, AI reasoning, operational capability and human authority. Its product direction is not “give the model the whole machine”. It is to expose small, bounded capabilities that can be composed around a real workflow.
The security-research stress test demonstrates why the distinction matters: the system could use real tools and environments, while scope and disclosure decisions remained human.
A practical permission checklist
- What exact capability is required?
- What exact target is required?
- Can read and write be separated?
- Can the grant expire with the task?
- Which actions need a human approval gate?
- How is a denied action represented?
- How is success verified?
- How is access revoked?
- What happens to in-progress state after revocation?
- What evidence is retained for review?
Human-controlled AI is not AI with no autonomy. It is autonomy inside explicit authority.