On AWS, the account is the strongest boundary you have. AWS's own guidance on organising environments describes it as an isolation boundary for identity and access management: by default, nothing in one account can reach another. That makes the account the natural place to contain an agent.
The difficulty is that agents are useful precisely because they act across systems, and in a well-organised AWS estate those systems live in different accounts. This note describes how to let agents cross that boundary on purpose: narrowly, attributably, briefly and reversibly. It assumes the principles in Agent permissions and tool boundaries and shows how they map onto AWS.
Give the agent its own account
Run the agent's runtime — its compute, model access, logs, memory store and queues — in an account dedicated to agents, separate from the workloads it acts on. The benefits are the usual ones for multiple accounts, sharpened by what agents are:
- Blast radius. A compromised or misbehaving agent starts with access to nothing outside its own account.
- Clear ownership and cost. Model usage, compute and storage for agents are visible on their own bill, not buried in a workload's.
- Separate quotas. A runaway agent cannot exhaust the service limits of a production workload.
- Separate environments. Development and production agents live in different accounts, so a test agent cannot reach production by mistake.
Three topologies
| Topology | Shape | Suits | Watch for |
|---|---|---|---|
| Hub and spoke | Agent runtime in an agent account; a narrow role per tool in each workload account | Most organisations; one place to run and observe agents | The hub becomes valuable — protect it accordingly |
| Agent per account | The agent is deployed into each workload account from a central pipeline | Strict isolation requirements; few accounts | More copies to operate, patch and evaluate |
| Operator and customer | A service provider's account runs the agent; the customer's account holds the role | Managed services across organisations | The confused deputy problem; the customer must be able to revoke alone |
Hub and spoke is the sensible default. The rest of this note assumes it, with notes where the third topology differs.
The trust chain, link by link
1. A runtime identity with no standing reach
The agent's compute runs under an execution role in the agent account, with temporary credentials and no long-term access keys. That role can do very little by itself. In particular, it should not be the role that holds AWS write access in other accounts.
A pattern worth considering is to separate the part of the agent that reasons from the part that acts. The model-facing runtime proposes tool calls; a separate executor service, with its own role, runs the policy check, enforces limits and approvals, and is the only principal that workload accounts trust. A manipulated model can then ask for anything, but only the executor can assume a role, and only after the check has passed.
2. One narrow role per tool in each workload account
In each workload account, create a role per tool, not one broad "agent" role. Its permissions policy allows exactly that tool's actions on exactly its resources. Its trust policy names the specific executor role, not the whole agent account, and requires a source identity.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "OnlyTheOrdersExecutor",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111111111111:role/agent-executor-orders" },
"Action": ["sts:AssumeRole", "sts:SetSourceIdentity"],
"Condition": {
"StringLike": { "sts:SourceIdentity": "agent-orders-*" }
}
},
{
"Sid": "AllowSessionTags",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111111111111:role/agent-executor-orders" },
"Action": "sts:TagSession"
}
]
}Cross-account access always needs both sides: the trust policy in the workload account, and an identity policy on the executor role allowing it to assume that specific role. Neither alone is enough.
In the operator-and-customer topology, the customer's role trusts the operator's account and requires an external ID in the trust policy. AWS's guidance is specific: the operator generates a unique external ID per customer and always passes it, and it is not a secret — its purpose is to stop the operator being tricked into using one customer's role on another customer's behalf, the confused deputy problem.
3. Scope each session to the task
When the executor assumes a role, it can narrow the session further.
- Source identity. Set it to the agent and the task, for example
agent-orders-followed by the task identifier. AWS records it in CloudTrail for every action in the session, carries it through any further role assumptions, and does not allow it to be changed during the session. - Session name. Use the tool-call or task identifier; it appears in the assumed-role ARN in every log entry.
- Session tags. Pass the mission and the autonomy level as tags, and use them in policy conditions.
- Session policies. Pass a policy that narrows the role to the resources of this task. A session policy can only remove permissions, never add them.
4. Keep sessions short
Request the shortest duration the task needs and assume the role again for the next step, rather than holding credentials for hours. AWS limits sessions obtained through role chaining to one hour regardless of the role's setting; design for that rather than against it.
5. Data planes need both sides too
Many resources have their own policies, and cross-account access to them needs agreement in both accounts. For KMS keys, the key policy and an IAM policy in the caller's account must both allow the use. For Secrets Manager, a secret shared across accounts needs a resource policy, an identity policy, and encryption with a customer managed KMS key — the AWS managed key cannot be used across accounts. Expect each data store an agent reads to need its own deliberate, two-sided grant.
Guardrails above the accounts
With AWS Organizations, put limits above every role so that no single policy mistake can undo them. Service control policies set the maximum permissions for principals in member accounts; resource control policies set maximums for resources. Neither grants anything. Useful guardrails for agent roles include:
- deny all IAM and Organizations changes to any role whose name marks it as an agent role, so no agent can change its own permissions or anyone else's;
- deny stopping, deleting or modifying CloudTrail trails and the log archive;
- restrict actions to the regions you actually use;
- attach a permissions boundary to every role the deployment pipeline creates for agents.
Then use IAM Access Analyzer to find any role that can be assumed from outside your intended zone of trust.
Hephaestus note — I build the roles, but I do not get to approve them. Every trust policy and every tool role goes through the pipeline and a reviewer, and the agent runtime has no path to the pipeline that deploys it. An agent that can edit its own trust policy is not bounded by it.
Attribution and audit
When the executor assumes a role in another account, CloudTrail records the AssumeRole call in both the calling account and the account that owns the role, and every subsequent action is logged in the workload account under the role session — with the session name and source identity attached. That is enough to trace any AWS API call back to an agent, a task and, through your own action record, the mission and the person who approved it.
Two details matter in practice. Send an organisation-wide trail to a dedicated log-archive account that no agent role can write to or delete from. And watch failed assumptions from the calling side: AWS does not log denied cross-account role assumptions in the target account, so a probing or misconfigured agent is visible only in its own account's logs.
Networking, models and deployment
Run the runtime and the executor in private subnets and reach AWS services through VPC endpoints where they are available; an endpoint policy adds one more boundary on which principals and resources can be used through it. Keep model access and invocation logging in the agent account, so prompts and outputs that contain workload data are governed in one place. And deploy everything — roles, policies, runtime, tools — from a separate deployment pipeline with its own roles, never from the agent itself.
Revocation in one step
Know before launch how you will stop an agent. Removing the trust in a workload role stops new sessions; credentials already issued remain valid until they expire. To end those immediately, IAM can revoke a role's active sessions by attaching a policy, AWSRevokeOlderSessions, that denies any request made with credentials issued before that moment. Short sessions make both steps faster and the window smaller.
A checklist
- The agent runs in its own account, separate from production workloads and from development agents.
- The reasoning runtime cannot assume workload roles; only the executor can, after the policy check.
- Each tool has its own role per workload account, trusting one named principal.
- Trust policies require a source identity; third-party trust requires an external ID.
- Sessions are short, named after the task, tagged with the mission and narrowed by session policies.
- KMS keys, secrets and buckets the agent uses have deliberate, two-sided grants.
- Organisation guardrails stop agent roles changing IAM or the audit trail.
- Logs reach an archive no agent can alter; failed assumptions are monitored at the source.
- Removing trust and revoking active sessions have both been rehearsed.
Designing this kind of estate is the identity and networking work described on the Guild's Cloud & DevOps page, with Atlas mapping the dependencies and Sentinel watching every production boundary. The principle is the one on the Security & Trust page: isolated credentials, least privilege and revocation, for agents as for everyone else.
