Production AI systems are no longer single models. They are ensembles of specialized agents that delegate, coordinate, and accumulate capabilities across sessions. Your monitoring stack was not built for this.
A new paper from ArXiv (2608.02518v1) introduces Magnet, a detection approach that tracks capability accumulation across agent conversations. The core problem: an attacker can decompose a harmful goal into innocuous-looking units and execute each in isolated sessions. The agent is stateless between conversations. The attacker is not.
This asymmetry breaks traditional monitoring. Single-turn and multi-turn detection frameworks assume you can inspect a conversation and decide if it is harmful. But when the dangerous artifact is assembled from pieces scattered across dozens of benign sessions, per-conversation inspection fails.
The Plumbing Problem
Most AI observability tools instrument individual model calls or single sessions. They log prompts, responses, tool calls, and maybe some basic metadata. This works when the threat model is a single malicious prompt or a multi-turn jailbreak within one conversation.
It does not work when:
- An attacker uses session 1 to generate a benign code snippet
- Session 2 to retrieve a benign dataset
- Session 3 to combine them into something harmful
Each session looks clean. The aggregate does not.
The infrastructure challenge is not detecting bad prompts. It is correlating capabilities across temporal and session boundaries without storing full execution traces or building a surveillance database.
What Magnet Does
Magnet does not inspect every session. It attracts relevant artifacts out of the haystack. The name is literal: it pulls needles (incriminating capabilities) from benign sessions and aggregates them at a higher-level correlator, typically a user ID.
The key insight: you do not need to store every conversation. You need to track what each conversation produced that could compose into harm.
Magnet defines a capability as an artifact produced at one step of an objective, evidenced by model responses and tool-call results, and composable with capabilities accrued elsewhere.
This shifts the detection problem from “is this session harmful?” to “does this user have a collection of capabilities that, when combined, indicate a harmful trajectory?”
Architecture Implications
To implement cross-session capability tracking, you need three layers:
1. Capability Extraction
This happens at the agent execution layer. After each session, you extract artifacts that could contribute to a harmful goal:
- Code snippets
- Data retrieval results
- Tool-call outputs
- Generated files or credentials
You do not store the full conversation. You store a compact representation of what the session produced.
2. Capability Aggregation
This happens at the user or entity level. You maintain a rolling window of capabilities per correlator (user ID, API key, session cluster).
The aggregation layer needs to:
- Handle sparse, asynchronous updates
- Support temporal decay (old capabilities expire)
- Scale to millions of users without a full trace database
3. Detection Logic
This is where Magnet runs. It evaluates the aggregated capability bundle and decides if the collection indicates a harmful trajectory.
The detection logic does not see individual sessions. It sees a set of capabilities and their temporal relationships.
State Persistence Primitives
The hard part is storing enough state to detect accumulation without building a surveillance database. You need primitives that:
- Compress session outputs into capability fingerprints
- Support efficient lookups by correlator ID
- Allow temporal queries (what capabilities did this user accumulate in the last 7 days?)
- Expire old data automatically
A naive implementation stores every session in a database and runs batch queries. This does not scale and creates privacy risks.
A better approach uses a capability index:
class CapabilityIndex:
def __init__(self, ttl_days=7):
self.store = {} # user_id -> list of (timestamp, capability_hash, metadata)
self.ttl = timedelta(days=ttl_days)
def add_capability(self, user_id, capability):
"""Extract and store a capability fingerprint."""
fingerprint = self._hash_capability(capability)
timestamp = datetime.utcnow()
if user_id not in self.store:
self.store[user_id] = []
self.store[user_id].append((timestamp, fingerprint, capability.metadata))
self._prune_expired(user_id)
def get_capabilities(self, user_id):
"""Retrieve active capabilities for a user."""
self._prune_expired(user_id)
return self.store.get(user_id, [])
def _prune_expired(self, user_id):
"""Remove capabilities older than TTL."""
if user_id not in self.store:
return
cutoff = datetime.utcnow() - self.ttl
self.store[user_id] = [
(ts, fp, meta) for ts, fp, meta in self.store[user_id]
if ts > cutoff
]This is a toy example. Production implementations need distributed storage, efficient indexing, and privacy controls. But the pattern is clear: you store capability fingerprints, not full conversations.
Where Detection Logic Lives
You have three options for where to run Magnet:
| Location | Pros | Cons |
|---|---|---|
| Orchestrator | Direct access to agent state, can block before execution | Tight coupling, hard to retrofit, performance overhead |
| Model Gateway | Centralized choke point, sees all traffic | Limited context on tool calls, misses post-processing |
| Separate Observability Layer | Decoupled, can aggregate from multiple sources | Async detection, cannot block in real-time |
The paper does not specify, but the architecture suggests a separate layer. Magnet needs to see tool-call results and model responses, not just prompts. That means it runs after execution, not before.
This has implications for mitigation. You cannot block a harmful session in real-time. You can only flag a user after they have accumulated enough capabilities. Remediation happens at the account level, not the session level.
Failure Modes
Cross-session detection introduces new failure modes:
False Positives from Legitimate Workflows
A developer building a security tool might accumulate the same capabilities as an attacker. The difference is intent, which is hard to infer from artifacts alone.
Mitigation: context signals (user role, historical behavior, declared project goals).
Capability Fingerprint Collisions
Two users generate similar artifacts for different reasons. The hash collides, and the detection logic conflates them.
Mitigation: include session metadata in the fingerprint (timestamp, tool used, input context).
Temporal Decay Tuning
If capabilities expire too quickly, you miss slow-burn attacks. If they expire too slowly, you accumulate noise and privacy risk.
Mitigation: adaptive TTL based on capability type and risk score.
Evasion via Capability Dilution
An attacker spreads capabilities across multiple accounts or introduces benign capabilities to dilute the signal.
Mitigation: graph-based correlation across related entities, not just single user IDs.
Observability Gaps
Traditional observability tools (Langfuse, Langsmith, Helicone) log individual traces. They do not aggregate capabilities across sessions. To implement Magnet-style detection, you need:
- A capability extraction pipeline that runs after each session
- A storage layer that indexes by correlator ID, not trace ID
- A detection engine that evaluates capability bundles, not individual sessions
None of the major observability platforms support this out of the box. You have to build it yourself or wait for the tooling to catch up.
Security Boundaries
Magnet introduces a new security boundary: the capability aggregation layer. This layer sees a compressed view of what every user has done across all sessions. It is a high-value target.
Threat model considerations:
- Data leakage: capability fingerprints might reveal sensitive information even without full conversations
- Poisoning attacks: an attacker could inject fake capabilities to trigger false positives
- Inference attacks: analyzing capability patterns might reveal user behavior or business logic
You need access controls, audit logs, and encryption at rest. The aggregation layer should be isolated from the agent execution layer and the model gateway.
Technical Verdict
Use Magnet-style cross-session detection when:
- You run multi-agent systems with tool access
- Users can execute multiple sessions over time
- The threat model includes goal decomposition and slow-burn attacks
- You have the infrastructure to store and query capability fingerprints at scale
Avoid it when:
- You only run single-turn or single-session agents
- Your threat model is limited to prompt injection or jailbreaks
- You cannot afford the engineering overhead of a separate aggregation layer
- Privacy constraints prevent storing any cross-session state
The paper exposes a real gap in current AI monitoring. Most observability tools assume stateless agents and single-session threats. Production systems are moving toward stateful, multi-agent ensembles. The plumbing needs to catch up.
If you are building agent orchestration infrastructure, you need to decide where capability tracking lives, how you store state without building a surveillance database, and when you can afford to detect threats asynchronously instead of blocking them in real-time.