Split the workflow into separate read, draft, and send permissions, then require a fresh consent or approval step when the action crosses into external effect. The goal is to stop capability from expanding silently inside a single session. That keeps authorisation aligned to intent rather than to the initial login event.
Separate Read, Draft, and Send as Distinct Authority Boundaries
An agent becomes risky when a single session carries enough authority to move from analysis into external effect without a new decision point. The cleanest control is to split the workflow so the read step can gather context, the draft step can prepare content, and the send step is a separately authorised action. That keeps intent, scope, and blast radius aligned.
In practice, the important design choice is not whether the agent can compose an output, but whether it can cross a boundary that changes the real world. When the same task context is allowed to execute outbound actions, the agent can silently accumulate capability and turn an apparently harmless request into a higher-impact one.
That pattern is why AI Agent Authorisation Guide is useful here: it frames task-scoped access and per-action policy as the default, rather than treating the initial login as permission for every later step.
Why Read-Only Tasks Still Need a Hard Stop Before External Effect
“Read-only” is only safe if the runtime can enforce that the agent never acquires a send path from the same authority context. The most common failure is capability creep, where a task starts as summarisation, research, or extraction, then gains the ability to email, post, file, approve, or modify once a tool chain is introduced.
That makes the control problem about intent drift, not just access control. A prompt, a user instruction, or a benign first action should not be enough to authorise outward side effects later in the same session, because the downstream effect is what creates business and security exposure.
For teams building and reviewing these flows, Zero Trust for AI Agents is a strong reference point because it treats every action as something that must be re-verified rather than inherited from a prior trust decision.
The practical standard is simple: if the action changes something outside the agent’s own working context, the workflow should require a fresh check that is separate from the read step. That can be approval, re-authentication, a scoped consent screen, or a policy decision that is evaluated at the moment of effect.
Design the Approval Step So It Cannot Be Bypassed by Context Reuse
The approval step only works if it is bound to the exact outbound action, not to a generic session or a broad user request. Teams should describe what will happen, what target will be affected, and what evidence justifies the send, then require a fresh decision before the tool call executes.
This is where agents often fail operationally: they keep enough conversational context to make the outbound step look like a continuation of the same harmless task. A robust design forces the system to treat send as a new risk event, not as a natural continuation of read or draft.
The strongest controls usually combine policy and observability. AI Agent Observability, Audit and Incident Response Guide is relevant because you need to be able to prove which action was proposed, which action was approved, and which action actually left the system.
For especially sensitive outbound actions, Browser and Computer-Use Agent Security Guide reinforces the same principle in interactive environments: isolate the session, restrict scope, and require confirmation before a page, account, or desktop interaction can produce external effect.
Risk and Threat Considerations
The main risk is that a read-only request becomes a delivery mechanism for outbound action once the agent has enough delegated authority or a reused session to act externally. That creates exposure to unintended messages, changes, approvals, data transfer, or account actions, even when the user believed the task was limited to analysis.
Failure mechanism: The agent inherits a broad enough context that draft and send are treated as one continuous workflow, so the system never forces a new authorisation check at the point where external effect begins. Attackers and failure conditions both exploit the same weakness, namely a missing boundary between internal reasoning and outward execution.
Impact: The result can be unauthorised outbound communication, data leakage, fraudulent approval, destructive change, or escalation of privilege through a trusted automation path. At scale, the issue becomes more dangerous because one weak workflow pattern can be reused across many agents, many users, or many integrations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The question is about preventing an agent from crossing from read-only to outbound action. |
| Recommendation — Enforce per-action authorisation so read access cannot silently become send authority. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Separate read, draft, and send permissions to prevent excess capability within one session. |
| IA-5 — Authenticator Management | Fresh consent or approval depends on controlled use and lifecycle of the credentials that enable action. | |
| Recommendation — Limit each agent step to the minimum permission needed for that step. Rotate or scope credentials so outbound actions require a distinct, current authorisation context. | ||
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Policy-based Access Decisions | The outbound step should be re-evaluated at the moment of effect, not inherited from prior context. |
| Recommendation — Make every external action pass a fresh policy decision before execution. | ||
| OWASP ASVS | V8 — Authorization | The send step is an authorisation boundary that must be separately enforced from read and draft. |
| Recommendation — Require explicit authorisation checks before any external side effect. | ||
Practitioner Guidance
What to verify: Confirm that the “send” step cannot be reached through the same token, role, or runtime permission that was sufficient for reading and drafting. If the outbound action can succeed without a fresh policy decision, the control is too weak.
Decision rule: If the action creates an external effect, treat it as a new authorisation event, even when the user originally asked for a read-only task. If the action only prepares content locally, keep it in the read or draft phase.
What good looks like: The agent can explain, draft, and stage work, but it cannot cross the final boundary until the exact outbound target and effect have been reviewed and approved.
Practitioner takeaway: The safest pattern is not to make the agent “more careful” inside one session, but to make the session incapable of silently expanding from analysis into action.