Start from actions, not a trust label
“Trusted agent” is too coarse for an operating plan. Reading an approved file, writing a draft, contacting a customer, and deleting a database have different consequences. List the actions your workflow actually needs, then choose a boundary for each one.
Our suggested starting point is read access to approved inputs, write access to a draft workspace, and explicit review before external effects. This is an operating pattern, not a guarantee that every harness enforces the same controls.
- Read: identify the allowed sources and records.
- Write: restrict outputs to a designated workspace.
- Send or publish: require a reviewer to inspect the exact output.
- Delete or spend: use narrow scopes and explicit limits, or leave the capability unavailable.
Use runtime controls where available
A prompt can describe policy, but it does not create isolation. Configure the harness permissions, credentials, workspace boundaries, and tool access. Confirm behavior in the version and execution mode you actually use.
Avoid giving a small drafting job access to an entire account. Prefer a scoped integration or separate working account when possible. Store credentials through the supported secret mechanism rather than embedding them in instructions, templates, or exported runbooks.
Treat retrieved content as input
Web pages, emails, documents, and tool responses may contain instructions that conflict with the job. Your workflow should treat them as material to analyze rather than permission to expand its scope. Test a sample input that attempts to change the destination, request a secret, or bypass review.
If the task legitimately requires a new action, stop and have the owner review the changed scope. Do not let a discovered instruction silently become part of the operating policy.
Make approval specific and inspectable
A useful approval packet contains the exact action, target, proposed content, supporting evidence, and consequence. “Proceed?” is not enough when the reviewer cannot see what will happen.
Keep a record of who approved the action and which version they saw. If the content or destination changes materially, obtain a fresh review. For recurring work, document who can pause the schedule and revoke access.
Proposed action: publish draft 2026-09-07
Destination: specified CMS draft ID
Changes: attach the final diff
Evidence: source links and validation results
Reviewer: named owner
Failure plan: leave the draft unpublished and report the errorSources and further reading
These guides combine linked documentation with our suggested operating practices. Examples are illustrative; they are not customer results or harness benchmarks.