iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Yes—but only within a scoped, auditable development environment. An agent can be allowed to revise code and run tests, but that permission should not automatically include merging changes, deploying to production, accessing broad credentials, or altering infrastructure. Require a human owner to review and approve changes before merge or production, with stronger approval gates for actions that are sensitive or difficult to reverse.
What should “fix its own mistake” mean?
“Fix” can describe several separate actions. Treat them as distinct permissions rather than one blanket authorization:
- Propose a patch: The agent suggests a change without modifying project files.
- Edit and test: It changes files in a scoped workspace and runs permitted checks.
- Commit or open a pull request: It records the change or submits it for review.
- Merge: It makes the change part of the shared codebase.
- Deploy: It sends the change to a live environment.
Permission for an earlier stage should not imply permission for a later one. A useful default is to let the agent attempt local edits and tests, while reserving merge and production deployment for explicit human approval. This reflects the distinction between routine work inside constrained boundaries and higher-risk actions that need stronger handling. OpenAI’s Codex security guidance describes the sandbox as the technical execution boundary; it does not make every action inside that boundary safe or correct.
Set permissions according to risk and reversibility
Decide what an agent may do by considering the possible impact if it misunderstands the task, produces a faulty change, or follows untrusted instructions. The broader the blast radius and the harder the action is to undo, the more explicit the approval should be.
#1 Best Overall
- Lower risk: Editing code in a disposable or otherwise scoped workspace, then running approved tests.
- More consequential: Changing security controls, handling sensitive data, modifying dependencies, or connecting to external services.
- Highest consequence: Merging, deploying, changing infrastructure, or using credentials with broad access.
For each category, define permitted tools and files, limit credentials to the minimum required, and block prohibited actions deterministically rather than relying on the agent to remember a rule. Microsoft’s guidance emphasizes least privilege and least action, alongside deterministic controls for actions that must not occur: Microsoft agent security guidance.
Use a sandbox, but do not mistake isolation for correctness
A sandbox can limit where commands run and what they can reach. It reduces exposure if an agent runs an unsafe command, but it does not establish that the resulting code meets requirements, passes meaningful tests, or is secure. Sandboxing is one control among several—not a substitute for review.
Limit execution to the project workspace, restrict network access where practical, and avoid giving the agent credentials it does not need. Review the tools, extensions, dependencies, and connected services available to it: those components can introduce their own security risks. Visual Studio Code’s sandboxing guidance describes sandboxing as an additional protection and explains that isolation can be weakened by configuration. Keep code review and testing as separate safeguards.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsRequire evidence before a change advances
Before a proposed repair is merged or deployed, the reviewer should be able to understand what changed and why. At minimum, retain a record of the task request, files changed, commands run, test results, approvals, and final disposition. Give each AI-assisted change a named human owner who is accountable for deciding whether the evidence is sufficient.
- Check that the patch addresses the stated defect rather than an inferred, broader objective.
- Review the diff for unrelated edits, unsafe behavior, and changes to security-sensitive code.
- Run relevant tests and inspect their results; a passing test suite does not prove the repair is correct.
- Confirm that required human approval occurred before merge and before production deployment.
- Preserve an audit trail that makes the decision and subsequent recovery possible to trace.
OWASP’s guidance for LLM applications supports human ownership, approval before merge, and audit trails. The UK Home Office engineering standard states that AI-assisted outputs must be reviewed and approved by a human before reaching production, and that AI-assisted code must meet the same security expectations as human-written code: UK Home Office AI-assisted engineering standard.
Account for prompt injection and automated review limits
Agents may encounter untrusted instructions in code, documentation, issues, or other inputs. Keep those sources inside the correct trust boundary, restrict the actions available to the agent, and require review when a change crosses into a more consequential stage. Also audit the dependencies, extensions, agent tools, and connected services that can affect the work.
Rank #4
Automated review can help decide when to escalate an action for human approval, but it cannot serve as a complete safety net. OpenAI’s 2026 account of its internal Codex deployment says Auto-review caused sessions to stop for human approval “roughly 200x less often” than manual approval; the report also says around 99% of the small fraction of actions it reviewed were approved. Those are vendor-reported internal figures, not an independent benchmark of repair accuracy or a general measure of safety. The same account describes a snapshot of 720 out-of-sandbox actions, of which seven were rejected: four continued through a safer route and three stopped for user input. OpenAI’s report on Auto-review also cautions that the mechanism does not address every in-boundary or concealed behavior.
A practical policy for teams
- Scope the task: Define the intended outcome, permitted files and tools, and any actions that are off limits.
- Constrain execution: Use a scoped workspace, minimum necessary credentials, and limited network access.
- Allow bounded self-correction: Let the agent edit and test within those boundaries; do not treat successful tool use as proof of a correct repair.
- Escalate by consequence: Require explicit human approval for sensitive changes and for actions such as merge, deployment, or infrastructure modification.
- Review and record: Assign a human owner, inspect the change and test evidence, and preserve the relevant audit trail.
- Recover deliberately: Keep the ability to interrupt the agent and revert or otherwise contain a change if review or monitoring reveals a problem.
There is no evidence-based universal number of approvals or autonomy level that fits every team. Calibrate the policy to the system’s privileges, the change’s impact, the quality of available tests, and how reliably the team can detect and reverse a bad outcome.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
