Skip to main content
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.
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.

​
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 kindMeaning
assumes_roleAn identity or workload can assume this IAM role
grantsA role or policy grants permissions to this resource
reachesNetwork reachability between two resources
storesA workload writes data to this data store
mountsA container mounts this volume or secret
runsA 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

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.
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.
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.
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.

​
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. 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: 
# 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*"]
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 for the full fix workflow.