Survivability Engineering, Part 3: AI and the New Tech
Mar 2026
AI can bypass traditional security controls through a single prompt injection, or simply because a human feeds it the right information. Trying to account for every possible injection path with guardrails is fundamentally impossible. There are too many variables and too many options.
The issue isn't the technology itself, but the assumption that AI can be controlled the same way as deterministic systems. AI agents don't behave like predictable software. They respond to input, context, and influence in ways that shift over time, and treating them like static assets to lock down and govern creates gaps you won't see until something breaks.
None of this means AI agents can't be used securely. It means we're thinking about securing them the wrong way. Treating an agent like another application or endpoint, something to harden and monitor with the same old controls, produces a false sense of security. We've dealt with non deterministic actors before: humans. People click links, ignore policy, and find the fastest path to get their work done. Agents behave the same way, except they operate at machine speed and scale.
AI agents aren't just a new attack surface, they're a new kind of participant in the environment, part human weakness and part machine capability. They can be influenced, manipulated, and redirected in ways that look less like exploiting software and more like social engineering, which changes the game entirely. You're not securing code alone anymore. You're managing behavior.
This is where survivability engineering becomes useful. You won't prevent every prompt injection, and you can't perfectly constrain a system built to be flexible and adaptive, so the goal shifts. As covered in Part 2, if something doesn't reduce risk, it's attack surface, and every integration, every permission, every workflow an agent can touch deserves evaluation through that lens.
Susceptibility changes with AI, since exposure grows as agents interact with more systems and more data. The real question becomes how easily an agent can be influenced to do the wrong thing, not whether that's possible but how often it happens and under what conditions. Damage becomes the central concern. What can the agent actually do once influenced? Can it access sensitive data, execute actions across systems, or trigger downstream processes without human review? This is where blast radius lives, and if an agent's behavior gets compromised, the impact can spread far beyond where it started. Recovery time is where most teams are least prepared. When an agent goes off track, how quickly can you detect it, stop it, and restore normal operation? Logging alone isn't enough, and after the fact analysis doesn't shorten disruption. You need visibility and control while the problem is unfolding.
Ask the same question every time: when something goes wrong, how bad does it get and how long does it last?
Guardrails and policies alone won't answer that. You have to assess risk the same way as before, just applied to a different kind of actor. Start with susceptibility, looking at where the agent can be influenced, what inputs it trusts, and what external data, tools, or users can shape its behavior. Move to damage next, examining what the agent is actually allowed to do if it goes wrong, which systems it can touch, what data it can reach, and what actions it can trigger. Then look at recovery time, asking how quickly you can spot behavior drift, interrupt it, and return to a known good state.
Framing it this way forces better decisions. Does this integration shrink blast radius or expand it? Does this permission shorten recovery or make it harder to contain? If the answer is no, it's attack surface.
Treat the agent like a human operator with high speed and no judgment. Give it least privilege access, scoped to specific tasks and time bound where possible. Separate duties so no single agent can complete high impact workflows end to end. Require approvals or secondary validation for sensitive actions. Limit what it can reach across environments and keep boundaries tight between systems. Monitor behavior in real time rather than relying only on after the fact logs, watching for deviation from expected patterns. Build the ability to pause, revoke access, or kill sessions immediately when something looks wrong, and keep audit trails that show intent and action, not just system events.
Isolation is important. Run agents in constrained environments with clear boundaries on data access and tool usage, and avoid unrestricted chaining of actions across systems without checkpoints. Introduce friction wherever the potential damage runs high. Fast rollback paths carry equal importance, since snapshots, state restoration, and the ability to undo actions all reduce recovery time when something goes wrong.
None of this is new, it's just applied differently. The real shift is accepting that failure will happen and designing around it, with controls that assume the agent will be influenced at some point and focus on limiting what happens next and how fast you can recover.
This is the same shift discussed throughout this series. Stop focusing on preventing every issue, and focus on surviving them. AI makes that shift unavoidable, since the systems are too dynamic, the behaviors too unpredictable, and the speed too high. Security Brutalism applies here more than you'd expect. Strip away controls that don't change susceptibility, damage, or recovery time. Keep whatever shrinks blast radius. Keep whatever shortens recovery. Remove whatever adds complexity without changing outcomes.
AI and the modern tech around it aren't a special case that breaks security. They expose the weaknesses in how security has been approached all along. Survivability is how you deal with that reality.
Originally posted on The Security Brutalist blog.