Free, read-only, runs on your machine

Can your agents spend, reach, or act without a record? Find out in five minutes.

One Python file. It reads your AWS account with your own credentials, never writes, and prints what an autonomous agent running there could get away with: a loop that bills until someone notices, a role that reaches further than intended, logs that could not prove afterwards what happened.

Download the check What it does, exactly ›

Nothing leaves your machine unless you open the link the report prints, and that link carries only a score, a size class and finding ids.

agent_readiness_check.py read-only

$ python3 agent_readiness_check.py

score     13/100   class small   regions 1

spend  [critical] No AWS Budget exists
reach  [critical] Root has no MFA
       [high    ] 2 access keys older than 90 days
proof  [critical] No CloudTrail trail
       bedrock: no invocations in 90 days, not assessed

nothing above has left your machine

What it does

Twenty read-only API calls, three questions.

The file is short enough to read before you run it, and --calls lists every API it touches. It needs the ReadOnlyAccess managed policy or less.

SPEND

Is there a limit that actually stops an agent?

Budgets that only email are not a limit. It looks for a budget with an action, and for a billing alarm as the earliest warning. Ninety seconds on why.

REACH

Can an agent go further than it was meant to?

Root without MFA, long-lived keys nobody rotates or uses, and agent-looking roles carrying administrator power.

PROOF

Could you prove afterwards what it did?

CloudTrail present, multi-region and integrity-validated; the log bucket protected from silent deletion; Bedrock invocation logging and guardrails; GuardDuty and Config.

Who runs it, and what it needs

An engineer with read access to the account. It uses whatever credentials the AWS CLI already has on that machine: a profile, an SSO session, environment variables. Nothing is typed into it. The report is written to be forwarded to whoever decides.
Python 3 and boto3. That is the whole dependency list.
The regions your agents run in, with --regions. The default is us-east-1 and us-west-2, which is wrong for most of Europe; pass yours.
One account per run. An organisation with several runs it once per account that runs agents; the results do not combine.
Services you do not use are not scored. Bedrock checks apply only where CloudTrail shows Bedrock has been invoked in the last 90 days; otherwise they are reported as not assessed and carry no weight in the score or the fee.

Why you should not have to trust it

Give it a role that can only read. This CloudFormation template creates a role allowing exactly the twenty calls the check makes and nothing else. Run the check through that role and the worst a hostile copy of the file could do is read. --policy prints the same policy for any other tooling.
Watch what it does. --audit-log calls.log appends every API call as it is made, service and operation, so the read-only claim is checked from outside the script rather than stated inside it.
Check the file is the file. SHA-256 of the download: ce3b809f0a63cd692a6787d00efd56abd44b24979995e72494eae6af3a1e9a27. The verifier this check sits beside, with its history and tests, is at github.com/abacross/agent-journal; our own journal, every production action this company has taken, is at github.com/abacross/ops-journal and verifies with it.
Read it. It is one file, about 400 lines, and half of them are the words on this page.
The fixes are public too. Every finding class with an infrastructure fix names its CloudFormation template, linted, with cost and reversal stated inside: spend-limit, proof-trail, detect, bedrock-proof and agent-boundary. Apply them yourself; the audit is for the judgment about your account, not the YAML.
Then keep the record. The proof finding is fixed for good by a journal the agent cannot rewrite: the attestation service, which keeps ours.

pip install boto3
python3 agent_readiness_check.py --regions us-east-1,eu-west-1 --html report.html --audit-log calls.log

Each finding comes with its evidence, its blast radius in plain words, and the fix. The score is 100 minus 20 per critical, 10 per high, 5 per medium, 2 per low. Keep the --json report; run again after fixing with --baseline first.json and it prints what changed instead of a second wall of findings.