L4 · MAESTRO

Deployment Infrastructure

Last reviewed 2026-05-08 · Status: published · Order 4 of 7
WHERE L4 LIVES ON THE AGENTIC REFERENCE ARCHITECTURE
Agentic reference architecture: L4 Deployment Infrastructure highlighted L4 DEPLOYMENT PERIMETER APPLICATION USER INPUT OUTPUT AI AGENTS PLANNING TOOL CALLING ACTION MEMORY (short) MODEL LLM Function Calling AGENT peer / MCP CONTENT CODE DATA HITL DEVICE SERVICE LONG-TERM MEMORY VECTOR DATASTORE

L4 is the deployment perimeter (containers, orchestration, sandboxes, network and credentials) around the runtime and its tool execution path.

The Deployment Infrastructure layer covers the runtime environment that hosts the agent: containers, orchestration platforms, secrets management, network egress controls, autoscaling, and the trust boundary between the agent runtime and adjacent systems. This is the layer where MLSecOps practices apply: securing not just the model artifact but the infrastructure that serves it. In a multi-agent system (MAS), L4 is also where the orchestration plane that deploys and manages multiple agent pods or processes lives, making it a high-value target for attackers who want control over the entire system at once.

What lives here

  • Container images that package the agent runtime and its dependencies
  • Container orchestration (Kubernetes deployments, ECS task definitions, Cloud Run services)
  • Secrets management systems accessed by the agent at runtime (Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault)
  • Network egress policies: what external endpoints the agent container may reach
  • Sandbox environments used for tool execution (gVisor, Firecracker, nsjail, Kata Containers)
  • Service mesh and mTLS configuration between agent services and tool backends
  • Autoscaling policies and resource quotas that bound agent compute consumption
  • CI/CD pipelines that build and deploy agent containers (themselves part of the attack surface)
  • The orchestration control plane (Kubernetes API server, ECS scheduler) that can deploy, modify, or terminate agent workloads
  • Non-human identities (NHIs): service accounts, OIDC tokens, and workload certificates the agent uses to authenticate to tools and peers

The MAESTRO guide (Cloud Security Alliance, Ken Huang, 2025) calls out compromised orchestration as a MAS-specific escalation: an attacker who gains control of the orchestration plane can deploy rogue agents, modify running workloads, or drain resources from legitimate agents. These effects go far beyond compromising a single agent instance.

Concrete example: An AutoGen multi-agent coding assistant runs each agent as a Kubernetes pod with a shared service account that was granted secrets:read on the entire namespace for convenience. A code-execution tool (Python REPL) runs without a gVisor sandbox. When a prompt-injection payload triggers execution of attacker-supplied code, the resulting process reads every secret in the namespace (database credentials, API keys, peer-agent tokens) and exfiltrates them via an egress path that no network policy blocked. The L3 injection became an L4 blast-radius failure.

Threats that target this layer

  • T3 Privilege Compromise: service accounts attached to agent containers often accumulate permissions over time. Excessive IAM roles, over-scoped OIDC trust policies, or hardcoded credentials in container images give an attacker who compromises one agent container a foothold into systems far outside the agent’s intended scope.
  • T4 Resource Overload: an agent or a peer that issues unbounded tool calls, spawns recursive sub-agents, or generates arbitrarily large payloads can exhaust container CPU/memory quotas, exhaust API rate limits on shared inference endpoints, or trigger cascading autoscaling that incurs cost without performing useful work.
  • T11 Unexpected RCE and Code Attacks: if the agent executes code generated during inference (Python REPL, shell tool, SQL execution), the container that runs that code is the blast-containment boundary. Insufficient sandboxing at L4 means a code-injection attack (L3) becomes a host or cluster escape at L4.
  • T13 Rogue Agents in Multi-Agent Systems: an attacker who compromises the orchestration control plane can deploy unauthorised agent instances that impersonate legitimate peers or perform malicious actions under the cover of the cluster’s identity.

Mitigations anchored here

  • gVisor sandbox: run tool-execution containers under a gVisor or equivalent kernel-isolation sandbox. Reduces the blast radius of T11 code attacks from host-level to sandbox-level; effective even when the agent framework layer provides no code-review gate.
  • NHI lifecycle management: govern the full lifecycle of non-human identities (service accounts, workload certificates, OIDC tokens) attached to agent processes. Short-lived credentials, automated rotation, and just-in-time issuance limit the window an attacker can exploit compromised credentials.
  • per-agent quota budgets: enforce per-agent resource quotas (API call rate, token budget, concurrent requests) at the infrastructure layer. Quota enforcement at L4 is harder to bypass than at L3 because it does not depend on the agent’s own cooperation.
  • RBAC and ABAC: enforce role-based and attribute-based access control on every service the agent calls. The agent’s service account should hold only the permissions its declared role requires; L4 policy enforcement is the backstop when L3 scope controls fail.
  • time-bounded privilege elevation: issue agent credentials with explicit expiry and scope them to the current task. A time-bounded credential that expires when the task completes cannot be replayed in a later context.
  • SPIFFE / SPIRE workload identity: use SPIFFE/SPIRE to issue short-lived, workload-attested identities to agent processes. Workload attestation binds the credential to the specific container image and orchestrator context, making it harder to forge the identity outside the legitimate deployment.
  • policy-bound autonomy: enforce a declared autonomy boundary at the infrastructure layer: the agent’s service account, network policy, and resource quota collectively define what it can actually do, independent of what it believes it is permitted to do.

How L4 relates to its neighbours

L4 sits below L5 Evaluation and Observability and above L3. The framework layer (L3) issues real-world actions (tool calls, API requests, code execution) and L4 is the infrastructure that executes or proxies them. Controls at L4 do not prevent a bad plan from forming (that is L3’s job) but they limit what a bad plan can accomplish. A sandboxed container means a compromised code-execution tool cannot escape to the host; a network egress policy means an agent cannot exfiltrate data to an arbitrary endpoint even if it tries.

L4 also provides the substrate on which L5’s observability tooling runs. Log collection, metrics export, and distributed tracing all depend on L4 infrastructure: log pipelines, telemetry agents, and storage backends. A L4 compromise that silences telemetry infrastructure disables the visibility that L5 relies on.


Deployment infrastructure is where the policy decisions made at every other layer either hold or fail under real-world conditions. An agent with a well-designed framework (L3) but an over-privileged service account and no egress control (L4) has a large, exploitable blast radius that no amount of prompt engineering can close.

All threats tagged to this layer

Every threat whose maestroLayers list includes L4. The prose above may discuss a subset; this list is the complete index.

Upstream sources