Should organisations let agents propose fixes before humans approve them?

Why letting agents propose fixes can work

An agent can be useful at the proposal stage because it compresses the tedious part of remediation: finding the likely root cause, drafting the change, and showing the affected resource or policy path. That is especially valuable when the issue is in infrastructure-as-code, cloud configuration, or repeatable operational hygiene, where the human reviewer can judge the change faster than they can assemble it from scratch.

The key boundary is authority. Proposal is not approval, and the more a fix can change access, routing, deployment state, or production cloud posture, the more the human needs to validate intent, blast radius, and rollback before anything is applied.

Where the boundary should sit between proposal and execution

Good proposal workflows separate three things: diagnosis, proposed remediation, and execution. The agent can help with the first two by surfacing the finding, suggesting the delta, and explaining why the change appears safe. The human should own the final decision whenever the fix could touch production, alter privileged access, or affect shared infrastructure where a bad edit can create outsized impact.

This boundary is easiest to enforce when the proposal is specific enough to review line by line. A vague recommendation like "tighten permissions" is hard to approve safely. A concrete patch, such as a resource block, policy statement, or parameter change, gives the reviewer something they can compare against the finding and the intended control outcome.

Agent proposal also works best when the organisation treats it as an advisory control, not a shortcut around review. If teams start accepting agent output as if it were a completed change request, the workflow loses the very safeguard that makes it valuable.

Why human approval still matters for cloud accounts and IaC workflows

Cloud accounts and IaC pipelines magnify small mistakes. A fix that looks narrow in a prompt can have broad effect if it is applied to the wrong account, region, environment, or module version. That is why the review step should verify the target, the scope, the dependencies, and the rollback path before the change is merged or deployed.

When agents draft changes for IaC, the review should focus on whether the proposed diff matches the finding, whether it preserves environment separation, and whether it introduces hidden coupling such as reused variables, shared modules, or implicit defaults. In cloud operations, the same review must ask whether the fix changes standing access, widens trust between services, or affects production resources that should be protected by stricter change control.

A useful practical rule is that the more the fix resembles a security control or privilege change, the more it deserves a human gate. If the proposal touches a production account, a deployment role, or a policy that governs other workloads, the reviewer should treat it as a high-consequence change even if the agent generated it correctly.

How to make proposal workflows safe enough to use

The safest design is to let the agent prepare a patch and an explanation, then force the human reviewer to confirm the intended resource, the expected outcome, and the rollback option before approval. That keeps the agent in an assistant role while preserving accountable decision-making where the organisation actually bears the risk.

What to verify: Require the proposal to name the exact asset, the exact change, and the exact reason the finding maps to that change. If the agent cannot show those three items clearly, the proposal is not ready for human approval.

Decision rule: If the proposed fix changes production access, platform policy, or IaC that can affect multiple environments, make human approval mandatory; if it is a low-risk, reversible non-production edit, the review can be faster but should still be explicit.

Common mistake: Teams often trust a well-written agent explanation and forget to inspect the actual diff. That is backwards. The diff is the control, and the explanation is only support for the review.

Risk and Threat Considerations

Agent-generated fixes can fail in predictable ways, especially when the system is allowed to infer too much from partial context. A seemingly reasonable patch can overcorrect, change the wrong environment, or introduce a new exposure while trying to remove an old one. The risk increases when the agent has access to live configuration, deployment tooling, or broad write permissions.

Failure mechanism: The agent proposes a change that is syntactically valid but semantically wrong, for example by widening scope, breaking isolation, or altering a production control without understanding the full dependency set. If humans approve without checking the exact target and blast radius, the workflow turns a remediation aid into an operational hazard.

Impact: The result can be accidental privilege expansion, service disruption, or the deployment of a control that looks compliant but leaves the underlying issue unresolved. In the worst case, the approval process becomes a rubber stamp for changes that should have been independently reviewed.

Practitioner Guidance

What to prioritise: Keep the agent focused on drafting, explanation, and evidence gathering, then require a human to approve any change that can affect production state, access, or shared infrastructure. That gives you speed without surrendering control.

What good looks like: The reviewer can trace the proposed fix from finding to resource to intended effect in one pass, and can reject or amend it without needing to reconstruct the change from scratch. If the human cannot do that, the proposal is too vague to trust.

Practitioner takeaway: Let agents reduce the cost of remediation, not the accountability for it; the approval step matters most exactly where the change is easiest to apply at scale.

Related resources from NHI Mgmt Group

• Should organisations keep humans in the pentesting loop even when agents outperform them on some tasks?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How should organizations approach the governance of AI agents?