Linking an AWS account

Give your agent AWS credentials and it can build and operate real infrastructure on your behalf — deploy a site, stand up a database, read CloudWatch to diagnose an incident. This is optional: an agent with no AWS credentials still writes code, works your repositories, and answers questions.

⚠ Note:These keys let the agent act in your AWS account. Scope them deliberately, and read the permissions section below before you decide what to grant. If you are evaluating the platform, use a brand-new AWS account with a billing budget rather than the one running your production workloads.

Use a dedicated IAM user, not your own

Create a separate IAM user whose only purpose is to be your agent's identity. That keeps the agent's activity legible in CloudTrail, and lets you revoke it without disturbing anything else.

In the AWS console, open IAM → Users → Create user.
Name it after the agent so the audit trail reads clearly — e.g. isomorph-agent.
Do not enable console access. The agent uses access keys only; a password is one more thing to leak.
Attach permissions using one of the approaches in the next section.
After creating the user, open it and choose Security credentials → Create access key. Pick Application running outside AWS.

You will be shown an Access key ID and a Secret access key. The secret is displayed once and never again.

Decide what it may do

There is a real trade-off here and it is worth two minutes of thought. An agent can only do what its credentials permit — which cuts both ways.

Approach	Good for	Cost
`ReadOnlyAccess`	Diagnosis, audits, cost analysis, “why is this broken”	Cannot build or fix anything
Scoped write	Day-to-day building within named services (S3, Lambda, CloudFront…)	You maintain the policy as needs grow; the agent will hit walls
`PowerUserAccess`	Open-ended building in a dedicated or sandbox account	Broad blast radius — pair with a budget and a separate account

Most people start with ReadOnlyAccess to build confidence, then widen. Whatever you choose, avoid AdministratorAccess: it includes IAM, which means the credential can silently grant itself anything else.

ℹ Info:Start narrow. It is far easier to add a permission when the agent tells you it was denied than to work out afterwards what a broad credential touched.

Dangerous shortcut — proceed with caution

For a brand-new, empty AWS account only.

Scoping permissions properly takes time, and when you are starting from nothing there is nothing yet to protect. If you have created a fresh AWS account specifically for your agent to build in, you can hand it full control and get out of its way:

Create the IAM user as described above, in an AWS account that contains nothing you would miss.
Attach the AWS managed policy AdministratorAccess.
Set a monthly budget alert first — see the next section. This is the only guardrail left, so do not skip it.
Create the access key and supply it to your agent.

The agent can now provision anything: networks, databases, clusters, DNS. For greenfield building this removes nearly all friction, and the blast radius is an account you were prepared to throw away.

Do not do this on an account that runs anything.

If the account holds production systems, customer data, other teams' work, or anything you would have to explain the loss of, this shortcut is the wrong trade. AdministratorAccess includes IAM, which means the credential can rewrite its own permissions and every other principal's — so no other control in the account meaningfully constrains it. It can also delete resources, and an agent acting on a misunderstanding is as capable of DeleteDBInstance as of CreateBucket.

For an account with existing systems, spend the time on scoping instead: name the services the agent may touch, keep IAM out of its reach, and read Building on AWS with an agent for how to keep its changes reviewable and reversible.

⚠ Note:A common middle path: give the agent its own empty account to build in, then move the finished, reviewed infrastructure into your real account yourself. You keep the speed without ever pointing a broad credential at something that matters.

Put a spending guardrail in place first

An agent building infrastructure can create billable resources. Before you hand over write access, set up a guardrail so a mistake is visible in hours rather than on next month's invoice.

Open Billing and Cost Management → Budgets → Create budget.
Create a monthly cost budget at a number that would make you look, and add an alert at 50% and 100% to an address you actually read.
If this is a sandbox, consider a separate AWS account entirely. Account boundaries are the only hard isolation AWS offers.

Supply the keys to your agent

Enter the access key ID and secret access key during onboarding, or add them later from your agent's Credentials panel in the console. Include the default region you want the agent to work in.

They are written straight into your agent's own encrypted secret in AWS Secrets Manager and injected as environment variables into each task. They are never written to logs, never stored in the request record, and never shared with another tenant's agent. See Security for how that isolation is enforced.

ℹ Info:Adding or changing credentials takes effect on the agent's next task. Ask it to run something that touches AWS — “list my S3 buckets” is a good first check that the keys landed.

Rotating and revoking

Rotate on whatever schedule your policy requires, and immediately if you suspect exposure. IAM allows two active access keys per user, which makes rotation a no-downtime operation:

Create a second access key on the same IAM user.
Update the credential in your agent's Credentials panel.
Confirm the agent can still reach AWS, then deactivate — and afterwards delete — the old key.

To cut access off entirely, deactivate the access key in IAM. That takes effect immediately and does not require any change on the platform side. Deleting the agent also destroys its secret.

Next: Building on AWS with an agent · Your other credentials