> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usetrident.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Find Multi-Hop Cloud Attack Paths Linked to AI Agents

> Trident's toxic combo engine finds multi-hop attack paths connecting AI agent vulnerabilities to sensitive cloud data, ranked by exploitability.

An attack path is a sequence of steps an adversary can chain together to move from an initial foothold to a high-value target — lateral movement through IAM roles, across network boundaries, and into sensitive data stores. Individual steps often look harmless in isolation: a slightly over-permissioned role here, a publicly reachable service there. The danger is in the combination. Trident's toxic combo engine exists precisely to find those combinations — and in an AI-first architecture, the chain frequently starts with a prompt injection rather than a credential leak.

<Note>
  Attack paths that involve AI agents are uniquely dangerous because **prompt
  injection can be the initial compromise step**. An attacker who can influence
  an agent's input can trigger tool calls that traverse cloud permissions the
  agent was never intended to exercise at that level of trust.
</Note>

## The security graph

Trident represents your entire cloud environment as a directed graph. Every resource is a node; every relationship between resources is a typed, directed edge.

**Node types** include: EC2 instances, Lambda functions, S3 buckets, RDS and DynamoDB instances, IAM roles and users, EKS clusters, Kubernetes pods, service accounts, and more.

**Edge types** capture access and trust relationships:

| Edge kind      | Meaning                                              |
| -------------- | ---------------------------------------------------- |
| `assumes_role` | An identity or workload can assume this IAM role     |
| `grants`       | A role or policy grants permissions to this resource |
| `reaches`      | Network reachability between two resources           |
| `stores`       | A workload writes data to this data store            |
| `mounts`       | A container mounts this volume or secret             |
| `runs`         | A compute resource runs as this identity             |

Every AI agent you instrument with Trident is linked in the graph to the cloud workload it runs on, the IAM role that workload assumes, and the data stores reachable from that role. This is the connection traditional cloud security tools do not make.

## The toxic combo engine

The toxic combo engine searches the security graph for paths that combine two or more risk factors that are individually low-severity but together constitute a critical exploit chain. It runs a breadth-first search (BFS) from every agent workload node, following typed edges toward high-sensitivity data stores and privileged identities.

### Named detection rules

<AccordionGroup>
  <Accordion title="agent_injection_priv_role — AI agent to privileged role to sensitive data">
    **The Trident-defining rule.** Fires when a prompt-injectable AI agent
    runs as (or can assume) a privileged IAM role that has access to a
    sensitive data store. The path: attacker crafts a malicious prompt →
    agent executes tool calls under the privileged role → role has
    `s3:GetObject` (or equivalent) on a bucket classified `sensitivity:HIGH`.

    This is the attack that makes AI-adjacent cloud security fundamentally
    different from traditional CSPM.
  </Accordion>

  <Accordion title="Over-permissioned identity + public exposure + sensitive data">
    Fires when a publicly reachable resource (e.g. an EC2 instance with a
    security group open to `0.0.0.0/0`) runs as an identity with broad
    permissions over sensitive data. Public exposure combined with
    over-permission creates a direct exfiltration path requiring no
    lateral movement.
  </Accordion>

  <Accordion title="Leaked secret + reachable service + data exfiltration path">
    Fires when a secret (API key, access token, service account key) that
    Trident has flagged as potentially leaked — via TruffleHog, gitleaks,
    or your CI scanner — also has a reachable service endpoint and a
    permission path to sensitive data. The leaked credential is the
    initial foothold; the graph provides the rest of the chain.
  </Accordion>

  <Accordion title="Additional rules">
    Trident ships six named rules in total. Additional patterns cover:
    workload identity privilege escalation, Kubernetes RBAC misconfigurations
    that expose cloud credentials, and cross-account role assumptions that
    bridge security boundaries. New rules are added as the threat landscape
    evolves.
  </Accordion>
</AccordionGroup>

## Exploitability verification

Before surfacing an attack path to you, Trident confirms that the path is actually exploitable — not just theoretically possible — using a **read-only IAM policy simulation**.

Trident calls `iam:SimulatePrincipalPolicy` with the source identity and the target resource's required actions. If the simulation returns `allowed`, the path is confirmed and ranked accordingly. If the simulation returns `denied` (e.g. because an SCP blocks the action), Trident lowers the confidence score or suppresses the path entirely.

This step prevents alert fatigue from theoretical paths that your environment's actual policies already block.

## Viewing attack paths

Open **Cloud → Attack Paths** in the [Trident dashboard](https://app.usetrident.dev). Each path card shows:

* **Involved assets** — every node in the chain, with resource type and ARN
* **Attack chain steps** — the ordered sequence of edges traversed, labeled with edge kind and the predicate that fired (e.g. "agent runs as `arn:aws:iam::…:role/AgentRole`")
* **Blast radius** — the set of data stores or identities reachable if the path is exploited
* **Confidence score** — a 0–100 score reflecting IAM simulation result, data sensitivity, and path length

Click any path to expand the full explain view, including which toxic combo rule fired and the specific policy simulation result.

## Prioritization

Trident ranks attack paths by a combination of **exploit reachability** and **potential impact**:

* **Reachability** is determined by the IAM policy simulation result and the number of hops required
* **Impact** is the product of data sensitivity (LOW / MEDIUM / HIGH) and access breadth (how many sensitive resources are reachable)

Paths involving AI agents that Trident has observed handling untrusted input receive an additional severity boost, because the initial compromise step (prompt injection) requires no credential theft.

## Cloud guardrails (PREVENT layer)

For each confirmed attack path, Trident can generate **preventive policy code** that blocks the path at the infrastructure level — before an attacker ever tries to walk it.

Click **Generate Guardrail** on any attack path. Trident's Sentinel AI produces policy code in your chosen format:

<Tabs>
  <Tab title="Kyverno">
    ```yaml theme={null}
    # Auto-generated by Trident Sentinel — AUDIT mode
    # Blocks: agent_injection_priv_role (rule: no-priv-role-for-agent-workloads)
    apiVersion: kyverno.io/v1
    kind: ClusterPolicy
    metadata:
      name: trident-no-priv-role-agent-workload
      annotations:
        trident.espritlabs.com/rule: agent_injection_priv_role
        trident.espritlabs.com/mode: audit
    spec:
      validationFailureAction: Audit
      rules:
        - name: restrict-agent-service-account-role
          match:
            resources:
              kinds: [Pod]
              namespaces: ["ai-agents"]
          validate:
            message: "Agent pods must not use a service account bound to a privileged IAM role."
            deny:
              conditions:
                - key: "{{ request.object.metadata.annotations.\"eks.amazonaws.com/role-arn\" }}"
                  operator: AnyIn
                  value: ["arn:aws:iam::*:role/*Admin*", "arn:aws:iam::*:role/*Priv*"]
    ```
  </Tab>

  <Tab title="Conftest / Rego">
    ```rego theme={null}
    # Auto-generated by Trident Sentinel — AUDIT mode
    # Blocks: over_permissioned_public_exposure
    package trident.cloud.guardrails

    import future.keywords.if

    deny[msg] if {
      input.resource.type == "aws_security_group"
      rule := input.resource.change.after.ingress[_]
      rule.cidr_blocks[_] == "0.0.0.0/0"
      rule.from_port == 0
      rule.to_port == 65535
      msg := sprintf(
        "Security group '%v' allows unrestricted ingress — flagged by Trident (over_permissioned_public_exposure).",
        [input.resource.name]
      )
    }
    ```
  </Tab>

  <Tab title="CloudFormation Guard">
    ```
    # Auto-generated by Trident Sentinel — AUDIT mode
    # Blocks: leaked_secret_reachable_service
    rule trident_no_public_secret_access {
      AWS::SecretsManager::ResourcePolicy {
        Properties {
          ResourcePolicy.Statement[*] {
            Principal != "*"
            <<Trident: secrets must not have wildcard principal (leaked_secret_reachable_service)>>
          }
        }
      }
    }
    ```
  </Tab>

  <Tab title="Cloud Custodian">
    ```yaml theme={null}
    # Auto-generated by Trident Sentinel — AUDIT mode
    # Blocks: agent_injection_priv_role
    policies:
      - name: trident-flag-agent-priv-role
        resource: iam-role
        mode:
          type: periodic
          schedule: "rate(1 hour)"
        filters:
          - type: value
            key: RoleName
            op: regex
            value: "^(AgentRole|LLMRole|AIServiceRole).*"
          - type: has-allow-all
        actions:
          - type: notify
            to: ["security@yourorg.com"]
            subject: "[Trident] Privileged agent role detected"
    ```
  </Tab>
</Tabs>

All generated guardrails run in **AUDIT mode** by default — they log violations without blocking traffic. Review the policy, test it against your environment, then switch to ENFORCE when you are confident it will not disrupt legitimate workloads. See [Remediation](/cloud/remediation) for the full fix workflow.