I Gave an AI Agent Access to My AWS Account - Here's What It Found
Source: Dev.to
I Gave an AI Agent Access to My AWS Account – Here’s What It Found
The Moment It Clicked
I asked my AI agent what OS it was running on.
It answered correctly, without me telling it anything.
That’s when I stopped thinking of it as a chatbot and started seeing it as something else entirely: an autonomous operator inside my cloud environment.
The agent is called Om. I built it using the open‑source framework OpenClaw, deployed on an EC2 instance in AWS. Instead of logging into consoles, running CLI commands, or digging through dashboards, I just talk to it—through Telegram.
This post is a walkthrough of what I tested, what Om did, and, more importantly, what it made me think about.
What I Built and How It Works
Before the demo, a quick note on the architecture, because it matters for the security conversation later.
OpenClaw AI Agent Architecture
- Om runs on an EC2 instance in AWS.
- It can connect to messaging platforms like Telegram, WhatsApp, Microsoft Teams, Slack, so you can interact with it from whichever platform your team already uses.
- Because it runs on the EC2, it has direct access to local system state: OS details, disk usage, running processes—no external API call needed for that.
- For AWS access, it authenticates via an IAM Role attached to the EC2 instance (
openclaw-iam-role). No hard‑coded credentials, no secrets in config files—just IAM, the way it was designed to work. - Through that role, Om can reach Cost Explorer, EC2, S3, IAM, VPC, CloudTrail, and other AWS resources.
That’s the whole architecture: simple, clean, and IAM‑governed end‑to‑end.
Now, here’s what happened when I put it to work.
Test 1: System Awareness
What I asked:
- “What OS am I running?”
- “What’s my disk utilization?”
- “Which directories are consuming the most space?”
Om didn’t guess. It inspected the host directly and replied with:
- OS: Ubuntu 24.04.4 LTS (Noble Numbat), Kernel 6.17.0, running on AWS
- Disk: 57 % utilized – 4.9 GB used of 8.7 GB total
- Top offenders:
- npm global packages – 1.4 GB
- npm cache – 755 MB
- a CUDA library – 432 MB
- the Node executable – 118 MB
Unprompted, it recommended running:
npm cache clean --forceto reclaim the 755 MB cache.
That last part matters: it didn’t just report, it reasoned about the data and made a recommendation. That’s the difference between a monitoring tool and an agent.
Test 2: AWS Cost Intelligence and a Deliberate Failure
What I asked: “Check my AWS costs this month.”
Om failed – ❌ – not because it couldn’t, but because the IAM role attached to the instance lacked ce:GetCostAndUsage.
Instead of hallucinating a cost figure, Om responded with an exact explanation:
- Missing permission:
ce:GetCostAndUsage - Role name:
openclaw-iam-role - Fix: Attach the required permission (or a broader policy)
That moment of honest failure is one of the most important things I saw. An agent that knows what it doesn’t know is far more useful—and far less dangerous—than one that guesses.
I attached ReadOnlyAccess to the role and asked again.
This time Om returned:
- February bill to date: effectively $0.00
- Forecasted end‑of‑month: ≈ $0.06
- Account status: comfortably within AWS Free Tier
- Service‑level cost breakdown across EC2, S3, and others
For a team running production workloads, the same query returns real spend, broken down by service and region, without opening the AWS console once.
Test 3: Full Infrastructure Inventory
What I asked: “Give me a list of all user‑created AWS resources, exclude anything AWS creates by default.”
Normally this requires a tool like Steampipe, AWS Config, or a manual sweep across every service and region. Om did it in a single message.
(Image truncated for brevity; the original output listed every user‑created resource across all regions, grouped by service.)
Takeaways
- Direct system access + IAM‑governed AWS access = powerful, low‑friction ops.
- Honest failure is a feature. When the agent can’t do something, it tells you why instead of fabricating an answer.
- Conversational interfaces can replace many manual CLI/console steps. A single chat message can replace dozens of
awsCLI calls or console clicks. - Security still matters. The whole setup hinges on the principle of least privilege for the attached IAM role.
If you’re curious about trying this yourself, the OpenClaw repo is open‑source, and the IAM role can be scoped down to the exact services you need. Just remember: give the agent only the permissions it truly requires, and let it do the heavy lifting.
[](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fbhorawlnhhl2878kqavp.png)
It returned:
**IAM:** 7 custom users and 9 custom roles, filtered from 20+ AWS service‑linked roles it correctly excluded.
**Compute:** 1 EC2 instance in `ap‑south‑1`, with its root volume, security group, and full VPC topology (subnet, internet gateway, route table).
**Storage:** 1 S3 bucket.
But here's the flag that jumped out: Lambda‑specific IAM roles existed in the account with no corresponding Lambda functions in the region.
Om caught that and called it out – orphaned permissions, a cleanup task. Exactly what a security review would surface, and it appeared without me asking for it.
---
## Test 4: Security Audit – The Real Test
**What I asked:** “Who created this EC2 instance? When? From where? Treat this as a request from the security team.”
[](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F3zw030sw65oltce0itno.png)
Om went to CloudTrail and assembled a complete forensic report:
- **Created by:** `venkatesh`
- **Method:** Terraform 1.14.5
- **Timestamp:** February 20 2026, 15:45:26 UTC
- **Source IP:** `106.51.xx.xx`
- **Identity:** SSO‑assumed *AdministratorAccess* role via AWS IAM Identity Center
- **48‑hour activity:**
- Instance stopped Feb 20 (same IP)
- Restarted Feb 22 from a different IP (`106.51.xx.xx`), indicating the user was on a different network
- **IAM role assumed on boot:** Confirmed correct
- **IMDSv2 status:** Required ✅ – SSRF protection in place
No dashboards. No CloudTrail filter setup. No JSON log parsing. One sentence. Full chain of custody.
A security analyst using Wiz or AWS Security Hub would get most of this, but they'd need to know which dashboards to open, which filters to apply, which time ranges to set. Om assembled it from plain English.
---
## What Surprised Me Most: The Agent Respected IAM Boundaries
It failed when permissions were missing. It worked when properly authorized. That’s exactly how it should behave. ✅
But that observation opened a bigger question.
---
## The Real Conversation: IAM as an AI Control Plane
We’ve spent years designing AWS environments for humans – console users, CLI users, Terraform pipelines.
Now we’re introducing autonomous agents that can call APIs, read audit logs, inspect infrastructure, and correlate activity across services.
Most AWS accounts today were not designed with that in mind.
If an AI agent assumed the same IAM permissions many engineers casually run with today, it wouldn’t just “assist.” It could map your entire account in minutes.
That’s not a capability problem. It’s an **architecture** question.
### Think about what that means in practice:
- An over‑permissioned agent with *AdministratorAccess* isn’t just a misconfigured tool. It’s an autonomous actor with full account visibility.
- An agent scoped to read‑only, service‑specific permissions behaves predictably and safely.
- The IAM role an agent assumes is its **blast radius**.
When AI agents operate inside your cloud environment, IAM design becomes architecture, not just access control.
- **Sloppy permissions → risky agents** ⚠️
- **Precise permissions → powerful agents** 🚀
**Your IAM design is now your AI control plane.**
---
## What’s Next?
This is early. Om today handles system inspection, cost queries, resource inventory, and CloudTrail audits. The architecture is designed to expand: more AWS service integrations, smarter anomaly detection, deeper security correlation.
But the more interesting question isn’t *what* Om can do next.
**It’s, are your cloud environments ready for agents like this?**
---
## I Want to Test Your Hardest Problems
If you had direct access to Om inside an AWS account, what would you throw at it?
- Cost anomaly detection? 💰
- Security misconfiguration audit? 🔐
- Unused resource cleanup? 🧹
- Terraform drift detection? 🏗️
- Over‑permissioned IAM role analysis? 🛑
- Public exposure scan? 🌍
- Something more aggressive?
Drop your toughest CloudOps / FinOps / Security challenge in the comments. I’ll run it and share the results publicly. Let’s see how ready our architectures really are. 👀
*Om is built on **OpenClaw**, an open‑source AI agent framework. Follow me for more on cloud‑native AI agents, AWS architecture, and infrastructure engineering.*
**Connect:**
- X: [@venkatesh111](https://x.com/venkatesh111)
- YouTube: [LetUsCloud](https://www.youtube.com/@letuscloud)
- LinkedIn: [venkatesh111](https://www.linkedin.com/in/venkatesh111/)