This article follows Evolutionary Software: When Selection Becomes the Bottleneck. The first article argues that cheap software variation and increasingly automated selection will give software development stronger evolutionary dynamics.

Security inherits the same dynamics.

A malicious agent that is easy to detect has poor fitness. A variant that evades a detector survives longer. Once attacks can be generated, tested against defenses and mutated automatically, defensive evasion becomes an optimization target.

This is already observable in narrower agent-security settings. A 2025 NAACL paper evaluated eight defenses against indirect prompt injection and bypassed every one of them with adaptive attacks, consistently reaching attack-success rates above 50%. [1]

Static defenses are therefore not enough. But the race is not necessarily lost.

The defender can define the playing field

Attack and defense are asymmetric. In conventional cybersecurity this asymmetry often favors attackers: the defender has to protect many paths while an attacker needs to find only one useful mistake.

Agent systems give defenders an opportunity to create a different asymmetry because legitimate agents run on infrastructure we control.

We decide which capabilities exist. We can mediate credentials. We can sandbox processes, constrain tools, record provenance, rate-limit APIs, separate networks, randomize environments and withhold information. The attacker has to operate inside—or somehow escape—the world we construct.

A defensive agent controls CPU, network, tools and credentials while hostile agents are constrained by the environment.
The defender can shape the environment: resource limits, capabilities, sandboxes and deception all impose costs on an attacker.

The attacker has a metabolism

Malicious activity requires resources. An agent needs some mixture of CPU or GPU time, memory, storage, network traffic, API calls, credentials, persistence and coordination with other systems.

Those resources create a dilemma:

more activity
    → more capability
    → more observable footprint

less activity
    → less observable footprint
    → less speed, reach and capability

Attackers can stay “low and slow,” but stealth itself becomes a tax.

Biology offers an analogue. In nutritional immunity, hosts restrict access to resources such as iron and zinc that pathogens need to proliferate. Pathogens evolve mechanisms to recover those resources; hosts evolve mechanisms to withhold them. [2]

A digital equivalent might deliberately make compute, bandwidth, credentials, persistence and tool capabilities abundant for authenticated, well-understood activity but scarce for unknown or increasingly suspicious activity.

This gives the defense two benefits at once:

  • Detection: abnormal resource use can expose an attacker.
  • Containment: staying below detection thresholds inherently limits how quickly an attacker can scan, propagate, coordinate or exfiltrate.

Perfect detection may therefore be the wrong goal. A more achievable objective is to make undetected attacks slow and local enough that the rest of the immune ecosystem has time to react.

malicious activity Needs resources to act compute · network · tools · storage
go fast Large footprint more capability easier to detect → contain
Either way, the defender extracts an advantage.
Stealth is not free: forcing an attacker under observable thresholds can also constrain its speed and scale.

Progressive restriction instead of binary judgment

An immune defense also does not need to classify everything immediately as GOOD or MALICIOUS.

normal operation
    ↓
weak anomaly
    ↓
reduce network budget
    ↓
restrict sensitive tools
    ↓
move execution into a stronger sandbox
    ↓
introduce decoys and canaries
    ↓
isolate if evidence accumulates

This has two useful properties. False positives become less destructive: a legitimate process can become slower or more constrained instead of being immediately killed. And each restriction becomes an experiment. How the agent reacts to lost capabilities can itself provide evidence.

Defenders can also introduce resources that legitimate software has little reason to touch: decoy credentials, canary documents, synthetic endpoints or fake peers. An attacker looking for new paths may reveal itself by interacting with them.

Resource budgets are not capability budgets

Resource asymmetry has a limit. Some of the most damaging actions are tiny.

One API call can transfer money. One configuration change can disable a safeguard. One carefully chosen line can compromise a software update.

So we need both:

resource budget   = how much can this agent do?
capability budget = what can this agent do at all?

A suspicious agent with 1% CPU is still dangerous if it holds a credential that can erase production data.

There is another complication: malicious agents can make trusted systems do their work. Viruses do something conceptually similar by using host-cell machinery. Digital defenses therefore need causal provenance, not just per-process accounting. The interesting question is not only “which process used the CPU?” but “which untrusted information or actor caused this chain of actions?”

An immune ecosystem, not a global immune system

Fast worldwide sharing is important. If one system discovers a new attack pattern, other systems should benefit quickly.

But identical defenses would share a common failure mode.

Biological populations provide a useful lesson. Major histocompatibility complex (MHC) genes are highly polymorphic. Different individuals recognize different sets of pathogen peptides, making it harder for one pathogen variant to evade an entire population. Immunology texts note that population-level MHC diversity makes it unlikely that all individuals will be equally susceptible to the same pathogen. [3]

The digital equivalent should be:

Global immune intelligence, but not a global immune implementation.

Different organizations and machines should be able to use different models, prompts, sandbox designs, capability systems, operating systems, update schedules, detectors and security architectures.

Security through deliberate software diversity is not new. N-Variant Systems, for example, execute diversified variants and look for behavioral divergence, forcing an attacker to compromise multiple disjoint variants with the same input. [4]

AI may make this more practical. Maintaining ten independent implementations has always been expensive. Where software generation is cheap, intentional diversity could become an ordinary security property.

Different local immune systems sharing threat intelligence while retaining different structures and failure modes.
Global knowledge should spread quickly, while local implementations remain diverse enough to avoid a single common failure mode.

Share antibodies globally; activate them locally

We use “antibody” loosely here. A digital antibody should probably not be a globally distributed executable patch or a decree that every machine must obey.

It may instead be a compact description of evidence:

  • a behavioral signature,
  • an attack trace,
  • a suspicious causal pattern,
  • a test case that reproduces an exploit,
  • a provenance rule,
  • or a proposed containment strategy.

Threat information can move rapidly while each local immune system independently evaluates it and chooses a response.

Cybersecurity already has partial precedents for this. OASIS TAXII defines a protocol for exchanging cyber-threat information, and CISA's AI Cybersecurity Collaboration Playbook encourages voluntary sharing of AI incidents and vulnerabilities across government, industry and international partners. [5] [6]

The agentic version should go further: distribute enough causal evidence that independent systems can reproduce the concern without requiring one central authority to dictate the response.

shared layer Global threat intelligence observations · traces · test cases · signed evidence
local AModel Apolicy αstrict sandbox
local BModel Bpolicy βbehavior monitor
local CModel Cpolicy γmoving target
local DOpen systempolicy δindependent stack
local outcomesshared memorynew evidence
Diversity is intentional. One exploit, poisoned update or bad defensive rule should not compromise every population at once.
Shared memory does not require shared implementation. Local diversity limits common-mode failure while observations circulate globally.

Disagreement is a security feature

Imagine a malicious agent that learns to exploit the immune system itself. It could attempt to poison shared memory, manufacture false indicators or convince defenses that legitimate software is malicious.

A homogeneous global immune system could turn one successful attack into a worldwide autoimmune response.

A heterogeneous ecosystem creates a different failure mode:

bad defensive signal
    ↓
some populations react
    ↓
others do not
    ↓
the disagreement becomes visible
    ↓
humans and independent agents investigate

Controlled disagreement is therefore valuable, and should not be optimized away.

But diversity alone is not enough. Ten agents produced by the same foundation model may share the same blind spot. Ten implementations derived from the same flawed specification can fail in correlated ways. What matters is not the raw number of defenses but the independence of their failure modes.

Preventing digital autoimmune disease

An immune ecosystem needs safeguards against its own power.

  • Local activation: shared intelligence should normally be evidence, not a remote command.
  • Bounded authority: no defensive agent should be able to disable the world's infrastructure because of one inference.
  • Independent corroboration: consequential responses should require evidence from genuinely independent systems.
  • Staged propagation: new defensive policies should reach heterogeneous subsets before universal deployment.
  • Reversibility: containment should be easy to undo when the immune response is wrong.
  • Provenance: systems need to know where a defensive claim came from and what evidence supports it.

These are not merely reliability mechanisms. They are ways to make the immune system itself a difficult target.

Who should control the immune system?

Probably nobody.

It would be dangerous for the companies building the dominant AI agents to also become the sole authority deciding what agents are malicious and what the world's computers should block. That creates conflicts of interest and, just as importantly, a security monoculture.

But replacing several AI companies with one central governmental or international immune authority would create another enormous single point of failure.

A better arrangement is a pluralistic ecosystem: open-source communities, security companies, operating-system vendors, universities, public institutions, infrastructure operators and users running independent defensive systems that can exchange signed observations through open protocols.

The common layer should be communication and evidence—not universal control.

A useful map from biology

The analogy is not a specification, but it suggests useful questions:

  • Immune cells: specialized agents that monitor, investigate and contain.
  • Immune memory: durable, shareable knowledge from previous attacks.
  • Antibodies: compact recognition or containment patterns.
  • Vaccination: controlled exposure to attacks and adversarial training before real deployment.
  • Nutritional immunity: restricting compute, traffic, credentials and persistence available to suspicious actors.
  • Population diversity: independent defensive architectures and failure modes.
  • Autoimmune disease: defenses misclassifying and attacking legitimate systems.
  • Pathogen evolution: malicious agents adapting to defenses.
  • Immune evolution: defenses adapting in response.

Artificial Immune Systems have been studied in computer security since the 1990s, including anomaly detection, malicious-process detection, intrusion detection and fraud detection. [7] We are not claiming the analogy is new. What is changing is the environment: both attackers and defenders can increasingly be autonomous software agents capable of modifying software and adapting quickly.

The design goal

The goal should not be an omniscient AI that recognizes every malicious agent.

A better goal is a worldwide immune ecosystem that:

  • learns globally but acts locally,
  • shares evidence faster than attacks spread,
  • forces attackers to pay for compute, communication and stealth,
  • uses capability boundaries to make some attacks impossible rather than merely detectable,
  • contains suspicious behavior progressively,
  • maintains genuine implementation diversity,
  • treats disagreement as information,
  • and cannot itself be turned into a mechanism for global compromise.

The world does not need one immune system. It needs an immune ecosystem: connected enough to develop shared memory, diverse enough that no single pathogen, vendor, defensive mistake or malicious update can compromise every system at once.

Sources and further reading

  1. Zhan et al. — Adaptive Attacks Break Defenses Against Indirect Prompt Injection Attacks on LLM Agents
  2. Núñez et al. — Innate Nutritional Immunity
  3. Immunobiology — The major histocompatibility complex and its functions
  4. USENIX — N-Variant Systems: A Secretless Framework for Security through Diversity
  5. OASIS — TAXII Version 2.1
  6. CISA — AI Cybersecurity Collaboration Playbook
  7. Fernandes et al. — Applications of artificial immune systems to computer security: A survey