Editorial illustration.
Originally published 13 August 2026; rewritten and reviewed on 15 October 2026.
An assistant that suggests a code change and an agent that can deploy that change create different responsibilities. The original August article used reporting about Astra to raise this concern. Revisiting it, I find the most useful part is the engineering question: what have we actually allowed the system to do?
This revised article does not treat reports about unpublished internal evaluations as independently verified facts. It focuses on the controls a team can inspect in its own environment.
Begin with the tools, credentials and destinations
List the repositories, cloud projects, databases and communication tools available to the agent. Then identify which actions only read information and which change a system or disclose data.
Give the workflow access appropriate to its task. A documentation assistant usually has a different need from a release operator. Separate development and production credentials, and use a controlled route when additional authority becomes necessary.
Review meaningful boundaries
OpenAI’s official guidance on guardrails and human review discusses controls around agent actions. For a practical workflow, review should show the proposed change and its destination clearly enough for someone to make a decision.
For example, a release proposal should identify the environment, the version and the intended effect. A vague request to “continue” gives the reviewer little evidence. Logging the action and its result helps explain what happened afterwards.
Treat outside content as material to assess
A repository issue, web page or retrieved document can contain useful information without having authority to change the task. An agent should not acquire new permissions simply because a page instructs it to send files somewhere.
Test that distinction with realistic examples before relying on the workflow for sensitive work. Check failure behaviour as well as successful execution: unavailable tools, conflicting instructions and uncertain results deserve clear handling.
The lesson I would carry forward from the Astra discussion is concrete. Model capability matters, but deployment choices determine what capability can reach. Permissions, review and observable results make that relationship easier to manage.