Finds the common cost and security problems in an AWS account: forgotten spend, and the defaults that actually cause incidents. Read-only, runs locally, covers every region. Usable as a library, a CLI, or an MCP server your agent can drive.
It answers the questions you'd check by hand if you had the afternoon: is anything public that shouldn't be, does root have MFA, which access keys have never been used, what's still billing that nobody is using.
It cannot change anything. Every call it makes is a Describe*, List* or
Get*. There is no code path that creates, modifies or deletes an AWS resource,
and no dependency that could add one — see Read-only by construction.
Point it at your own account with your own credentials. Nothing is sent anywhere, and nothing is stored.
Tool | Finds |
| Stopped instances still billing for their EBS volumes |
| Volumes attached to nothing, billed at full rate |
| Buckets exposed by ACL or policy, and buckets missing Block Public Access |
| Sensitive ports open to |
| Root access keys, root without MFA, users without MFA, keys never used or unused for 90+ days |
| Whether anything is actually being logged, and whether it covers all regions |
| Forgotten EC2/EBS/RDS resources in regions you've stopped thinking about |
Every tool returns structured findings — severity, the specific resource id, why it matters, and the console and CLI steps to fix it — so the output is usable by a program, not just readable by a person.
Related MCP server: cyntrisec
npm install
npm run buildRequires Node 22+.
Add it to any MCP client. For Claude Desktop, in
claude_desktop_config.json:
{
"mcpServers": {
"aws-audit": {
"command": "node",
"args": ["/absolute/path/to/aws-audit-scanner/dist/index.js"],
"env": { "AWS_PROFILE": "your-profile" }
}
}
}Then ask your agent to audit the account. It calls the tools it needs and reasons across the results.
import { scanIam } from 'aws-audit-scanner/dist/tools/scan-iam.js';
const result = await scanIam({ region: 'eu-west-1' });
if (result.ok) {
for (const finding of result.findings) {
console.log(`[${finding.severity}] ${finding.title}`);
}
}Every tool returns a Result-shaped value ({ ok: true, findings } or
{ ok: false, error }) rather than throwing, because a single denied permission
should degrade one check rather than fail the whole audit.
The tools use the ambient AWS credential chain — profile, environment, instance role, whatever the SDK resolves. Nothing is read from a config file of ours and nothing is stored.
To audit a different account, assumeAuditRole wraps STS with an external ID:
import { assumeAuditRole } from 'aws-audit-scanner/dist/assume-role.js';
const assumed = await assumeAuditRole({
roleArn: 'arn:aws:iam::111122223333:role/YourAuditRole',
externalId: 'the-id-the-role-requires',
region: 'eu-west-1',
});
if (assumed.ok) await scanIam({ region: 'eu-west-1', credentials: assumed.credentials });Sessions are short-lived by design.
A promise in a README is worth very little, so this is enforced in three places:
The code. Only Describe*, List* and Get* commands are imported from
the AWS SDK. Grep for it — there is no Create, Put, Delete, Update,
Terminate, Stop, Start, Modify, Attach or Detach command in the
source.
The IAM policy. The role the hosted service asks customers to deploy is
published in full at
whatsinmycloud/readonly-role —
the literal file, not a summary. PERMISSIONS.md in this repo explains why
each permission is needed.
The trust policy. That role can only be assumed by one named role, in one named account, gated by a server-issued external ID. It is not assumable by anyone who merely learns its ARN.
If you're evaluating whether to point this at an account you care about: read
src/tools/. Each file is short, and the scan logic is the whole story.
Pagination is handled. Every list call follows its continuation token.
Worth stating because it wasn't always true here: IAM's ListUsers defaults
MaxItems to 100 when you omit it, and the docs warn it may return fewer
even when more exist — so the count is never an end-of-list signal. An
unpaginated scan of a 150-user account reported two users without an MFA
device with complete confidence, while never looking at the other 50. A wrong number in a security report is
worse than a missing one, because nothing signals that it's wrong. The EC2
calls are paginated defensively rather than because a bug was demonstrated —
DescribeSecurityGroups documents that omitting MaxResults returns
everything. src/paginate.ts has the mechanics, and
src/tools/ugly-account.test.ts fails the build if a first-page-only
regression ever creeps back in. The paginator fails closed: if a
continuation token repeats, or a response says it is truncated but carries no
marker, it throws rather than returning what it has. Each scan turns that
into an explicit failure for that check, so a partial list can never be
mistaken for a complete one.
Region discovery is a presence probe. discover.ts checks every enabled
region cheaply and deep-scans the ones with resources. region-sweep.ts
deliberately reads only the first page — it answers "is there anything here?",
not "what exactly is here?".
Costs are estimates. EBS pricing is approximated from volume type and size. Treat the figures as an order of magnitude for prioritising, not a bill.
Not covered yet: Lambda, ElastiCache, NAT Gateways, unattached Elastic IPs, old snapshots. All are real sources of forgotten spend; none are implemented.
npm test # unit tests, no AWS calls — the SDK is mocked
npm run typecheck
npm run buildTests use aws-sdk-client-mock,
so the suite runs offline and never touches an account. New checks want a test
covering the interesting shape, not just the happy path — the bugs worth having
tests for here have all been about accounts that were bigger or messier than the
one the author was looking at.
Issues and pull requests welcome. A new scan tool needs: a ScanResult-returning
function in src/tools/, a registration in src/index.ts, and tests. Keep the
read-only guarantee absolute — a pull request that introduces a mutating AWS
call will be declined regardless of how useful it is.
WhatsInMyCloud runs this scanner and adds prioritised plain-English reports and weekly monitoring on top. That layer is not open source; everything that touches an AWS account is in this repo.
If you'd rather not run anything yourself, that's the hosted version. If you'd rather read the code and run it locally, that's this.
MIT — see LICENSE.
Check if CloudTrail logging is enabled and covering all regions.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | AWS region to scan, e.g. eu-west-1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only check but does not state whether it returns a boolean, a report, or what happens if logging is not configured. It also does not clarify whether the check is per-region or across all regions, which is ambiguous given the 'covering all regions' phrasing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any filler. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should clarify the return value and how the region parameter affects the check. It does not specify whether the tool returns a simple yes/no, a list of regions missing logging, or a detailed report. The interaction between the 'region' parameter and 'all regions' is unclear, leaving significant gaps for an agent to make correct calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'region' parameter with an example, providing 100% schema description coverage. The description adds no additional parameter details, so it meets the baseline for tools with well-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Check') and resource ('CloudTrail logging'), and specifies the scope ('enabled and covering all regions'). This distinguishes it from sibling tools that target EC2, EBS, S3, security groups, and IAM, so an agent can easily identify this as the CloudTrail check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without mentioning prerequisites, conditions, or comparisons to sibling tools like scan_s3_public_access or sweep_other_regions. An agent has to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find IAM issues: root access keys, missing MFA, stale access keys.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | AWS region to scan, e.g. eu-west-1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'find' suggests a read-only operation, but the description does not explicitly state that the tool makes no changes, what AWS permissions are required, whether it can return partial results, or any rate-limit implications. For a scanner, this lack of explicit behavioral disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence, front-loaded with the main action ('Find IAM issues') and immediately followed by concrete examples. There is no fluff, repetition, or irrelevant detail; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects) and the description lists the kinds of findings, which is helpful. However, there is no output schema and the description does not explain what the tool returns (e.g., a list of findings, severity levels, or a summary). An agent knows what it scans but not what it will receive, leaving a moderate completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'region' parameter, and the schema already explains it ('AWS region to scan, e.g. eu-west-1'). The description adds no additional parameter-level meaning, but the schema fully carries that burden, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Find') and resource ('IAM issues'), then enumerates concrete examples (root access keys, missing MFA, stale access keys). This clearly distinguishes it from sibling scan tools like scan_stopped_ec2 and scan_s3_public_access, which target other AWS resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the scan_* sibling family and the description's focus on IAM-specific checks, but there is no explicit when-to-use statement, no mention of when not to use it, and no reference to alternatives. An agent must infer that this is the IAM scanner rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find S3 buckets that are publicly accessible or missing guardrails.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | AWS region to scan, e.g. eu-west-1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of explaining behavior. It only states 'find' and does not disclose whether the tool performs API calls, requires specific AWS permissions, or what 'missing guardrails' includes (e.g., encryption, logging, versioning). It also does not clarify if any side effects or costs occur, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that states the purpose without filler. The core functionality is front-loaded and immediately understandable, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, so the description is the sole source of context. It explains what the tool scans for but leaves 'missing guardrails' undefined and does not describe the expected result format or prerequisites. Adequate for a simple scan tool, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the region parameter is already well described in the schema. The tool description adds no extra parameter-level insights, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (S3 buckets), the action (find), and the specific target condition (publicly accessible or missing guardrails). It distinguishes itself from sibling scan tools by explicitly naming S3, so an agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool when checking S3 public access or guardrails, but it provides no explicit trigger conditions, prerequisites, or alternatives. Sibling scans are clearly different resources, so an agent can infer the appropriate use case, yet no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find security groups with dangerous ports open to the internet.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | AWS region to scan, e.g. eu-west-1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It only states the action and leaves out key behavioral details: whether the scan is read-only, what output it returns, how it defines 'dangerous ports', or any AWS permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler or repetition. It front-loads the key action and target, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too sparse. It does not explain what the scan returns, what defines a dangerous port, or whether there are any side effects, leaving an agent to guess at runtime behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'region' parameter is clearly described in the schema with an example. The description adds no parameter-specific details, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Find') and a specific resource ('security groups') with a precise filtering criterion (dangerous ports open to the internet). This distinguishes it from sibling tools like scan_iam or scan_s3_public_access, which target different AWS resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: if an agent needs to find security groups exposing dangerous ports, this is the tool. However, the description gives no explicit when/when-not guidance and does not reference alternatives, relying solely on the tool name and sibling list to set context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find stopped EC2 instances still incurring EBS costs.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | AWS region to scan, e.g. eu-west-1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It tells the agent the tool finds instances, suggesting a scan/read operation, but it doesn't disclose whether it performs any mutations, requires specific AWS credentials/permissions, or what the output looks like (e.g., a list of instance IDs and costs). Without annotations, this is a significant gap for a tool that likely accesses AWS.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, efficient and focused on the core purpose. It gets to the point quickly and doesn't waste characters on filler. However, it could be slightly more helpful with additional context about the cost aspect, but for what it is, it's appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema (one param) and no output schema, so the description needs to be the main source of information. The description tells why to use it ('incurring EBS costs') but doesn't cover what the tool returns (list of instance IDs? total costs? a report?), how it behaves (does it only scan a single region?), or any prerequisites (like needing describe permissions). This is insufficient for an agent to fully understand the tool's output and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the single parameter 'region' is well-documented in the schema itself (type and example). The description doesn't add extra meaning about the region beyond what's in the schema, such as whether multiple regions are supported or if 'all' is a wildcard. Since the schema does its job, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'find' and resource 'stopped EC2 instances' with a specific purpose ('still incurring EBS costs'). It stands out from siblings which target different resources (EBS, S3, security groups, IAM, CloudTrail), so an agent can likely distinguish it. However, it doesn't explicitly say it only lists instances (no action) and the word 'scan' in the name implies a read-only operation, which is clear enough but not as specific as some alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you need to identify cost-incurring stopped instances. However, it doesn't provide explicit guidance on when not to use it or direct to alternatives, such as using scan_unattached_ebs for volume-level costs or other scan tools for different resource types. The usage context is clear for the intended purpose but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find EBS volumes not attached to any instance.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | AWS region to scan, e.g. eu-west-1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Find' implies a read-only scan with no modification, but the description never explicitly states that it does not modify resources, what permissions are needed, or what form the results take. It discloses the filtering behavior but leaves the safety profile implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single eight-word sentence with no filler. The action and object are front-loaded, and every word adds meaning. For a tool with one parameter, this is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and invocable: one required parameter, fully documented in the schema. However, there is no output schema and no annotations, and the description does not mention return format, read-only guarantee, or pagination. It is adequate for basic invocation but not fully complete for setting expectations after the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, region, is already documented with type and an example ('eu-west-1'). The description adds no additional parameter semantics, but the schema fully covers the single parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with a specific verb ('Find') and names the exact resource ('EBS volumes') plus the filtering criterion ('not attached to any instance'). It clearly distinguishes the tool from siblings like scan_stopped_ec2 and scan_s3_public_access, which target different AWS resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: identify orphaned EBS volumes, likely for cleanup or cost analysis. However, the description gives no explicit when-to-use guidance versus sibling scan tools, and no exclusions such as 'does not check volumes attached to stopped instances'. The sibling list provides context, but the description itself doesn't route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Presence-check every other enabled region for forgotten EC2/EBS/RDS resources.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | AWS region to scan, e.g. eu-west-1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, whether it modifies anything, what the return format is, or any rate limits or region-specific behaviors. The term 'presence-check' suggests a listing operation, but this is not confirmed, and the meaning of 'forgotten resources' is left undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise in length, but the ambiguity in 'every other' and the undefined 'forgotten' reduce its effectiveness. It is not front-loaded with the most critical clarifying information (e.g., what the region parameter does).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must cover return behavior and side effects. It does not explain what the tool returns (e.g., a list of resources, a summary count), whether it is safe to run repeatedly, or how the region parameter affects the scan. For a multi-region sweep, this is insufficient for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'region' parameter as 'AWS region to scan', which conflicts with the tool description's 'every other enabled region'. The description does not clarify whether the parameter is the region to exclude, the starting region, or the only region scanned. With 100% schema coverage, the schema does provide a basic description, but the tool description introduces ambiguity, making the parameter's actual role unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('presence-check') and resource scope (EC2/EBS/RDS) across multiple regions, distinguishing it from sibling tools that target specific resource types. However, the phrase 'every other enabled region' is ambiguous—does it mean all regions except the one passed in the 'region' parameter, or all regions including it? This uncertainty reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the specific sibling scans (e.g., scan_stopped_ec2). It does not mention whether this should be a first pass before drilling into specific resources, or if it is a standalone audit. No exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0scan_cloudtrailscan_iamscan_s3_public_accessscan_security_groupsscan_stopped_ec2scan_unattached_ebssweep_other_regionsScored across 7 tools
Each tool targets a distinct AWS resource or audit concern (EC2, EBS, S3, security groups, IAM, CloudTrail, region sweep), with no overlapping purposes. The descriptions are specific enough to guide an agent to the correct tool without confusion.
All tools follow a consistent 'scan_<resource>' or 'sweep_<scope>' pattern, with scan_ used for the six core checks and sweep_ for cross-region discovery. This is a predictable and uniform convention that makes the tool set easy to navigate.
With 7 tools, the set is well-scoped for an AWS audit scanner, covering the major cost and security risk areas without overwhelming the user. Each tool corresponds to a distinct audit category, and the count is within the ideal range for a focused server.
The surface covers key AWS cost and security risks (stopped EC2, unattached EBS, S3 public access, security group exposure, IAM hygiene, CloudTrail coverage, and forgotten resources in other regions). Minor gaps include lack of checks for RDS snapshots or Lambda misconfigurations, but the core audit scope is well covered.
Lowers your AWS bill by helping you clean up and optimize your setup
AWS cloud security scanners for AI agents — S3, IAM, EC2, EKS, RDS, CloudTrail, CloudWatch Logs
IaC attack-path auditor: finds internet-to-crown-jewel chains in Terraform/CFN/K8s.
CloudOracle - 14-tool multi-cloud compliance MCP: AWS, Azure, GCP posture, IAM, configs.