Insisting on a human in the loop for everything is hurting security’s ability to meet engineering where it’s going.
Why AI-Driven Security Needs a New Approach
Engineering teams are experimenting with agents that can take on whole sequences of work, from investigating a problem to writing a fix and testing it. If security requires a person to approve every step, we are asking those teams to organize their future around our existing process. We should expect them to question that process.
We worry that good security leaders could lose their voice inside their companies, and some could lose their jobs, because they cannot get comfortable with this change. A security team that cannot explain how the company can move forward risks being left out of the decisions about how it will. That would leave the company with less security expertise at precisely the moment it needs more.
We need to get more comfortable trusting AI to do real work inside limits we establish. We can give it room to work through a problem and still put the result through a final review that is 100% human overseen. That is the shift we are asking our community to make: from insisting on a human in every step to putting humans over the loop.
We understand the hesitation. Security leaders have spent their careers cleaning up the consequences of technology deployed before anyone understood its risks. An agent that makes a mistake can repeat it quickly. A demonstration that works once tells us very little about whether a system deserves access to something important. Those are legitimate concerns, and addressing them is our job.
But “someone has to approve everything” cannot be our permanent answer. We need to explain what would make us comfortable delegating the work, then help build those conditions. Otherwise, human review becomes a requirement that survives without anyone having to demonstrate that it is making the company safer.
Consider vulnerability remediation. Security teams have spent years trying to get engineering time to fix the problems we find. An agent that can investigate a vulnerability, attempt a fix, and test the result gives us a chance to get more of that work done. Keeping an exploitable application waiting while people approve routine intermediate steps has a security cost. We should be evaluating that cost alongside the risk of letting the agent proceed.
Start with one application in an isolated, disposable test environment using synthetic data. Engineering and security agree on the problem to solve, the changes the agent is allowed to make, and the evidence a successful fix must produce. Then let the agent work. It can investigate, change the code, run tests, and try again when its first attempt fails. It does not need a person to click “approve” between every one of those steps.
Before the change reaches production, people oversee the final review and own the decision to release it. They evaluate the evidence that the vulnerability was fixed and that expected behavior still works. They examine exceptions and direct additional testing where they see uncertainty. Automated tests and AI assistance can support that review. Human reviewers determine whether the evidence is sufficient and whether to accept the result.
That gives human attention a more useful job. Instead of repeatedly approving an unfinished process, people assess a completed piece of work against standards they helped set. They can reject it, send it back, or require closer inspection. The agent cannot change those standards or approve its own release.
The limits during execution still matter. An agent working on a test application should not have credentials that let it alter production or expose sensitive data. It should leave a reliable record of its actions, and the team needs a way to stop it. Work that requires consequential actions outside the agreed scope must pause for approval. A final review cannot undo damage that has already happened, which is why containment has to be part of the design.
This supervisory approach is already recognized in security guidance. The UK’s National Cyber Security Centre describes monitoring with the ability to intervene as “human-on-the-loop” in its August interim advice on agentic AI. It emphasizes matching controls to the consequences of failure. When we say human over the loop, we are emphasizing people’s responsibility for the process and its results.
We should also be honest about the limits of the approval model we are defending. A record of who clicked does not establish what they understood or whether they meaningfully challenged the recommendation. NIST’s AI Risk Management Framework recognizes that combining human and AI judgment can sometimes amplify bias. Human involvement has to earn its place as a control through what it accomplishes.
For CISOs, this means getting closer to engineering. Sit with the people building these workflows. Use the tools yourself. Agree with the CTO on where agents can operate independently and what the final review needs to establish. Judge the process by the quality of the work and the risk it removes. As experience grows, adjust the boundaries based on evidence, including reducing autonomy when something fails.
Companies have a responsibility here, too. Security teams need time, access, and budget to learn. People building agentic products every day have opportunities that many enterprise practitioners do not. Give security colleagues a place to experiment and a role in designing the workflow. Expect them to adapt, and invest in their ability to do it.
We want security leaders to have more influence over how their companies use AI. That means bringing a credible answer to how this work can happen safely. If our contribution is to insist that every step wait for us, we risk losing the opportunity to shape the steps that matter most. We can delegate the work without delegating the responsibility.
