Your Cloud Now Has Two Attack Surfaces. You're Only Monitoring One.

✓ Human-authored analysis; AI used for formatting and proofreading.

A coding agent assumes an IAM role. It reads a specification. It generates Terraform. It runs terraform apply. It deploys infrastructure into your AWS account. The infrastructure includes IAM roles, Lambda functions, S3 buckets, security groups.

The agent is now part of your cloud's attack surface.

If an attacker compromises the agent through prompt injection, poisoned context, manipulated specifications, or supply chain attacks on the agent's dependencies, the attacker inherits the agent's IAM role. Every permission the agent has, the attacker has. Every resource the agent can modify, the attacker can modify.

MITRE ATT&CK tells you how attackers compromise cloud infrastructure such as privilege escalation, lateral movement, data exfiltration. Your CSPM tool monitors these. Your SOC alerts on these. You know this attack surface.

MITRE ATLAS tells you how attackers compromise AI systems such as prompt injection, data poisoning, model manipulation, adversarial examples. Your CSPM tool doesn't monitor these. Your SOC doesn't alert on these. This is the attack surface you're not watching.

In the agentic era, both attack surfaces converge. An ATLAS attack on the agent produces an ATT&CK outcome on the infrastructure. The two frameworks are no longer separate domains. They're two stages of the same attack chain.

Two frameworks, one attack chain

MITRE ATT&CK (14 tactics, 200+ techniques) covers the traditional attack lifecycle against IT infrastructure. Reconnaissance, initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, impact.

MITRE ATLAS (16 tactics, 84 techniques) covers adversarial tactics targeting AI and ML systems. Reconnaissance of ML models, poisoning training data, evading detection models, extracting model weights, injecting prompts, manipulating agent behavior, exploiting ML supply chains.

Before agents, these were separate domains. ATT&CK was for infrastructure security teams. ATLAS was for ML security researchers. The teams, attack surfaces and the tools didn't overlap.

Agents changed this. When an AI agent manages cloud infrastructure, an ATLAS attack on the agent is an ATT&CK attack on the infrastructure executed through the agent instead of through a compromised credential or a misconfigured service.

TRADITIONAL ATTACK (ATT&CK only):
    Attacker → phishes credential → assumes IAM role → escalates
    → reads S3 data → exfiltrates

    Attack surface: the cloud infrastructure
    Framework: ATT&CK
    Detection: CloudTrail, GuardDuty, CSPM

AGENTIC ATTACK (ATLAS → ATT&CK):
    Attacker → injects prompt into agent context → agent generates
    malicious Terraform → agent runs terraform apply → IAM role
    with admin access is created → attacker assumes the role
    → reads S3 data → exfiltrates

    Attack surface: the agent (ATLAS) → the infrastructure (ATT&CK)
    Framework: ATLAS for the entry, ATT&CK for the outcome
    Detection: ??? (most organizations have nothing here)

The second attack chain has the same outcome as the first with data exfiltration via IAM escalation. But the entry point is different. The attacker didn't phish a credential. They manipulated an agent. The agent did the escalation. CloudTrail shows the agent's IAM role making API calls which looks like normal agent behavior. GuardDuty doesn't flag it because the actions are within the agent's permissions. The CSPM tool checks the configuration after deployment and might catch the admin role but by then the damage is done.

Where the two frameworks meet

The connection point is the agent's IAM role. The agent needs cloud permissions to do its job. Those permissions are the bridge between the AI system (ATLAS scope) and the cloud infrastructure (ATT&CK scope).

ATLAS scope (the agent):
    The agent receives instructions (prompt, specification, context)
    The agent generates actions (API calls, code, configurations)
    The agent executes actions (terraform apply, aws cli, kubectl)

    ATLAS attacks target: the instructions, the generation, the execution
    ATLAS techniques: prompt injection, context poisoning, supply chain
                      compromise of agent dependencies

ATT&CK scope (the infrastructure):
    The IAM role permits specific actions
    The actions modify cloud resources
    The resources contain or protect data

    ATT&CK attacks target: the permissions, the resources, the data
    ATT&CK techniques: privilege escalation, lateral movement,
                       data exfiltration

Bridge: The agent's IAM role
    ATLAS attack → agent compromised → agent uses IAM role → ATT&CK outcome

The agent's IAM role is the amplifier. An ATLAS attack on the agent is constrained by the agent's permissions. An agent with read-only access to one S3 bucket can't exfiltrate all of S3. Even if the agent is fully compromised. An agent with admin access can do everything, the ATLAS attack produces an ATT&CK outcome equivalent to a stolen admin credential.

This is why IAM least privilege for agents isn't just good practice, it's the blast radius control for ATLAS attacks. The principle is the same as for human users (constrain permissions to limit damage). The threat model is different (the agent is compromised through prompt injection, not credential theft).

Five ATLAS techniques that produce ATT&CK outcomes

1. Prompt injection → Privilege escalation

ATLAS technique: AML.T0051 (LLM Prompt Injection)

An attacker injects instructions into the agent's context through a manipulated specification file, a poisoned document the agent reads, or a crafted user input the agent processes. The injected instructions tell the agent to create an IAM role with admin access, or to modify a security group to allow inbound SSH from the attacker's IP.

ATT&CK outcome: T1078.004 (Valid Accounts: Cloud) or T1098.003 (Additional Cloud Roles). The infrastructure is compromised through a legitimate agent action that was triggered by a malicious prompt.

What catches it: The CSPM tool might catch the over-privileged role AFTER creation. Stave's controls (CTL.IAM.POLICY.ADMIN.001, CTL.IAM.ESCALATE.*) would flag it in the next evaluation. But the gap between creation and detection is the window of exposure. The ideal defense: constrain the agent's IAM role so it CAN'T create admin roles even if prompted to.

2. Context poisoning → Configuration drift

ATLAS technique: AML.T0049 (Adversarial ML Supply Chain Compromise) applied to agent context

An attacker modifies a specification file, an ADR, or a configuration template that the agent reads as context. The modification is subtle, a single field changed in a YAML file, a condition removed from a policy template. The agent reads the poisoned context and generates infrastructure that matches the poisoned specification.

ATT&CK outcome: The infrastructure drifts from the intended security posture. The drift isn't detected because the agent implemented the specification and the specification was wrong. The audit checks the agent's output against the specification and says compliant. The specification was compromised.

What catches it: Drift detection between the specification's intended security properties and the observed cloud state. If the specification says "no public access" but the poisoned version removed that constraint, the CSPM tool compares the LIVE state to the SECURITY PROPERTIES, not to the specification. The properties are the source of truth for security.

3. Supply chain compromise → Code injection

ATLAS technique: AML.T0048 (ML Supply Chain Compromise)

An attacker compromises a dependency the agent uses such as a tool, a plugin, a library, an MCP server. The compromised dependency modifies the agent's behavior: it adds a backdoor to every Lambda function the agent deploys, or it exfiltrates environment variables to an external endpoint.

ATT&CK outcome: T1195.002 (Supply Chain Compromise: Software). Every infrastructure deployment the agent makes includes the backdoor. The backdoor persists across deployments because it's in the dependency, not in the agent's prompt.

What catches it: Static analysis of the DEPLOYED code (not the agent's code). Stave's Lambda controls (CTL.LAMBDA.SECRETS., CTL.LAMBDA.CODESIGN.) catch secrets in environment variables and unsigned code. But the supply chain attack is upstream of Stave's evaluation. It happens in the agent's dependency chain, before the infrastructure exists.

4. Model extraction → Specification theft

ATLAS technique: AML.T0024 (Model Extraction)

Applied to the agentic context: an attacker extracts the agent's specifications, prompts, and instructions which contain the organization's security policies, architectural patterns, and infrastructure templates. The attacker now knows the organization's security model, including which properties are enforced and which aren't.

ATT&CK outcome: T1592 (Gather Victim Host Information). The attacker uses the extracted specifications to identify gaps, properties that AREN'T in the specification are properties the agent doesn't enforce. The attacker targets those gaps.

What catches it: Nothing in the current CSPM landscape catches specification theft. The defense is information classification: treat agent specifications as security-sensitive documents. The specifications contain the organization's defense model.

5. Agent manipulation → Lateral movement

ATLAS technique: AML.T0052 (Manipulate AI Agent Behavior)

An attacker manipulates an agent to use its IAM role for actions outside the agent's intended scope. The agent is authorized to deploy Lambda functions (for CI/CD). The attacker manipulates the agent to use its Lambda deployment permissions to deploy a function that reads from an S3 bucket the agent was never intended to access. But the IAM role permits it because the role was scoped to Lambda, not to specific buckets.

ATT&CK outcome: T1021 (Lateral Movement). The agent moves from its intended scope (Lambda deployment) to an unintended target (S3 data access) using permissions it legitimately holds but was never intended to use this way.

What catches it: Stave's compound chain detection. The reasoning engine traces the path: agent's IAM role → Lambda deployment permission → Lambda execution role → S3 access. Each hop is individually authorized. The composition is the vulnerability. This is the Capital One pattern applied to an agent instead of a human.

What this means for cloud security tooling

The CSPM tool that only evaluates infrastructure configuration (ATT&CK scope) misses the agent attack surface (ATLAS scope). The ML security tool that only evaluates model behavior (ATLAS scope) misses the infrastructure consequences (ATT&CK scope).

Tool scope             Catches                  Misses
───────────            ───────                  ──────
ATT&CK only (CSPM)    Infrastructure misconfig  Agent compromise → infra impact
ATLAS only (ML sec)    Agent manipulation        Infrastructure consequences
Both (unified)         Agent compromise AND      (this tool largely doesn't
                       the infrastructure        exist yet)
                       outcome it produces       

The tool that evaluates BOTH surfaces needs to trace the path from the agent's context (ATLAS) through the agent's IAM role (bridge) to the infrastructure outcome (ATT&CK). This is the same graph-traversal compound detection that traces paths from a public endpoint to a sensitive resource extended to include the agent as a node in the graph.

The agent is a principal. It has an identity (IAM role). It has permissions (IAM policies). It has access to resources (S3 buckets, Lambda functions, databases). It can be compromised (ATLAS techniques). When compromised, it uses its permissions to produce infrastructure outcomes (ATT&CK techniques).

The security graph must include the agent as a first-class node not as a human user and not as a service, but as an entity with its own threat model (ATLAS) that produces outcomes on other entities (ATT&CK).

For practitioners: what Stave does and doesn't do here

ATLAS attacks happen UPSTREAM of Stave. Stave evaluates DOWNSTREAM. The infrastructure the agent deployed. It catches the ATT&CK outcomes, not the ATLAS entry points.

ATLAS attack surface (UPSTREAM — Stave does NOT cover this):
    Prompt injection into the agent         → prevent with input validation
    Context poisoning of specifications     → prevent with integrity checks
    Supply chain compromise of agent deps   → prevent with dependency scanning
    Model extraction of specifications      → prevent with access controls
    Agent behavior manipulation             → prevent with agent sandboxing

ATT&CK outcome surface (DOWNSTREAM — Stave DOES cover this):
    Agent created an admin IAM role         → CTL.IAM.POLICY.ADMIN.001
    Agent created a privilege escalation    → CTL.IAM.ESCALATE.*.001 (30+ controls)
    Agent opened a security group           → CTL.EC2.SG.INGRESS.*.001
    Agent deployed Lambda with admin role   → CTL.LAMBDA.PASSROLE.001
    Agent created a ghost reference         → ghost reference detection
    Agent created a compound attack path    → reasoning engine chain detection

The workflow:

1. The agent deploys infrastructure (whether compromised or not — Stave doesn't know and doesn't care).

2. You snapshot the deployed state:

# Capture what the agent deployed
./capture.sh snapshot-agent-deploy dog agent-

3. You run Stave against the snapshot:

./stave apply --observations observations/

4. Stave evaluates the RESULT, not the source. If the agent was compromised and created an admin role, Stave flags CTL.IAM.POLICY.ADMIN.001. If the agent was NOT compromised but made a mistake (overprivileged role from a bad spec), Stave flags the same control. The detection is the same regardless of WHY the misconfiguration exists — because the misconfiguration is dangerous either way.

5. For compound chains, export to reasoning engines:

./stave export-sir --observations observations/ --format jsonl > facts.jsonl
# Soufflé/Prolog compute: can the agent's deployed resources
# form a privilege escalation chain?

The reasoning engine traces the path the ATLAS attack created through the specific IAM roles, trust relationships, and resource configurations the agent deployed. This is the same graph-traversal compound detection used in the Datadog and Bishop Fox labs, applied to agent-deployed infrastructure.

What Stave tells you after an ATLAS attack:

"The agent deployed infrastructure that contains:
    - 1 admin-equivalent IAM role (CTL.IAM.POLICY.ADMIN.001)
    - 1 privilege escalation path via Lambda (CTL.IAM.ESCALATE.EDITLAMBDA.001)
    - 1 compound chain: public endpoint → Lambda → admin role → S3

Whether the agent was compromised or simply misconfigured, these
findings represent the same risk. Remediate regardless of cause."

Stave doesn't tell you WHETHER the agent was compromised. It tells you what the agent PRODUCED and whether what it produced is safe. The ATLAS question (was the agent compromised?) and the ATT&CK question (is the infrastructure safe?) are both important. Stave answers the second. The first requires upstream tooling that monitors the agent itself.

The honest boundary:

Stave's scope:     Evaluate what the agent deployed
Not Stave's scope: Evaluate whether the agent was compromised

Stave catches:     The ATT&CK outcomes of ATLAS attacks
Stave doesn't:     Prevent ATLAS attacks from happening
Stave's value:     The blast radius of an ATLAS attack is defined
                   by what the agent deployed. Stave measures that
                   blast radius — every privilege escalation path,
                   every admin role, every compound chain — 
                   regardless of how it got there.

Stave evaluates cloud configuration regardless of how it was deployed by humans, agents, or CI/CD pipelines. The 2,668 controls and the reasoning engine exports cover the ATT&CK outcomes (privilege escalation, admin access, ghost references, compound chains). ATLAS-scope defenses with constraining agent IAM roles, validating agent context, detecting prompt injection are upstream of Stave's evaluation but determine the blast radius of what Stave evaluates. Both frameworks apply. Both attack surfaces matter. MITRE ATT&CK technique IDs are mapped to every escalation control in the catalog for cross-framework correlation.