What should an AI agent be allowed to do in production?
What should an AI agent be allowed to do in production?
Section titled “What should an AI agent be allowed to do in production?”Quick answer
Section titled “Quick answer”The safest default is:
- read narrowly,
- draft freely within scope,
- ask before writing,
- and never execute broad side effects by default.
Production AI agents should earn permission in stages. They should not start with wide authority just because the workflow sounds useful.
The permission ladder
Section titled “The permission ladder”Most healthy production systems grow through four levels:
- Read: inspect documents, records, or pages within a narrow scope.
- Draft: produce a recommendation, summary, response, or action plan.
- Propose: prepare a structured action that a human can approve.
- Execute: carry out a side effect after explicit policy and approval rules are satisfied.
Many teams skip directly from read to execute. That is where hidden risk usually enters.
Why broad permission is a trap
Section titled “Why broad permission is a trap”Wide tool access creates several problems at once:
- harder evaluation,
- harder incident review,
- larger blast radius,
- weaker user trust,
- and more expensive approvals because reviewers no longer understand what the agent can actually touch.
The agent may look flexible, but the operating system around it becomes brittle.
What should usually be allowed early
Section titled “What should usually be allowed early”Early production agents are strongest when they can:
- search or read from narrow sources,
- classify or summarize content,
- draft suggested actions,
- prepare tool arguments,
- and surface confidence or uncertainty for review.
These permissions create leverage without making the agent the final authority.
What should usually require approval
Section titled “What should usually require approval”Approval should exist whenever the action can:
- write or mutate a record,
- contact a customer,
- spend money,
- change permissions,
- trigger external systems,
- or alter production content.
That does not mean the agent is weak. It means the workflow has a visible control boundary.
Read scope matters as much as write scope
Section titled “Read scope matters as much as write scope”Many teams focus only on write danger. But broad read access is also risky when the agent can see:
- sensitive personal data,
- contracts or financial information,
- internal strategy material,
- or credentials and secrets through adjacent systems.
A good permission design narrows both read and write scope instead of assuming read-only is automatically safe.
Whose authority should the agent use?
Section titled “Whose authority should the agent use?”The system should be explicit about identity:
- user-scoped authority when the agent is acting as the user inside their normal boundary,
- service authority when a workflow-owned system identity is safer and more auditable,
- and mixed models only when the team can explain the boundary clearly.
Permission mistakes often begin when identity is implied rather than designed.
Approval is not enough without narrow scopes
Section titled “Approval is not enough without narrow scopes”Approval does not fix a bad permission model.
If the agent can access too many systems, one approval step still leaves the team with:
- large traces,
- confused reviewer burden,
- unclear incident analysis,
- and too many things that could go wrong before the approval point.
Approval works best after the scope is already narrow.
The best rollout rule
Section titled “The best rollout rule”Expand permissions only when the team can show:
- stable performance at the current permission level,
- good trace visibility,
- acceptable approval behavior,
- and clear business value for the next step up the ladder.
Permission growth should follow evidence, not enthusiasm.
A practical default policy
Section titled “A practical default policy”For many teams, the best first production policy is:
- narrow read access to one task-specific source set,
- draft-only outputs,
- structured proposals for any side effect,
- explicit approval before execution,
- and full audit traces for every run.
This is much easier to operate than a broad “assistant” model with unclear authority.
Implementation checklist
Section titled “Implementation checklist”Your permission design is probably healthy when:
- the agent’s read scope is specific and documented;
- draft, propose, and execute are treated as separate capability levels;
- approval is attached to side effects, not only to vague “high risk” labels;
- the agent’s identity model is explicit;
- and scope expansion happens only after observed success.