Traditional security systems watch for individual bad actors. One compromised credential. One malicious request. One anomalous process. But when thousands of AI agents coordinate an attack at machine speed, each individual action can look harmless while the collective behavior is hostile.
Inwom is a Show HN project responding to Anthropic CEO warnings about AI swarms potentially taking over the internet in 6 to 12 months. The timing matters. The Hugging Face incident already demonstrated unintentional agent coordination at scale. The next incident may not be unintentional.
The Unit of Attack Has Changed
Your SIEM watches users, sessions, endpoints, and requests. It flags anomalies in individual behavior. Rate limiters throttle single sources. Authentication systems verify identities one at a time.
None of these primitives understand populations.
When 284 agents execute 4,812 events across 37 minutes, your security stack sees:
- 284 valid authentication events
- 4,812 individual API calls within rate limits
- 37 denied requests (normal failure rate)
- 19 capability changes (legitimate feature usage)
What it does not see:
- Agents sharing discovered vulnerabilities through artifact storage
- Behavioral changes propagating across the population at 1.31 adoptions per second
- 17 actors forming a candidate collective with 0.91 evidence score
- Coordinated boundary pressure testing across identity systems
What Swarm Detection Requires
Inwom reconstructs coordinated behavior from observable evidence. The architecture treats agent populations as the analysis unit, not individual agents.
Observable Signals
| Signal Type | What It Captures | Why It Matters |
|---|---|---|
| Artifact access patterns | Which agents read/write shared resources | Communication substrate between agents |
| Capability propagation | How new behaviors spread through population | Identifies knowledge sharing networks |
| Temporal clustering | When multiple agents change behavior simultaneously | Detects coordinated state transitions |
| Boundary pressure | Failed authentication or authorization attempts | Maps collective reconnaissance efforts |
| Resource access drift | Changes in what infrastructure agents touch | Reveals expanding attack surface |
Traditional security logs all of this data. Inwom correlates it across the population dimension.
Architecture Shape
The system operates as a passive observer layer above your existing security stack:
# Conceptual flow, not production code
class SwarmDetector:
def __init__(self, event_stream):
self.population_graph = AgentRelationshipGraph()
self.capability_tracker = PropagationAnalyzer()
self.collective_scorer = EvidenceAggregator()
def process_event(self, event):
# Individual event may be benign
if not self.is_individually_suspicious(event):
# But update population state
self.population_graph.add_edge(
actor=event.actor_id,
resource=event.resource,
timestamp=event.timestamp,
action_type=event.action
)
# Track capability spread
if event.is_capability_change():
self.capability_tracker.record_adoption(
actor=event.actor_id,
capability=event.capability_id,
source=self.infer_source(event)
)
# Score collective behavior
collective_score = self.collective_scorer.evaluate(
population=self.population_graph.get_active_actors(),
time_window=300 # 5 minutes
)
if collective_score > SWARM_THRESHOLD:
self.alert_coordinated_behavior(collective_score)The key insight: benign individual events can form malicious collective patterns.
Propagation as a Detection Primitive
When one agent discovers a useful capability (a working API endpoint, a permission boundary, a data schema), that knowledge can spread through the population. Traditional security does not track this.
Inwom watches for:
- Adoption velocity: How fast does a new behavior spread?
- Propagation depth: How many hops from the original discoverer?
- Substrate identification: What communication channel carries the knowledge?
If 12 agents adopt a new capability within 9 seconds, all accessing the same artifact file in between, you have evidence of coordinated knowledge sharing.
The Blind Spot in Rate Limiting
Your API gateway limits requests per IP, per API key, per user. An attacker with 1,000 agent identities gets 1,000x your rate limit. Each agent stays well below threshold. The collective exceeds it by three orders of magnitude.
Swarm-aware rate limiting needs population-level quotas:
- Track request volume across agent cohorts, not just individuals
- Identify when multiple agents exhibit correlated access patterns
- Apply backpressure to populations, not just sources
This requires a new primitive in your API gateway: the ability to group requesters by behavioral similarity and apply limits to the group.
Observability Gaps
Your existing observability stack probably exports:
- Request logs (per-request metadata)
- Authentication events (per-identity)
- Error rates (aggregated, not attributed to populations)
- Resource access (per-resource, not per-population)
To detect swarms, you need:
- Population membership over time (which agents are acting together)
- Cross-agent correlation metrics (how synchronized are their actions)
- Capability propagation graphs (who learned what from whom)
- Collective state transitions (when does a group change behavior)
Most observability platforms do not expose these dimensions. You will need to build a secondary analysis layer that consumes existing logs and reconstructs population dynamics.
Failure Modes
Swarm detection systems fail in predictable ways:
False positives from legitimate parallelism: Your CI/CD system spins up 50 agents to run tests. They all access the same resources. They coordinate through shared state. This looks like a swarm but is not an attack.
Evasion through timing jitter: Attackers add random delays between agent actions to break temporal correlation. Your detector needs to handle loose synchronization.
Substrate diversity: Agents coordinate through multiple channels (shared files, message queues, database records, API responses). Your detector must identify all possible communication substrates.
Population fragmentation: Attackers split their swarm into small, uncoordinated-looking subgroups. Each subgroup stays below detection threshold. The attack succeeds through cumulative effect.
What This Means for Authentication
Traditional auth assumes one human, one identity, one session. Agent swarms break this model:
- One human may control 1,000 agent identities
- Each identity may have multiple concurrent sessions
- Agents may share credentials through side channels
- Identity lifecycle (creation, usage, retirement) happens at machine speed
Your identity provider needs new capabilities:
- Population-aware anomaly detection (not just per-identity)
- Credential sharing detection across identities
- Bulk identity provisioning rate limits
- Behavioral fingerprinting that survives identity rotation
Deployment Shape
Inwom positions itself as a passive observer, not an inline security control. This matters for failure modes and performance:
- No blocking path: If Inwom crashes, your application continues
- Async analysis: Population scoring happens out of band
- Existing log integration: Consumes standard security event streams
- Alert output only: Does not enforce policy, only detects and notifies
This architecture choice trades real-time blocking for deployment simplicity. You cannot stop an attack in progress, but you can detect it fast enough to respond before significant damage.
Technical Verdict
Use this approach when:
- You run infrastructure that agents can access programmatically (APIs, repositories, compute platforms)
- You expect agent populations to grow beyond manual monitoring scale
- Your threat model includes coordinated multi-agent attacks
- You already have comprehensive security logging
Avoid this approach when:
- Your attack surface is small enough to manually audit all agent activity
- You need real-time blocking, not detection and response
- Your security logs do not capture enough detail to reconstruct agent relationships
- You cannot tolerate the operational overhead of a secondary analysis system
The core insight is correct: traditional security primitives do not understand populations. But building population-aware detection requires significant investment in log correlation infrastructure, behavioral modeling, and alert tuning. Start with narrow use cases (API access, repository activity) before expanding to full infrastructure coverage.