cybersecurity

How security engineering is shifting from human vigilance to automated defenses

Security is no longer just about training humans to spot threats.

3 min readInfoQ
How security engineering is shifting from human vigilance to automated defenses

The most honest thing you can say about security engineering is that we have been asking the wrong people to do the heavy lifting. For years, the burden of defense has fallen on humans: the overworked engineer patching a dependency, the analyst triaging alerts, the user who must remember not to click the phish. The conversation at QCon London 2026, captured by Chris Swan, points to a more mature direction: shifting that burden from human vigilance to automated, system-level defenses built into the entire application stack. This is not a convenience play. It is the only realistic path forward when the attack surface grows faster than any security team can hire.

The shift is already visible in how the industry is hardening the foundations. Consider Apple tightens macOS data access as AI agents reshape security risks, where the company is moving to constrain Full Disk Access permissions precisely because AI agents are becoming common actors on the desktop. That is a quiet admission that the perimeter is gone and the endpoint is now a vector for autonomous processes, not just human error. Similarly, Cloudflare Builds a Quantum-Safe Path for the Future of Internet Security shows that even encryption is no longer a static property but a moving target that must be automated and updated before the threat arrives. These are not isolated features; they are early signals of a stack that assumes compromise and enforces policy at the machine level, not the human level.

For the reader building or buying software today, the takeaway is direct: stop designing for a user who will make the right choice under pressure. That user does not exist. The practical consequence is that security must be a default property of the platform, not a feature request. When a permission model changes automatically based on the behavior of an AI agent, or when cryptographic agility is built in from day one, you are no longer asking whether someone will slip up. You are asking whether the system can contain the blast radius on its own. That is a fundamentally different question, and it changes how you evaluate every tool, vendor, and architecture decision you make.

The open question that lingers is accountability. If automated defenses make the call to quarantine a process or revoke a credential, who is responsible when the system is wrong? Swan's framing suggests we are moving toward a world where the machine is the first responder, but that does not remove the need for human judgment; it relocates it to the design phase. The teams that succeed will be those that treat automation not as a replacement for security engineers but as a force multiplier that frees them to focus on the threats that actually require reasoning. Watch for the moment when your own incident response runbooks start to feel like legacy code. That is the sign the shift has reached you.

From InfoQ

In this episode, Chris Swan, engineer at Atsign and security track host at QCon London, reflects on the ideas shared during QCon London 2026 and teases topics of the future edition. The discussion explores how security engineering is shifting from relying on human vigilance toward automated, system-level defences across the entire application stack.

Read the original at InfoQ