Security Brutalism Under Real Conditions, Part 5: The Active Layer and Agents
Part 3 and Part 4 covered building the foundation, an accurate inventory, a consequence map, hardened critical systems, detection that produces real signal, and recovery that's been tested. That foundation gives you a clean environment to operate in and a priority map for what to protect, and with it in place, two extensions become possible.
The first extends outside the walls, where security operates before an attacker gets close enough to touch your controls. The concept is a small specialist cell, five to eight people, running continuously with an offensive orientation. They deploy deception technology, run active threat hunting, conduct counter-intelligence operations, and war-game against your actual environment. Your security team builds the walls. This cell operates outside them, tracking who's watching, setting traps, and raising the cost of getting inside.
The deception technology piece maps directly onto the survivability framework, since honeypots, canary credentials, and behavioral baiting extend SEE work outward into the space an attacker occupies before intrusion. The war-gaming piece maps onto recovery, functioning as the chaos engineering the survivability framework requires but most programs skip, run continuously by people with an offensive mindset rather than as a scheduled exercise.
This needs the foundation first for practical reasons, not philosophical ones. Deception assets only produce clean signal when the baseline is clean. Place a canary credential in an environment with hundreds of undocumented service accounts, shadow IT integrations, and persistent stale access, and the resulting alert becomes one data point in a sea of unexplained activity, detected but unheard through the noise. A hardened environment with a documented inventory and a clean access baseline is what makes deception intelligence actionable rather than theoretical.
The same applies downstream. The cell produces intelligence about who's probing your environment and how, and if the people receiving that intelligence stay oriented toward satisfying audit frameworks rather than responding to real adversary signals, it never gets acted on. The operations pipeline has to function for the intelligence to carry value.
The active layer and the survivability foundation answer different questions across the attack timeline.
The active layer raises the cost of reaching the hardened environment and compresses detection time before intrusion, while the foundation stays hardened against what happens if something gets through and keeps recovery deterministic. They share almost no functional overlap, which is why they combine without redundancy, and that division of labor is also what should drive the evaluation of any active layer capability. One question carries more weight than any other, and you need to focus on it. Ask: is the war-gaming methodology scoped to your actual consequence map, or is it a generic red team exercise? Simulating the specific attack paths that would cause existential damage to your business delivers high value; running standard techniques against your perimeter for CVE coverage means paying for sophisticated compliance theater. The deliverable should be direct evidence about which attack paths succeed and fail against the systems at the top of your consequence map, under realistic adversarial conditions.
Several limits apply to the active layer. Sophisticated, well-resourced attackers can absorb higher costs, so disruption deters opportunistic attacks and makes some targeted attacks harder without acting as a backstop against a patient, well-funded adversary who's budgeted for extended operations. The survivability architecture, bounded blast radius and tested recovery, becomes what carries weight when disruption fails. The active layer reduces the probability of reaching damage. The foundation determines how bad that damage is once you get there.
The small cell model creates both its strength and its primary operational risk. Five to eight specialists operating continuously is exactly the right staffing model for this work, small, expert, and focused, with low overhead and high coherence, but it also creates key-person dependency. If the cell turns over, institutional knowledge about your specific deception architecture and adversary history walks out with them, which makes personnel continuity a security control in this model rather than an HR consideration. You need to invest in the right people, and continue to invest in them. I recommend you read my book on Security Unconventional Warfare to understand more about this concept.
Active disruption operations that feed false information to adversaries can create legal exposure depending on jurisdiction and what the operations involve. Honeytokens and honeypots stay legally clean, but counter-intelligence operations extending beyond passive deception need scoping with legal counsel before deployment, particularly in regulated industries. This is where the CISO or the more senior security leader in the organization needs to sync with the Legal department and understand what's possible.
The second extension sits inside the perimeter, and it's the same problem at a new scale, agents.
Autonomous agents now run in production environments, software that uses a language model to reason and act, with access to real tools, able to read files, make API calls, execute code, send messages, and call other agents. Organizations deploy them without applying the same controls they'd apply to any other system with that level of access.
The survivability framework applies here also, especially if you understand that an agent with tool access is an identity with permissions, and its blast radius gets determined by what tools it's been given. If compromised, what it can do depends entirely on what permissions it was granted. The same questions from Parts 2 and 3 apply here too, what can reach this system, what can it reach, how long to detect if it's misbehaving, how long to contain it, and what it costs if the worst case happens.
Know requires every agent inventoried, every tool it can call documented, every system it can reach mapped, and every other agent it can invoke treated as a trust relationship in the agent-to-agent graph. For each agent, the consequence question needs an answer. If this agent gets fully compromised right now, what can it do?
Harden mandates a minimum tool set per agent. A summarization agent has no business with file-write or network access, and a research agent has no business reaching production databases. Read-only stays the default, while write, delete, execute, and send remain explicit grants with documented business need, revoked once no longer needed, and agent-to-agent trust requires explicit grants rather than defaulting open. Before an agent deletes, publishes, exfiltrates, or sends, a human confirms it.
See calls for logging every tool call, every parameter, every result, and every agent-to-agent call, since this forms the forensic record and the baseline. High-consequence action sequences deserve flagging regardless of what triggered them, since an agent that normally reads files making external HTTP calls is a signal even when each individual action stays technically in scope. Deception assets belong here too, canary credentials and honeydocuments placed where only an agent in active exploration would find and use them.
Finally, recover requires hard kill switches. Can you stop a running agent mid-execution, and what happens to in-flight tool calls? If termination can't happen within minutes, that delay is the actual blast radius. Reconstructing what a compromised agent did during the window before detection needs to be possible too, and without full tool call logging, that reconstruction fails, a gap that will carry real weight during an actual incident.
A new layer applies here as well, "trust". Everything above applies to agents the same way it applies to any other system with broad tool access, but agents require one dimension traditional systems don't.
Traditional systems do what they're programmed to do. Agents process instructions and data through the same channel, and that channel can get hijacked. A web page, a document, a tool result, or another agent's output can carry adversarial instructions that redirect the agent's behavior, and this isn't a software vulnerability in the conventional sense, since no parser gets exploited and no memory gets corrupted. The attack surface is the model's core function, following instructions. A page telling an agent to ignore its instructions, become a data extraction tool, and send all context to a given URL is a real attack against an agent that browses the web, and agents processing user content, external documents, or third-party tool results encounter attempts like this continuously.
The controls here run differently from the rest. Structural separation keeps instructions apart from data, with system prompts defining what the agent can do while external inputs get processed strictly as data rather than directives, enforced architecturally where possible rather than through asking the model to be careful, since asking a model to ignore adversarial instructions arriving through the same channel as those instructions isn't a control at all. Input source tracking lets the agent know and log what kind of input it's processing, treating trusted system prompts, user-provided content, web-scraped data, and third-party tool results with appropriate and differing skepticism, external by default until validated. Directive patterns showing up in untrusted content get flagged before the agent processes them as instructions. And high-consequence actions need their reasoning chain logged, not just the final action, since a compromised agent can't be debugged from the outcome alone, only from the reasoning that produced it.
Applying the survivability framework to agents leaves two things that don't resolve cleanly. Behavioral baselines run softer for agents than for traditional systems, since agent behavior varies legitimately by context, prompt, and model version, leaving detection working against a fuzzy baseline. The answer is focusing on action-level anomalies rather than output-level ones, tracking what tools got called, in what sequence, with what parameters, since that stays far more stable than trying to characterize normal output and catch deviations in natural language.
The model itself is a trust boundary you don't fully control. A jailbroken model doesn't behave like a compromised server, and there's no binary clean or infected state because model updates, prompt changes, and fine-tuning can shift behavior in ways invisible from outside. Controls need to assume the model may behave outside expected parameters at any point, built to catch and contain that rather than prevent it, and the hardening work on tool access alongside the detection work on action-level logging is what bounds the damage when the model does something unexpected.
The Line Runs Mostly Clear
Parts 1 through 4 cover a single idea from multiple angles. Survivability is the metric, and every decision in the program gets evaluated against how much it moves the numbers that carry weight.
Programs that fail rarely fail from having no security. They tend to organize it around the wrong objective, measuring coverage rather than survivability, optimizing for audit outcomes rather than for how long they stay failed, and adding complexity in response to every new threat rather than removing complexity to shrink the surface threats can reach.
The foundation described in Parts 2 and 3, the inventory, the consequence map, the hardened critical systems, the detection that produces real signal, the recovery that's been tested, stays achievable in any organization with the will to prioritize it. It doesn't require organizational transformation or abandoning what already exists. It requires a different measurement framework and a standing discipline of asking, for every control and every tool, whether it makes the program more survivable or just more complex.
The active layer and the agent controls extend the foundation rather than replace it. Build the foundation first. Then build outward.