Managing AWS with AI: From Risky to Safe
Anyone who has opened the AWS console knows the feeling. Hundreds of services, dozens of ways to misconfigure each one, and a bill that punishes every mistake. Handing that work to an AI agent sounds appealing. In a recent video, Maximilian Schwarzmüller of Academind ranks the approaches to managing AWS with AI from reckless to genuinely safe. The gap between the two ends is wider than most beginners expect, and it comes down to permissions rather than prompts.
The Riskiest Options Are Also the Easiest
The worst approach is computer use. You log into the console, hand the browser to an agent, and let it click around. It works. It is also slow, burns a surprising number of tokens, and gives the model everything your logged-in session can reach.
Pointing an agent at the AWS CLI with your own IAM or SSO profile feels tighter. It isn’t. Asking for a read-only summary does not guarantee a read-only path. An agent might decide the fastest way to produce your VPC report is to spin up a Lambda function and analyze the account from there. You get your answer. You also get the invoice. That isn’t malice — the model has no intentions — it is a system finding a route you never sanctioned.
Dedicated Roles Beat Dedicated Users
Roles expire, users don’t
IAM users are permanent. Roles are temporary. Create a role the agent assumes, and its credentials go stale within hours. Agents genuinely do read secret keys and paste them into their own sessions, so that expiry window matters. Short-lived credentials are usually worthless by the time anyone else finds them.
Read-only is not the same as safe
AWS ships a broad read-only policy, and it is tempting to stop there. Schwarzmüller pushes back hard on that. Read-only still means read everything, including whatever sits in your S3 buckets. A prompt injection turns that into an exfiltration path. Narrower policies work better. His EC2 example restricts the agent to cheap instance types, so a runaway agent cannot provision something expensive. If writing IAM JSON sounds miserable, ask an agent to draft the policy and read it yourself before applying it.
CLI, MCP, or Code — and What the Agent Toolkit Changes
An agent can touch AWS three ways: the CLI, an MCP server, or a script written against the AWS SDKs. All three need credentials, so none of them removes the permission problem. The MCP route adds one genuinely useful lever, though. IAM can tell whether a call arrived through MCP, which lets you write deny rules that apply only to agents. Deny always wins in AWS, so those rules hold.
AWS has since formalized this. The Agent Toolkit for AWS is now the official successor to the MCP servers, skills, and plugins that previously lived under AWS Labs. The managed AWS MCP Server reached general availability in May 2026, and it brings CloudWatch metrics, CloudTrail logging for every request, sandboxed Python execution, and the aws:ViaAWSMCPService and aws:CalledViaAWSMCP IAM context keys. Installation runs through aws configure agent-toolkit. If you are choosing between CLI and MCP today, the audit trail alone makes MCP the stronger default.
Infrastructure as Code Is the Safest Way of Managing AWS with AI
The safest options skip live account access entirely. Instead of letting an agent call APIs, you let it write infrastructure as code. That might be a CloudFormation template in YAML, or Terraform, or Pulumi and Alchemy if you would rather define resources in TypeScript.
The agent then produces a reviewable artifact rather than a side effect. Schwarzmüller splits this into two tiers. In the safe version, you review the template and the agent deploys it. In the safest version, you review it and you deploy it yourself. Either way, nothing reaches production until a human has read it.
Key Takeaways
- Computer use is the worst option because it is slow, expensive, and hands the agent everything your browser session can reach.
- Giving an agent your own IAM or SSO profile offers no real guarantee, because agents find creative routes to a goal and you pay for the detour.
- Temporary roles beat permanent users, since leaked credentials expire before they can do much damage.
- A read-only policy is not a secure policy, because reading everything is exactly what data exfiltration needs.
- Having an agent generate infrastructure as code, then reviewing and deploying it yourself, keeps the productivity while removing the blast radius.
Conclusion
The question was never whether to let AI near your cloud account. It is how much rope you hand it. Every step from computer use toward reviewed templates trades a little convenience for a lot of control. Pick the point on that spectrum your risk tolerance can defend, and let permissions do the enforcing rather than your prompt.
