L4 · MAESTRO
Deployment Infrastructure
The runtime environment hosting the agent: containers, orchestration, secrets management, network egress, and the trust boundary between the agent runtime and adjacent systems.
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.
Threats at this layer
Every threat whose maestroLayers list includes L4. The prose above may discuss a subset; this list is the complete index.
- T3Privilege Compromise
- T4Resource Overload
- T11Unexpected RCE and Code Attacks
- T13Rogue Agents in Multi-Agent Systems
- T14Human Attacks on Multi-Agent Systems
- T22Service Account Exposure
- T33Blockchain Reorganisation Attack (Indirect)
- T34Wallet Key Compromise
- T43Network Exposure of MCP Server
- T51Agentic-Browser Cross-Origin Exfiltration
Controls mapped to this layer
Auto-generated from the mitigation catalog: every mitigation whose maestroLayers list includes L4, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
- Tier 1Kernel-isolated sandbox(Kernel-isolated sandbox — agent-executed code runs against its own kernel, not the host's)
When an agent executes generated or retrieved code, that code runs as a process with access to the host kernel. A vulnerability in the generated code, or a deliberate exploit injected through the agent's prompt, can reach the kernel and affect other workloads or the host itself. A kernel-isolated sandbox removes that path by giving the workload a kernel of its own: gVisor interposes a user-space kernel so syscalls reach the Sentry rather than the host, and Kata Containers runs the pod in a lightweight VM with a separate kernel. Which one is available is a property of the platform, not of the control — AKS ships Kata as Pod Sandboxing and does not support gVisor; GKE ships gVisor.
- Tier 1SPIFFE(SPIFFE / SPIRE workload identity — cryptographic identities for every agent and service)
In most deployments, agents authenticate to one another with long-lived bearer tokens or shared secrets. If any one of those credentials is stolen, the attacker has persistent, platform-wide access until someone manually rotates it. SPIFFE replaces that model: each workload is issued a short-lived, cryptographically verifiable identity document, and every connection requires both sides to present one. No long-lived secrets traverse the network, and a compromised credential is worthless within its TTL.
- Tier 2Admission control(Agent admission control — verify identity, capability claims, and provenance before a peer joins the system)
In a multi-agent system, peer agents are granted authority by the other agents that accept their outputs. A rogue or compromised agent that enters the system inherits that authority immediately. Agent admission control is the registration gate that evaluates a peer's identity, declared capabilities, and binary provenance against policy before granting access. A peer that cannot pass attestation is refused entry and cannot participate in the system.
- Tier 2Agent MFA(MFA for high-privilege agent identities — step-up attestation at credential issuance and action time)
An agent identity that holds broad write authority is a high-value target: compromising its credential gives an attacker persistent, authenticated access to every system that identity can reach. Multi-factor authentication addresses this by requiring a second factor at credential issuance time, so a stolen token is bounded to its issued lifetime and cannot be silently renewed. For non-human identities the second factor is workload attestation, hardware-bound key material, or certificate-backed proof rather than a phone or one-time code.
An agent that has been compromised, poisoned, or gone rogue will, in most cases, behave differently from its established baseline. Anomaly isolation acts on that difference: when an agent's behaviour score crosses a configured threshold, it is quarantined automatically, credentials revoked, message-queue access cut, in-flight actions aborted. Manual revocation cannot match the speed that cascading multi-agent failures demand.
- Tier 2Cross-client isolation(Cross-client isolation — request-scope tenant boundaries in shared MCP server deployments)
A shared MCP server that accepts connections from multiple clients is a concentration point where one client's session state, credentials, and resource budget are physically co-located with every other client's. Without enforced isolation, a malicious or compromised client can read another session's cached credentials, consume shared resources to the point of denying service to other clients, or exploit aggregate server permissions that exceed its own declared scope. Cross-client isolation is the set of structural controls that close those paths: per-session state scoping, per-client permission evaluation, and per-client resource quotas enforced at the server layer.
An agent that operates across HR, Finance, cloud, and SaaS systems accumulates permissions at each boundary, often without any single team seeing the combined picture. Privilege accumulates silently across those boundaries until a quarterly review finds it, by which point a compromised or misconfigured agent has had weeks of unchecked reach. Cross-system scope auditing prevents that by continuously reconciling the agent's actual entitlements against a declared baseline across every system it touches and raising a ticket the moment drift is detected.
- Tier 2Data classification(Data classification with tool-access allow-lists — a sensitivity label on every dataset, enforced at every access seam)
Every dataset, document, and external system an agent can reach carries a classification label. The agent's permitted-class set and the tool's permitted-class set are intersected at the moment of every read or write. When the requested data's class falls outside that intersection, access is denied at the seam. This is the data-side complement to least-privilege: it adds a data-sensitivity constraint that role scoping alone does not provide.
- Tier 2Egress isolation(Network egress isolation — deny-by-default agent→internet, enforced at the network layer)
Content-layer inspection reads outbound payloads and decides pass, redact, or quarantine per channel — but it can only classify what it can parse as content. A direct TCP/UDP socket opened by agent-executed code, a raw DNS query, or a payload encoded into DNS subdomain labels never reaches an HTTP-shaped inspection point at all. Network egress isolation closes that gap one layer down: every agent and tool-bus process sits behind a default-deny network policy, and the only path to the internet is through an enforced proxy that mediates, allowlists, and logs each connection attempt regardless of what it contains.
An AI agent operates under a non-human identity (NHI): a service principal, a task role, or a workload credential. That identity produces a stream of access events that, for a well-scoped agent, forms a narrow and predictable behavioural baseline. Identity monitoring applies User and Entity Behaviour Analytics (UEBA) to that stream, alerting when an observed access pattern deviates statistically from the baseline. Because agent behavioural distributions are tighter than those of human users, a deviation is a higher-confidence signal, and a spoofed or stolen credential used from the wrong workload origin is exactly the anomaly the technique is built to detect.
- Tier 2JIT elevation(Time-bounded privilege elevation — temporary credentials that expire automatically)
An agent running with a permanent high-privilege identity gives an attacker, or a misconfigured agent, broad access for as long as that identity persists. Time-bounded privilege elevation addresses this by issuing a short-lived credential tied to a specific action window: the agent holds elevated access only for the duration it needs, and the issuing platform revokes that access automatically when the TTL expires. This is the just-in-time (JIT) access pattern from PAM practice, applied to non-human identities.
An agent that holds a persistent catalog of invokable tools can reach any of them at any point in its session. If its reasoning is manipulated or its identity is compromised, that persistent surface is fully available to an attacker. Just-in-time tool grants remove the standing surface: a policy broker issues a time-bound, task-scoped grant immediately before the tool is needed and revokes it automatically when the task completes or the window expires.
- Tier 2MCP server attestation(MCP server attestation — cryptographic proof of server identity and binary integrity)
An MCP client connecting to a server has no built-in way to verify that the server at a given address is the expected workload or that its binary has not been replaced. An attacker who can intercept or substitute the server exploits that gap directly. MCP server attestation closes it by requiring the server to present cryptographic proof of two properties before the connection proceeds: that it holds a valid workload identity bound to a trusted certificate, and that its binary matches a signed hash recorded at build time.
A Non-Human Identity (NHI) is the service account, machine principal, or formal agent identity under which an agentic system authenticates and acts. When an NHI is provisioned with broad scope, never rotated, and has no named owner, a stolen or leaked credential gives an attacker persistent access for as long as that credential remains valid. NHI lifecycle management treats each agent identity as a first-class governance object: provision narrowly with a declared scope and owner, rotate on a short schedule using platform-native short-lived credentials, audit every authentication and rotation event, re-attest that the identity is still needed, and decommission by deletion when the agent is retired.
Prompt injection succeeds when untrusted content entering an agent's prompt is indistinguishable from trusted instruction. Three layered techniques address that: spotlighting tags untrusted content with a machine-readable origin mark before it reaches the model; delimiter defence rejects input carrying reserved framework tokens before the model is called; and dual-LLM extraction routes attacker-influenceable content through a quarantined model that holds no tool access, so injected instructions cannot reach the model that can act on them.
- Tier 2Policy bound(Policy-bound autonomy — declarative runtime enforcement of the agent's action space)
An agent's authority is normally bounded only by its own reasoning. If that reasoning is manipulated, or the agent's identity is compromised, it will attempt actions the operator never intended to permit. Policy-bound autonomy addresses this by placing a declarative enforcement point between the agent and every consequential action: a policy engine evaluates the agent identity, the target tool, and the parameter envelope before execution, and the agent cannot reason or argue past the result.
An LLM produces tool-call arguments through generation, not through a type system, and generation is not reliable. The arguments may be wrong in type, out of range, or assembled in a combination that violates business rules. A pre-execution validation gate intercepts the call before it reaches the tool: a schema pass confirms each argument conforms to the declared JSON Schema, and a policy pass confirms the argument combination is permitted for this agent and this action. The tool executes only when both passes clear.
- Tier 2Rate limits and quotas(Per-agent rate limits and quotas — bound compute, tokens, and external-API spend)
An agent operates without direct human oversight, autonomously scheduling tool calls, external API requests, and reflection loops. Without a budget, a single triggering event can fan out into hundreds of downstream calls. Per-agent rate limits and quotas assign each agent identity its own ceiling on call rate, token consumption, and cost spend, so a misbehaving or compromised agent cannot exhaust shared resources and its overconsumption becomes a visible, actionable signal.
Role-Based Access Control (RBAC) assigns every agent identity a named role that sets the outer limit on what it can reach. Attribute-Based Access Control (ABAC) narrows individual decisions inside that role by evaluating contextual attributes at request time. Used together, they enforce least privilege for non-human identities: the agent can only do what its role permits, and only when the request attributes satisfy the policy.
- Tier 2SBOM for AI(SBOM for AI: the model, dataset and infrastructure record a general SBOM has no fields for)
A conventional SBOM inventories libraries, images and packages. It has no field for the weight an agent loads, the corpus it retrieves from, or where that corpus was collected. An SBOM for AI adds those: seven clusters covering the system, its models, its datasets, its infrastructure, the security controls already in place, and the indicators used to watch it. It is recorded in addition to the general SBOM, never instead of it.
An agent that serves multiple users stores conversation history, retrieved facts, and intermediate state in a memory layer. If that layer is not scoped to the originating session, one user's writes can reach another user's retrieval path. Session-scoped memory isolation prevents that by enforcing a hard boundary at the storage layer, so each session can only read and write its own state.
- Tier 2Shared-memory ACL(Shared-memory ACL — per-agent, per-namespace read/write access control on shared vector stores)
When multiple agents share a single vector store, the access boundaries between them are not enforced by the store itself unless you configure them explicitly. Without per-namespace write and retrieval controls, an agent that can write to the shared corpus can insert crafted vectors into any namespace it can reach, and any agent that can query the store can retrieve another agent's confidential documents through embedding-space proximity. Shared-memory ACL addresses this by tagging every vector with a principal identifier at write time and filtering every retrieval query to the requesting agent's namespace, enforced at the gateway layer where the agent cannot bypass it.
An agent that writes its own audit log can omit, alter, or suppress any record of its own actions. This is not a theoretical risk: an attacker who controls the acting identity controls the evidence. Actor/recorder separation is the structural fix. The identity that performs an action and the identity that records it are different principals, with non-overlapping permissions, so no single compromise can both execute and erase.
- Tier 2Token TTL(Short-lived tokens — bounding the credential exploitation window for agent identities)
An agent identity backed by a long-lived bearer token grants access for as long as that token remains valid. If the token is stolen, logged, or extracted from a running process, the attacker holds working credentials for weeks or months without any further action. Short-lived tokens address this by issuing credentials with a time-to-live measured in minutes or hours, automated and renewed by the platform rather than a human. When a token expires, access ends: the attacker must win the renewal process as well, which requires compromising a harder target than the token itself.
- Tier 2Tool-desc validation(Tool description validation — inspect every tool description at catalog-load before it reaches the agent)
A tool's description field is concatenated directly into the agent's system prompt and shapes which tools the agent selects and how it uses them. An attacker who controls or compromises a tool manifest can plant a description that overstates the tool's scope, suppresses safety scaffolding, or embeds instruction-following language aimed at the agent. Validating descriptions at catalog-load, before the tool enters the runtime, stops that class of manipulation at the registration boundary rather than detecting its effects later at the call seam.
- Tier 3Workflow state consistency(Workflow state consistency — distributed-state integrity checks for multi-agent workflows)
When multiple agents read and write shared workflow state concurrently, a network partition, a delayed message, or an adversarially timed race condition can produce divergent views. An agent acting on stale or conflicting state may authorise an action it would reject given correct current state. Hash-chained state snapshots, merge-point conflict detection, and optimistic concurrency control close that window.