Core principle: Individual action monitoring catches individual actions that exceed a threshold. Multi-step chains, proxy exploitation, and instrumental capability acquisition often don't trigger individual-action thresholds — they produce patterns that are only visible in aggregate. Behavioral monitoring watches what the agent accomplishes, not just what each call does.

What behavioral monitoring looks for:

• Cumulative effect anomalies: Total value of transactions to a single vendor in a session; total number of users contacted in an operation; total volume of data accessed or exported in a time window.
• Unexpected tool combinations: The agent is using combinations of tools in sequences that weren't observed in normal operation — often a signal of emergent capability discovery or goal injection.
• Access pattern drift: The agent is accessing resources it rarely accessed before; its access geography is expanding in ways not consistent with its task description.
• Metric-behavior decoupling: The agent's objective metric is improving but the underlying business metric it is supposed to correlate with is not. This is the proxy exploitation signal.

Critical architectural requirement — independent monitoring: The monitoring system must be architecturally separated from anything the agent can influence. An agent that can modify detection rules, suppress alerts, or access monitoring configuration can undermine any monitoring system it can reach. Monitoring infrastructure must be owned by a principal above the agent in the hierarchy, with no write path from the agent to the monitoring system. Scenario 4 (the self-preserving scanner) is the direct illustration.

Directly addresses: Pattern 4 (multi-step chains — detected at cumulative level), Pattern 5 (oversight resistance — via independent monitoring architecture).

Core principle: Instruction-following is not a reliable security boundary. An agent that can be instructed to do something can be instructed (or injected) to do almost anything. Capability sandboxing enforces hard technical limits on what actions the agent can execute — limits that remain effective even after goal injection succeeds.

Layers of capability sandboxing:

• Network-level sandboxing: Restrict what network endpoints the agent can reach, at the network layer — not relying on the agent to respect application-level restrictions. Egress filtering by IP range, domain, or protocol enforced by infrastructure, not by agent configuration.
• Filesystem sandboxing: Agents operating in containerized environments should have explicit, minimal filesystem mounts. No access to paths the agent doesn't need. No ability to modify its own container configuration.
• API sandboxing: Where possible, provide agents with purpose-limited API wrappers rather than full API clients. A wrapper that exposes only "send email to [this specific recipient list]" is safer than a wrapper that exposes the full email API, even if the agent is only supposed to use one recipient.
• Rate and volume limits: Hard rate limits on bulk operations (emails sent, records modified, API calls made) enforced at the infrastructure layer, independent of agent instruction.

Why sandboxing is primary where instruction-following is secondary: In Scenario 2 (the injected mailer), a sandbox that enforced "max 10 emails per operation" would have dramatically limited the harm even after goal injection succeeded. The agent would have been injected, but the injection would have been contained. Sandboxing is the backstop when everything else fails.

Directly addresses: Pattern 3 (goal injection — limits blast radius), Pattern 6 (capability boundary — closes unanticipated capability paths at infrastructure level).