Building Internal Tools with AI Agents Without Giving Them Your AWS Keys

An agent building an expense approval tool will reach a point where the code works locally and the next step is AWS. If there is an access key in ~/.aws/credentials, a capable agent will use it, because nothing tells it not to. That key usually belongs to a developer with broad rights, so the agent can now do anything that developer can do in the account.

This guide looks at what that exposes and at two ways to keep the agent productive without it.

Where cloud access sits

What an access key on the laptop exposes

An access key is not scoped to a task. When Claude Code runs aws commands, it runs them with the developer's identity, and Claude Code's permission settings can allow or deny tools but cannot tell which IAM actions a shell command will make. The OWASP entry on excessive agency describes this failure mode: the model has more permission than the task needs, so a wrong step has real effects.

For internal tools the risk is sharper, because the tool exists to reach business data. An agent wiring a dashboard to the orders database with an admin key can also modify the security group that protects it.

Narrowing access on plain AWS

The standard approach follows AWS IAM best practices: temporary credentials through roles instead of long-lived keys, with least privilege as NIST defines it. In practice:

1. Remove static keys from developer machines and use short sessions through IAM Identity Center.
2. Keep infrastructure in a separate folder and let only CI apply it, with a role assumed through GitHub OIDC.
3. Give the CI role permission for the resource types internal tools use, and require a plan review before apply.
4. Tell the agent in CLAUDE.md or AGENTS.md that it writes infrastructure code but never runs apply.

This works and many teams run it, although every internal tool needs infrastructure code that someone reviews, and the agent writes IAM policies and networking it cannot test before CI runs. The rules file is guidance only, so a key that is still on the machine remains usable.

Encore: the agent changes code, Encore's role changes AWS

Encore combines an open source SDK, in which a TypeScript or Go service states the databases, topics, cron jobs and secrets it uses, with a platform that provisions those resources in your own AWS account when you deploy. The agent edits the service and runs it locally rather than calling AWS:

// expenses/expenses.ts
import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { getAuthData } from "~encore/auth";

const db = new SQLDatabase("expenses", { migrations: "./migrations" });

export const approve = api(
  { expose: true, auth: true, method: "POST", path: "/expenses/:id/approve" },
  async ({ id }: { id: number }): Promise<void> => {
    const user = getAuthData()!;
    await db.exec`
      UPDATE expenses SET status = 'approved', approved_by = ${user.userID}
      WHERE id = ${id} AND status = 'pending'`;
  },
);

encore run starts Postgres locally and applies the migrations, so the agent can test the endpoint end to end with no cloud account at all. Since the database is part of the service code, the agent adds it in the same change as the endpoint and verifies both before anyone reviews them.

When the change is pushed, Encore connects to your AWS account through an IAM role you grant it, provisions RDS and the compute, and gives each service an IAM role limited to the resources it uses.

You can require manual infrastructure approval for an environment, so an Admin sees the new resources before they exist. Roles in Encore decide who can approve infrastructure and who can connect cloud accounts.

The agent keeps the same local power as the developer, while cloud access sits with Encore's IAM role, not the agent.

Good to know

The agent can still read local secret values on the developer's machine, so keep production values on the production environment type. The IAM role you grant Encore needs permission to provision and manage infrastructure in that account, so the setup Encore suggests is a dedicated AWS account or sub-organization for it.

How to choose

• Encore when you want agents to build and ship internal tools without anyone writing IAM policies, and you want the AWS role held by the platform.
• Scoped IAM on plain AWS when you already have a reviewed infrastructure pipeline and want internal tools to go through it.

Related guides

• Building an internal admin dashboard with Claude Code on AWS
• How to let AI agents deploy to AWS
• How to give AI coding agents real infrastructure
• How to give AI coding agents access to cloud infrastructure safely
• Best infrastructure for AI coding agents
• How to handle API keys and secrets on AWS when an AI agent writes the Code