An agent can reason using a local model and still send information through an email tool, a webhook, or a remote application. The model endpoint is only one data path.
Start by drawing the entire action loop: input, retrieval, reasoning, proposed action, authorization, execution, and the returned result. Mark every boundary it crosses.
Separate proposals from permission
The model may propose an action and its arguments. A trusted application layer should decide whether that action is permitted for the authenticated user and the current workflow.
Do not give the model control of its own authorization identity. Derive user and tenant scope from the trusted session. Check permissions when the action executes, including when a request is resumed from a queue.
OWASP’s Excessive Agency guidance identifies excessive functionality, permissions, and autonomy as key causes of agent risk. A narrow tool interface and application-enforced permission checks are practical responses.
Define narrow tools
A tool named “run any command” grants much more capability than “look up an approved document by identifier.” Prefer interfaces with bounded inputs, outputs, and side effects.
For example, an internal document tool can accept a document identifier and return only the sections the current user is allowed to read. A message tool can require a known recipient record, a reviewed body, and an approval token.
A conceptual action policy might look like this:
Action: prepare_client_followup
Identity: authenticated workflow user
Scope: records assigned to that user
Output: draft message
External transmission: none
Action: send_approved_followup
Identity: authenticated workflow user
Scope: approved recipient and reviewed draft
Execution: only after a valid approval
External transmission: explicitly permitted emailThis is a design example, not an executable configuration. The two actions have different effects and should be evaluated separately.
Name the real boundary
If a system may send approved email, the whole application is not externally zero-egress. It may have an isolated inference service and controlled external tool access.
That architecture can be appropriate. Describe it accurately: which component is isolated, which broker can communicate outward, what information can cross, and which checks authorize it.
If the complete installation must remain disconnected, tools need to operate on internal services. External delivery must happen outside that installation through an explicitly designed process.
Treat retrieved content as data
A document, email, or tool response can contain instructions that conflict with the task. The application should not treat that text as authority to add recipients, change permissions, access another account, or send unrelated files.
Keep retrieved material separate from trusted workflow instructions. More importantly, enforce permissions at the tool layer so a misleading model response cannot expand its own capabilities.
Test with synthetic documents that ask for unauthorized actions. Inspect both the proposed action and whether execution was blocked.
Make review usable
For a consequential action, show the reviewer the exact destination, content, affected records, and expected effect. “Approve agent action” provides too little information.
Bind approval to the reviewed arguments. If the recipient or message body changes afterward, obtain a fresh approval according to the workflow policy. Add stable request identifiers so retries do not duplicate a send or a business update.
Record proposed, approved, rejected, and executed actions distinctly. A proposal is not evidence that an operation occurred.
Verify the entire loop
Test an allowed read, a forbidden read, an allowed action, an unapproved action, and a replayed request. Include cross-user and cross-tenant cases where relevant. Verify the broker’s external routes independently of the model runtime.
Review logs for unintended exposure of prompts, source data, or credentials. Network restrictions and application authorization address different parts of the path.
Begin with a bounded assistant that drafts or retrieves before adding broader actions. A workflow assessment can define the smallest useful action set and the corresponding acceptance tests.