AI agent permission design: why read, write, and execute must be separated

1. Overview: permission design is operations design

Companies often move from "AI can answer questions" to "AI can use our tools" too quickly. The demo looks better when the agent can open Notion, search Google Drive, update a CRM row, draft email, and trigger a workflow. But every connector changes the risk profile.

OpenAI safety guidance for agent workflows says MCP tool approvals should stay on so end users can review operations, including reads and writes. OWASP guidance points in the same direction: over-privileged agent skills, excessive agency, prompt injection, and sensitive information disclosure are not theoretical concerns once tools and company data are connected.

The practical answer is to design permissions like a building key system. A visitor badge may open the lobby. An employee card may open the office. A finance key may approve payment. AI agents need that same separation before they touch company systems.

2. Small dictionary: the technical words in plain language

Permission means the key you give the AI. A key can open one room, many rooms, or the entire building. Scope means exactly which rooms and actions that key can access.

Role means the job title attached to the key. A support-draft agent, finance-review agent, and founder-assistant agent should not inherit the same access just because they all use the same model.

Least privilege means giving the smallest useful key. If the agent only needs to summarize policy, it does not need write access to the policy folder. If it only drafts email, it does not need permission to send email.

Temporary credential means a rental key that expires. Instead of giving a permanent master key, the system gives the agent short-lived access for one task or one session.

Audit log means the receipt or CCTV trail. It records what the agent read, what it changed, which tool it called, who approved it, and when the action happened.

• Read: the AI can look at information, such as policy documents, tickets, meeting notes, or customer records.
• Write: the AI can create or edit a draft, internal note, CRM field, ticket status, spreadsheet row, or proposed document.
• Execute: the AI can cause an external or hard-to-reverse action, such as send, charge, delete, publish, sign, order, invite, or call an external API.
• MCP: a standard connector that lets AI applications connect to external data, tools, and workflows.
• Human approval gate: a checkpoint where the AI stops and a person confirms the next action.

3. Read permission: start with knowledge, not action

Read permission is usually the first useful layer. It lets an agent answer with company context instead of generic advice. It can read SOPs, refund policy, product specs, past tickets, onboarding documents, customer history, and meeting notes.

But read access is not harmless. OpenAI warns that private data leakage can happen when a model shares more data than intended with connected tools. OWASP also treats sensitive information disclosure as a core LLM application risk. That means read access still needs scope.

A practical rule: let the agent read what a new employee in that role would be allowed to read. Customer support may read customer tickets and policy. It should not read payroll, founder notes, private investor documents, or raw secrets.

• Good read scope: public policies, approved SOPs, customer-facing docs, categorized tickets, product FAQs, and non-sensitive knowledge notes.
• Risky read scope: raw inboxes, private Slack DMs, payroll, legal disputes, credentials, health data, unreleased financials, or broad "all files" access.
• Read controls: source allowlists, document sensitivity tiers, retrieval logs, PII filters, and answer citations.

4. Write permission: let AI prepare, but separate draft from record

Write permission is where many teams blur the line. A draft is not the same as an official record. A suggested CRM update is not the same as a committed CRM update. A refund memo is not the same as a refund.

The safest middle layer is draft-only write. The agent may prepare a reply, fill a form, suggest tags, update a local staging table, or create an internal note, but a human or deterministic rule commits the final change.

This is also where review cost becomes visible. If the agent writes too much too freely, the team spends time checking hidden errors. A good write permission should produce smaller, checkable changes with clear source links and a visible diff.

• Low-risk write: draft replies, summarize calls, propose tags, create checklist items, prepare report outlines, and fill fields in a review queue.
• Medium-risk write: update CRM stage, change ticket status, edit internal documentation, or write to a shared spreadsheet.
• Write controls: staging area, diff view, owner review, rollback path, field-level permissions, and sampled QA.

5. Execute permission: treat outside-world actions as high risk

Execute permission is the moment the AI affects the outside world. Sending an email, charging a card, deleting a record, publishing a page, creating a contract, changing permissions, or calling a production API can create legal, financial, brand, or customer damage.

OpenAI agent guidance recommends risk-rating tools by factors such as read-only versus write access, reversibility, account permissions, and financial impact. In plain language: an action is riskier when it is hard to undo, affects money, exposes private data, or changes what another person sees.

For non-technical teams, the rule can be simple. AI may recommend. AI may draft. AI may prepare. But high-impact execution needs an approval gate, a named owner, and a log.

• Always-gated actions: send external email, refund or charge money, delete data, publish customer-facing content, sign contracts, invite users, change permissions, and trigger production deployments.
• Never-start-here actions: broad shell access, secret-file access, payment execution, legal commitments, mass messaging, and destructive bulk changes.
• Execution controls: human approval, two-person review for high impact, rate limits, domain allowlists, temporary credentials, rollback plans, and audit logs.

6. The permission ladder for a real rollout

The safest rollout is not "no agents." It is a ladder. Start with one repeated workflow and move up only when the previous step is measurable, logged, and boring enough to trust.

The social signals from x-inbox-router point to the same operational problem from another angle. Posts about Tool Calling, MCP, and Skills warn that these are different layers, not interchangeable buzzwords. A markdown company OS wired through many MCP tools can be powerful, but the moment tools move from research to action, safeguards and ownership matter.

A Guildex-style permission ladder makes that distinction visible before the team connects everything.

• Level 0: no tool access. The AI only answers from pasted context.
• Level 1: read approved knowledge. The AI can cite sources but cannot change records.
• Level 2: draft-only write. The AI prepares outputs in a queue or staging area.
• Level 3: reviewed write. The AI commits limited internal changes after approval.
• Level 4: gated execution. The AI can trigger high-risk actions only after explicit approval.
• Level 5: narrow auto-execution. Only reversible, low-impact, rate-limited actions run automatically after repeated proof.

7. Failure patterns to avoid

The first failure is master-key access. A team connects an agent to every file, every channel, and every tool because it is convenient. The result is not a smart employee. It is an unbounded actor with unclear responsibility.

The second failure is hidden action. The agent appears to be summarizing or drafting, but one tool call also changes a CRM row, sends a message, or exports a list. If the operator cannot see the boundary, they cannot control it.

The third failure is approval theater. A human clicks approve on a clean summary without seeing sources, diffs, or risk. A real approval gate shows what will happen, why, what data was used, and how to undo it.

• Do not combine read, write, and execute into one broad "AI tools" permission.
• Do not let agents read `.env`, credential stores, payroll, or private legal folders unless the use case truly requires it.
• Do not let tool descriptions or external text directly drive privileged actions without structured validation.
• Do not approve actions from a summary alone. Show sources, changed fields, affected users, and rollback options.
• Do not let one successful demo become permanent production permission.

8. The Guildex rule: build the permission map before the agent

A practical permission map has six columns: source, owner, sensitivity, allowed action, approval requirement, and log location. That map is more important than the model name at the start.

For each workflow, ask: what does the AI need to read, what may it write as a draft, what may it change after review, and what must never be automated yet? This turns vague fear into concrete operating rules.

The goal is not to slow the company down. It is to let AI become useful without making responsibility disappear. Good permission design lets people trust the system because they can see the keys, the gates, and the receipts.