Survivability Engineering, Part 3: AI and the New Tech
Mar 2026
AI can bypass traditional security controls with a single prompt injection attack, or by a human feeding it the right information. Honestly, trying to account for every possible prompt injection path with guardrails is fundamentally impossible. Too many variables, too many options.
The issue is not the technology itself, but the assumption that it can be controlled the same way as deterministic systems. AI agents do not behave like predictable software. They respond to input, context, and influence in ways that shift over time. Treating them like static assets to lock down and govern creates gaps you will not see until something breaks.
I'm not saying AI agents cannot be used securely. I'm saying we think about securing them the wrong way. Treating an AI agent like another application, another endpoint, another system to harden and monitor with the same controls leads to a false sense of security. We have seen this play the same way before. As security professionals we have always dealt with non deterministic actors... Humans. Humans 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 are not just a new attack surface, they are a new kind of participant in the environment. Part human weakness, part machine capability. They can be influenced, manipulated, and redirected in ways that look less like exploitation of software and more like social engineering. That changes the game. You are not securing code alone. You are managing behavior.
This is where survivability engineering matters. You are not going to prevent every prompt injection, or perfectly constrain a system that is designed to be flexible and adaptive. The goal shifts. As we saw in Part 2, if it does not reduce risk, it is attack surface. Every integration, every permission, every workflow an agent can touch needs to be evaluated through that lens.
Susceptibility changes with AI. Exposure increases because agents are designed to interact with more systems and more data. The question becomes how easily can an agent be influenced to do the wrong thing. Not if, but how often and under what conditions.
Damage becomes the central concern. What can the agent actually do when it is influenced. Can it access sensitive data. Can it execute actions across systems. Can it trigger downstream processes without human review. This is where blast radius lives. If an agent is compromised in behavior, how far does that impact spread.
Recovery time is where we seem to be less prepared. When an agent goes off track, how quickly can you detect it, stop it, and restore normal operation. Logging is not enough. After the fact analysis does not shorten disruption. You need visibility and control while it is happening.
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 do not answer that. You have to assess risk the same way as before, just applied to a different kind of actor. Start with susceptibility. Where can the agent be influenced. What inputs does it trust. What external data, tools, or users can shape its behavior. Then move to damage. If the agent does the wrong thing, what is it actually allowed to do. What systems can it touch, what data can it access, what actions can it trigger. Then recovery time. How quickly can you see that behavior drift, how quickly can you interrupt it, and how quickly can you return to a known good state.
Framing it this way forces better decisions. Does this integration reduce blast radius or expand it. Does this permission shorten recovery or make it harder to contain. If the answer is no, it is 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 a single agent cannot 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, not just logs after the fact, and look for deviation from expected patterns. Build the ability to pause, revoke access, or kill sessions immediately when something looks wrong. Keep audit trails that show intent and action, not just system events.
Isolation matters. Run agents in constrained environments with clear boundaries on data access and tool usage. Do not allow unrestricted chaining of actions across systems without checkpoints. Introduce friction where the damage would be high. Fast rollback paths matter just as much. Snapshots, state restoration, and the ability to undo actions reduce recovery time when something goes wrong.
These are not new ideas, they are just applied differently. The difference is accepting that failure will happen and designing around it. Controls should 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 before. Stop focusing on preventing every issue. Focus on surviving them. AI makes that shift unavoidable. The systems are too dynamic, the behaviors too unpredictable, and the speed too high.
Security Brutalism applies here more than you think. Strip away controls that do not change susceptibility, damage, or recovery time. Keep what reduces blast radius. Keep what shortens recovery. Remove what adds complexity without changing outcomes.
AI and the modern tech around it are not a special case that breaks security. They expose the weaknesses in how security has been approached. Survivability is how you deal with that reality.
Originally posted on The Security Brutalist blog.