AI agents with write access: a three-level approval model for SMEs
Transparency note
This article was created automatically with AI. The linked sources were checked during creation on 25 August 2026; no substantive human editorial review took place before publication. The example classifications, acceptance tests and ten-day rollout plan are operational proposals, not customer cases, measured results or performance promises.
A prompt can tell an AI agent how to behave. It cannot reliably determine what the agent is technically authorised to do. As soon as an agent can read and change records, send messages or trigger APIs, its authority must be limited outside the model.
This is not a theoretical distinction. The current Google Cloud article on agent governance describes agents as systems with access to emails, databases and API actions. OpenAI’s practical guide likewise separates models, tools and instructions, and recommends assessing tools by write access, reversibility, required account permissions and potential impact.
For SMEs, the practical answer is not a heavyweight rulebook. It is a small, testable contract: What may the agent see? What may it propose? When may it write? And which action requires a specific human approval first?
In brief
- A prompt is not access control: permissions belong in tools, APIs, credentials and deterministic workflow rules.
- Every action receives a level: read and propose, write internally and reversibly, or act externally or with high impact.
- Approvals apply to one specific proposal: target, change, time and scope must remain verifiably unchanged afterwards.
- Execution does not end with API success: the workflow reads back the actual target state and reports deviations.
- Start small: one agent, one process, a few permitted tools and ten meaningful tests make a bounded pilot.
Prompts define behaviour – but not authority
The instruction “Only change approved records” is useful, but it cannot enforce itself. The model interprets context; the technical approval layer must independently decide whether this exact tool, record, action and scope are permitted.
Inside the prompt
Objective, preferred working style, decision criteria, required context and rules for questions or escalation.
Outside the model
Tool allowlist, data scope, write boundaries, approval state, credentials, volume limits, logging and stop rules.
This separation follows a simple principle: the agent may select or prepare an action, but the workflow and access layer decides deterministically whether it can be executed. If you first need to clarify the right role for agents in a process, see Lyron’s overview of AI agents in business processes.
The eight-field agent permission pass
The permission pass is a compact operating description for exactly one agent and one bounded process. It is a Lyron working aid, not a technical standard. Unclear fields are not left “to be clarified later”; they block production write access.
| Field | What to record | Test question |
|---|---|---|
| 1. Assignment | A clear process purpose and a defined end | When is the assignment complete? |
| 2. Identity | Technical agent identity, operator and process owner | Who acts, and who is responsible for operations? |
| 3. Data scope | Permitted data types, tenants, records and exclusions | Which data may be read or changed? |
| 4. Tools | Explicit tool and API allowlist with permitted operations | Which specific function is reachable? |
| 5. Limits | Prohibited actions plus volume, time and repetition limits | What must never happen, or only happen within limits? |
| 6. Approval | Action level, approving role and validity of consent | Who must confirm which proposal, and when? |
| 7. Evidence | Inputs, decision, action and target state to be logged | Can the run be reconstructed later? |
| 8. Stop and recovery | Abort criteria, escalation path and possible rollback | How can the run be stopped safely or reset? |
One pass per bounded assignment
“Sales agent” is too broad. “Qualifies new form enquiries, creates an internal draft and always submits external messages for approval” can be tested. New tools or a new data scope require a deliberate change to the pass.
The three-level action matrix
The level is assigned per tool action, not broadly per agent. An agent may therefore read customer data, write internal notes only under defined conditions and send external messages exclusively after individual approval.
| Level | Typical action | Execution rule | Required evidence |
|---|---|---|---|
| 1. Read and propose | Read and classify permitted records, or prepare a change or message as a draft | No production write or send access; sensitive outputs remain within the permitted process context | Source, proposal, uncertainties and rules used |
| 2. Write internally and reversibly | Update a status or internal field in a bounded system | Only permitted fields and values; preserve the prior state, check limits and test rollback in advance | Before-and-after diff, rule check, execution ID and read-back verification |
| 3. External, irreversible or high impact | Send a message, delete a record, place an order or trigger a financially relevant action | Specific human approval for each proposal; a changed target or content requires a new approval | Approving role, exact confirmed payload, time, result and verification |
This assignment is an operational risk classification, not a universal rule. OpenAI names write access, reversibility, required account permissions and financial impact as useful criteria for tool risk, and recommends human oversight for sensitive, irreversible or consequential actions. The exact classification must fit the organisation’s own process.
Why a sandbox alone is not enough
A sandbox limits where code runs and which resources the run can reach. It does not automatically answer whether the agent changes the correct customer record, whether a message has been approved by the process owner or whether the supplied permission was intended for this exact action.
The n8n guide from 6 August 2026 therefore describes limited tools, separated credentials, workflow rules, environments and logging alongside runtime isolation. Its central practical point is that an isolated runtime can protect the host system, but it does not decide integrations, approvals or permissions in connected services by itself.
Four complementary control layers
- Identity: a dedicated, traceable account instead of shared full access.
- Capabilities: narrow functions instead of an entire application or arbitrary API calls.
- Approval: proposal and execution as separate states with a binding approval object.
- Observability: combine the decision, tool call, result and read-back verification.
NIST is also working on agent authentication, identity infrastructure and security evaluations in its Agent Standards Initiative, updated 14 August 2026. This is not a finished SME specification, but it reinforces that agent identity and authorisation are distinct technical building blocks. The OWASP Top 10 for Agentic Applications 2026 provides a broader complementary risk list.
Propose, validate, approve, execute, verify: seven steps
- 1. Freeze the context: save the assignment, target system, record, current version and permitted action as immutable run context.
- 2. Generate the proposal: the agent supplies the target, intended change, reason, sources used and its uncertainties—still without write access.
- 3. Validate deterministically: check the schema, required fields, data scope, tool allowlist, volume limit, current record version and action level outside the model.
- 4. Route approval: level one remains a draft, level two follows the documented internal rule, and level three shows the responsible person the target and a before-and-after view for explicit consent.
- 5. Execute within limits: only now use a short-lived execution token scoped as narrowly as possible; an execution ID and idempotency key prevent unnoticed repetitions.
- 6. Verify the target state: read the record or delivery status back from the target system and compare it with the approved outcome; a successful API status alone is not enough.
- 7. Complete or stop: log the run, approval and result. If they differ, do not trigger a chained action; stop, roll back where appropriate and hand the case to the named owner.
Approvals must not “drift”
Consent to message A for recipient B does not apply to a message that is reworded later or sent to recipient C. Store a fingerprint of the approved proposal; if the target, content, volume or initial state changes, the approval expires.
For technical containment, small and clearly described functions are better suited than universal interfaces. Lyron’s guide to API integration shows how systems can be connected through controlled handoffs.
Ten acceptance tests before production write access
Every test needs an expected state, a visible error message, the permitted follow-up action and a verifiable log entry. The following cases are a test template, not a claim about an existing customer environment.
- 1. A read-only assignment changes no record.
- 2. A proposal shows the target, source and before-and-after view in full.
- 3. A tool that has not been approved is technically blocked.
- 4. A record outside the permitted data scope is rejected.
- 5. A record version changed between proposal and execution stops the run.
- 6. A reversible internal change can be rolled back using the preserved prior state.
- 7. An external message is not sent without specific approval.
- 8. A change to the target or content invalidates an existing approval.
- 9. A retry or duplicate callback creates no second change or message.
- 10. Missing logging, verification or connectivity results in a safe stop.
After launch, these cases remain as regression tests. The team should also collect real deviations without copying sensitive content in an uncontrolled way. The article on security in automations explores credentials, error paths and controlled handoffs in more depth; for ongoing operations, see monitoring AI workflows.
A bounded ten-day implementation proposal
The pilot remains deliberately small: one agent, one process, one production target system and no more than a few clearly defined actions. The schedule is a planning example, not a promise that every technical or organisational starting point will be production-ready in ten days.
Days 1–5: contract and control path
- Day 1: Bound the process, owner and stop criteria
- Day 2: Complete the eight fields of the permission pass
- Day 3: Classify actions and define the tool allowlist
- Day 4: Build the proposal object and deterministic validation
- Day 5: Implement the approval view and binding approval state
Days 6–10: execution and acceptance
- Day 6: Add tightly scoped execution with idempotency
- Day 7: Connect read-back verification, logging and the alert path
- Day 8: Run the ten acceptance tests in a test environment
- Day 9: Test a bounded live run under close observation
- Day 10: Evaluate deviations and confirm, reduce or revoke write access
Production approval is not automatic
If the owner, recovery path, logging or target-state verification is not robust on day ten, the agent remains at level one. A smaller, safer functional scope is a valid pilot outcome.
Conclusion: design authority first, then increase autonomy
Write access turns a helpful assistant into an actor in a business process. The most important boundary must therefore not be hidden in wording. It must be technically enforced as a verifiable combination of identity, tool, data scope, action level and approval.
The permission pass creates a shared contract for this purpose. The three action levels separate harmless drafts from reversible internal changes and consequential external actions. Finally, the seven-step workflow ensures that an approved intention is not only executed, but also checked against the actual result.
Sources and photo credit
Current as of and checked on 25 August 2026. The sources provide technical orientation; the approval model and permission pass are practical Lyron working aids derived from them.
- Google Cloud: Empowering autonomous agents with advanced security governance – published 24 August 2026; agent access, permission and identity management, and human approval for critical actions.
- n8n: AI Agent Sandboxes – Isolation and Secure Execution – published 6 August 2026; the limits of runtime isolation, restricted tools, credentials, workflow controls and logging.
- OpenAI: A practical guide to building agents – checked 25 August 2026; tool risks, guardrails, human intervention and the gradual expansion of agent systems.
- NIST: AI Agent Standards Initiative – updated 14 August 2026; voluntary standardisation, agent authentication, identity infrastructure and security evaluations.
- OWASP: Top 10 for Agentic Applications for 2026 – risk catalogue for agentic applications; checked 25 August 2026.
- Photo: Jakub Żerdzicki on Unsplash, Unsplash License; commercial use and modification permitted. The source page identifies a real photograph taken with a Sony ILCE-6700; the scene shows an empty office building with no recognisable people or brands. Source and licence checked on 25 August 2026.
Should your AI agent be allowed to do more than create drafts?
Lyron helps design agent actions, data scopes and approvals as a controlled workflow—with narrow API functions, traceable execution and a clear human handoff point.
Discuss your permission workflowShare this article: