gebalamariusz/cloud-audit

English | 简体中文
What can a hijacked AI agent reach in your AWS account, and can you prove it?
Open-source, read-only AWS security scanner. 110 checks, 64 IAM privilege-escalation methods, 31 attack-chain
rules, blast radius for any resource, and agent-blast for Bedrock Agents and AgentCore:
what a prompt-injected or credential-stolen agent can reach, with the IAM policy simulator as the witness.
Every finding ships an AWS CLI + Terraform fix . Nothing is written to your account.
30-second demo -
agent-blast -
Full scan -
What's inside -
Proof Mode -
Installation -
Documentation
Thirty seconds, no AWS account needed
The sample account is invented. Everything derived from it (attack chains, root causes, breach cost,
security graph, agent reach) is produced by the same engines a real scan uses.
With credentials, the real thing is one command and read-only. The AWS-managed SecurityAudit
policy covers every check (permissions):
agent-blast: what a hijacked AI agent can reach
An AI agent in AWS is a bundle of IAM identities: the role the agent runs as, the execution roles of
the Lambda functions behind its tools, the roles of its knowledge bases, gateways and sandboxes.
When the agent is hijacked, the attacker acts with *those* identities. agent-blast answers what
that means, per agent, under two threat models:
| Threat model | What the attacker has | What is in reach |
|---|---|---|
| **Identity takeover** | the credentials of a role the agent runs as (sandbox escape, metadata-service read, leaked session) | the full role: privilege-escalation methods, AssumeRole hops, data |
| **Behaviour takeover** | nothing but a prompt (indirect prompt injection through a document, a ticket, a web page) | what the agent's tools can do, bounded by the tools' own execution roles |
Real output for the sample agent (cloud-audit agent-blast --demo -a support-bot):
The story the output tells: the support bot itself is harmless, but a document that tricks it into
calling create-ticket runs code under a role that can pass an admin role to a new Lambda. The
search-docs tool, meant to read product docs, can also read the production database secret and
write into the backups bucket. Every line names the identity, the action and the resource, so the
fix is a policy statement, not a debate.
The same engine covers AgentCore. For the sample gateway (--demo -a tools-gw) the headline is a
cross-agent one:
What agent-blast reads (all list/get, no charge):
- **Bedrock Agents**: the agent resource role, every action group at the DRAFT version resolved to
its Lambda and the Lambda's execution role, knowledge bases resolved to their S3 data-source buckets.
- **AgentCore**: runtime role and network mode, gateway role with authorizer, policy engine and every
target (Lambda, remote MCP server, API Gateway, OpenAPI, Smithy) with its credential provider,
code interpreter and browser execution roles.
- **IAM policies** of exactly those identities (inline, attached, group), kept raw: action, resource,
effect, whether a Condition is present. Conditions are flagged, never guessed. The simulator
decides.
Then, per identity: the 64 privilege-escalation methods, AssumeRole hops through the trust graph,
and every data, secret, lateral, code-execution and model-invocation grant matched against concrete
resources. A knowledge-base bucket is always a concrete target, even behind s3:* on *, and
write access to it is reported as RAG poisoning. Anything the scanner could not read (a denied
region, a tool without an IAM identity) is a **coverage note**, never a silent pass.
--verify asks iam:SimulatePrincipalPolicy about every concrete pair, with the context an attacker
really has (no MFA on the session, TLS transport), and marks each reach PROVEN, DENIED (with the
policy layer that denied: SCP, permissions boundary) or not asserted. Output formats: tree,
json, markdown. The MCP server exposes the same report as get_agent_blast.