4. Multi-Model and Multi-Agent AI Systems: Infrastructure Implementation Guide

Safe Code Execution Architecture

The primary threat is an LLM generating code that, when executed, causes unintended consequences: data exfiltration, filesystem modification, resource exhaustion, or lateral movement. The sandbox must contain these consequences regardless of what code the LLM generates.

Sandbox Controls

The sandbox relies on ten layered controls. They fall into three groups.

Isolation controls. At the kernel level, gVisor or Firecracker microVMs intercept all syscalls before they reach the host kernel, preventing host kernel exploits from malicious LLM-generated code. No network egress is permitted from the sandbox, DNS resolution is disabled, all outbound connections are blocked, closing off data exfiltration, C2 callbacks, lateral movement, and credential theft via network scan. The execution environment is created fresh from an immutable base image on every invocation, with a tmpfs filesystem destroyed after execution, so nothing persists between runs.

Resource controls. Execution timeout is enforced at the container runtime layer, not the application layer, catching infinite loops and resource exhaustion before they affect adjacent workloads. cgroup limits cap CPU and memory hard, sized to the data analysis workload. Input data is mounted read-only from the calling agent’s authorized scope; the sandbox cannot write to it.

Operational controls. The sandbox runs as a non-root, non-privileged user with no sudo access. The container image includes only an explicitly approved list of data analysis libraries, the package manager is disabled or removed, preventing arbitrary dependencies and supply chain attacks via LLM-suggested pip install commands. Execution output is capped at a configurable size limit; oversized output is truncated and flagged for HITL review. Every execution event logs the requesting agent role, code hash, execution duration, exit code, output size, and sandbox ID.

Kernel-Level Sandboxing Options

• gVisor (runsc): A user-space kernel that intercepts all syscalls before they reach the host kernel. Provides strong isolation with workload-dependent overhead: CPU-bound workloads such as data analysis see minimal to no overhead; I/O-intensive and network-heavy workloads incur higher overhead. See gvisor.dev/docs/architecture_guide/performance for current benchmarks (Google, 2024).
• Firecracker microVMs: Lightweight virtual machines with a separate kernel per execution. Stronger isolation than gVisor. Boot time under 125ms per the official specification (Amazon Web Services, 2024), viable for warm pool designs.

Warm Pool Design

• The warm pool should be sized to peak concurrent code execution demand plus 20% buffer.
• Each warm instance is claimed exclusively by one workflow invocation, used, and then destroyed. Instances are never reused across invocations.
• Overflow requests queue with a configurable maximum wait time. Requests exceeding the maximum wait return a queue-full response to the calling agent.

Observability and Behavioral Monitoring

The observability pipeline collects ten categories of signals, grouped below by what they’re monitoring.

Core workflow signals. Distributed traces follow each workflow end-to-end via correlation ID, capturing agent transitions, tool calls, model invocations, HITL gate events, and explainability events. Alert when P99 latency exceeds 2× baseline for any segment (AU-12, IR-4). Tool call audit logs capture agent role, tool ID, input parameters redacted for sensitive fields, result status, execution duration, and MCP server ID, alert on any tool call by an agent role not in its manifest allowed_tools[] (AU-2, AU-3, AC-3). Model invocation logs record agent role, model ID, model version, token count, latency, and confidence score; alert on manifest pin mismatches and on confidence scores below threshold without HITL escalation (CM-6, AU-12).

Governance signals. HITL gate logs record gate ID, agent role, output summary hash, reviewer identity, decision, decision latency, and timestamp. Two alert conditions: gate bypassed without a recorded decision, and reviewer queue age exceeding SLA (AC-3, PM-14, AU-9). Prompt version logs capture every resolution event: agent role, prompt_ref, resolved version, timestamp, and correlation ID. Alert when a prompt resolves to an unexpected version or the prompt_ref isn’t in the farm (CM-3, AU-12).

Operational signals. Code execution logs capture sandbox ID, requesting agent role, code hash, execution duration, exit code, output size, and timeout events. Alert on non-zero exit code, timeout, output at size limit, or execution by an unexpected agent role (SI-3, AU-12). Container health metrics cover CPU/memory utilization, restart count, OOM events, and network connection count per zone, alert when memory hits 85% of limit, restart count exceeds two in ten minutes, or an unexpected outbound connection attempt is detected (SI-17, SC-7). Scaling event logs capture autoscaling trigger events, metric, threshold crossed, new instance count, and warm pool utilization; alert on sustained pool utilization above 90% and on scale-up events during off-peak hours (SI-17, IR-5).

Safety and security signals. Confabulation incident logs cover manually or automatically flagged outputs where an agent generated unverified specifics. Any confirmed confabulation event triggers root cause review within 24 hours (SI-10, IR-4). Secrets access logs record every credential retrieval from the vault: requesting container identity, secret identifier (not value), and timestamp. Alert on retrieval by an unexpected container identity and on high-frequency retrieval patterns (IA-5, AU-2).

EO 14028 Log Retention and Sharing Requirements

EO 14028 Section 8 adds log retention and sharing obligations that go beyond what NIST 800-53 AU controls alone require.

• Retention. Agency policy sets the minimum retention period, typically two years for operational logs and longer for audit logs; confirm the schedule and record it in the System Security Plan.
• CISA log exports. CISA needs selective log exports during incident investigations; configure the pipeline to support export by time range, system identifier, and event type.
• EDR telemetry. On federal infrastructure, EDR telemetry from all containerized components is required and feeds into the agency’s EDR solution.

AI Incidence Response Plan

IT disaster recovery covers infrastructure failures. An AI Incident Response Plan (AI IRP) covers a different problem: the system behaving in ways that cause harm even when all the infrastructure is running fine. The two overlap but aren’t the same. What follows is the AI IRP structure for multi-agent systems operating in or adjacent to federal environments.

EO 14028 Section 5(b) requires federal agencies and their contractors to report cybersecurity incidents to CISA within 72 hours of discovery. For AI systems, the reportable incident definition extends beyond traditional cybersecurity events to include adversarial attacks via prompt injection, model output manipulation causing operational harm, and unauthorized access achieved through AI agent privilege escalation. These events fall under the same 72-hour obligation.

AI Incident Classification

Four classifications cover the incident space. The line between them matters primarily for reporting obligations.

1. AI Security Incidents are situations where the infrastructure is actively working against you: prompt injection attacks, privilege escalation through agent manipulation, unauthorized data access via AI workflow, or model output weaponized against users or systems. The 72-hour CISA clock starts at discovery. Agency CISO notification within 4 hours. Capture a forensic snapshot before remediation, isolate the affected containers, preserve all logs and trace data, activate HITL-only mode.
2. AI Safety Incidents mean demonstrable harm from AI behavior regardless of whether the infrastructure was compromised: a confabulation that drove a wrong decision, a dangerous recommendation acted on, output affecting user safety, or systematic bias producing discriminatory outcomes. Report to the AI governance office within 24 hours; disclose to affected users per policy. Halt automated workflows in the affected domain, review outputs from the affected agent for the prior 48 hours, and start root cause analysis.
3. AI Operational Anomalies sit below the incident threshold but need tracking: elevated confabulation without demonstrated harm, schema failure rate spikes, confidence distribution shift, HITL escalation rate outside normal range. System owner notification within 8 hours, documented in the operational log. Increase monitoring verbosity, review recent prompt or model changes, and don’t halt workflows without actual evidence of harm.
4. AI Performance Degradation covers latency, throughput, and error rates with no safety or security angle. Standard incident management applies; no AI-specific escalation path needed.

CISA 72-Hour Reporting Procedure

• Step 1 (0-4 hours): The on-call responder confirms the event meets AI Security Incident criteria, captures a forensic snapshot of all logs, traces, and container states, and notifies the agency CISO and system owner.
• Step 2 (0-4 hours): Containment. Isolate affected agent containers, activate HITL-only degradation, preserve all evidence. Don’t remediate or restart anything until the forensic snapshot is confirmed complete.
• Step 3 (within 72 hours of discovery): Submit the incident report to CISA via the reporting portal or agency-designated channel. Required fields: system identifier, incident type, discovery date and time, affected components, initial impact assessment, containment actions taken, and point of contact. This report is preliminary; full findings follow separately.
• Step 4: Investigation. Reconstruct the incident using distributed traces and correlation IDs, identify the attack vector, affected agent roles, tool calls made, data accessed, and outputs produced.
• Step 5: Remediation and recovery. Address the root cause before restoring automated workflows, update manifest/prompt/schema as needed, run the full regression suite, and restore operations tier by tier starting from Tier 5.
• Step 6 (within 72 hours of closure): Structured after-action review. Update the IRP, runbooks, and detection rules based on findings. Report to the AI governance office.

STAKEHOLDER NOTIFICATION MATRIX