My Attempt to Sandbox an AI Agent with IAM Identity Center

AI agents have become heavily integrated into my daily work and learning process. The more I use them, the more impressed I am by how many different kinds of tasks they can carry. That is useful, but it is also uncomfortable.

I do not fully like admitting this, but in many situations I already rely on agents because they are faster or more capable than I am at moving through implementation details. Part of me still resists that. Another part of me feels that if I keep working exactly the old way, I will slowly fall behind the rest of the world.

That tension becomes sharper in DevOps work. If an agent can run commands, inspect infrastructure, write Terraform, and call the AWS API, then the question is not only "can it help me?" The question becomes:

What kind of boundary do I need before I let an AI agent touch cloud infrastructure?

This post is my attempt to think through a sandbox for AWS work using IAM Identity Center, AWS CLI credentials, permission sets, permission boundaries, Terraform-managed resources, and OIDC roles for CI/CD.

What I wanted to understand

The concrete questions were:

• How can I give an AI agent AWS access without handing it long-lived credentials?
• Can IAM Identity Center give me a short-lived session model that feels natural for agent work?
• How should I separate human interactive access from CI/CD access?
• Where do permission sets end, and where do IAM permission boundaries start to matter?
• Can I make the agent useful without allowing it to create one invisible black box after another?

What I learned

My current model is:

• IAM Identity Center is for centralized human access. It gives users or groups access to AWS accounts through permission sets.
• Permission sets describe what an assigned identity can do in an account. They can include AWS managed policies and custom inline policies.
• AWS CLI SSO sessions are temporary. That makes them a better fit than static IAM user keys for local agent-assisted work.
• Permission boundaries are a second layer of control. They do not grant permissions by themselves; they define the maximum permissions an IAM role or user can receive.
• Terraform and CI/CD should have their own controlled paths. Local interactive work and automated deployment work should not be blurred into one broad credential.
• The AWS CLI is still a strong interface for agents. It is mature, observable, and easier for me to reason about than adding another AWS-specific MCP layer.

The mental model I am working with is:

human login
  -> IAM Identity Center session
  -> permission set for an AWS account
  -> short-lived AWS CLI credentials
  -> agent runs commands inside that session
  -> IAM policies and boundaries limit the blast radius

This is not a complete sandbox. It is more like a controlled workbench: the agent can still act, but the shape of what it can touch is defined before the session starts.

Why I prefer the AWS CLI over an AWS MCP for this use case

For DevOps work, I am currently more comfortable exposing AWS through the AWS CLI than through an additional MCP server.

That does not mean MCP is bad. It means that, for this specific workflow, the AWS CLI has a few advantages that matter to me:

• it is already mature and widely documented
• every command is visible in the terminal history or agent transcript
• IAM policies map naturally onto the API calls being made
• it places less pressure on the context window than teaching the agent a large new tool surface
• it aligns with how Terraform, SDKs, shells, and existing AWS workflows already think about credentials

The CLI also keeps the responsibility more visible. If the agent runs:

aws iam list-roles

or:

aws s3api get-bucket-policy --bucket example-bucket

I can see the exact interface being used. I can reason backward from the command to the API action, then from the API action to the IAM policy. That chain is not always simple, but it is inspectable.

With an MCP abstraction, I worry that the agent-facing tool may become easier to use while also becoming harder for me to audit mentally. Since this exploration is about restriction and monitoring, I want fewer layers at first, not more.

So this post does not cover how to restrict an AWS MCP server. My current assumption is: for daily DevOps tasks, the AWS CLI plus IAM Identity Center is the baseline I want to understand first.

IAM Identity Center in plain terms

IAM Identity Center is AWS's centralized access system for humans. It used to be called AWS SSO, and many SDK and CLI names still use sso because of that history.

The core pieces are:

• Identity provider: where users and groups come from. This can be IAM Identity Center itself or an external IdP.
• AWS accounts: the accounts in AWS Organizations that users need access to.
• Permission sets: bundles of permissions assigned to users or groups for specific accounts.
• Access portal / start URL: the URL used for login.
• SSO session: the temporary authenticated session used by the AWS CLI.
• Temporary credentials: the credentials the CLI receives for a selected account and permission set.

The important distinction for me is that IAM Identity Center is not just another place to create IAM users. AWS generally recommends Identity Center for human access and IAM roles/policies for permissions inside accounts.

So the rough structure becomes:

AWS Organizations
  -> accounts for environments or purposes

IAM Identity Center
  -> users and groups
  -> permission sets
  -> assignments to accounts

IAM inside each account
  -> roles, policies, boundaries, service permissions

That split matters because an AI agent working through my terminal is not really a separate AWS identity unless I create one. It is acting through a session I grant. If I log in with an overpowered permission set, the agent inherits that overpowered context.

Short-lived sessions are the first boundary

The first sandboxing primitive is time.

I do not want an agent using long-lived IAM user access keys stored on disk. Those keys are too easy to forget about, copy, leak, or accidentally reuse months later.

IAM Identity Center gives me a more temporary workflow. I authenticate, the CLI gets SSO-backed credentials, and those credentials expire. That does not make the session harmless, but it does reduce one class of risk: permanent secrets lying around in ~/.aws/credentials.

A normal setup path looks like:

aws configure sso

Then the CLI stores SSO configuration and uses login flows to retrieve temporary credentials. For agent work, that gives me a useful habit:

1. choose the account and permission set intentionally
2. start a short-lived session
3. let the agent work only inside that session
4. let the session expire when the work is done

That feels closer to lending the agent a badge for a room than giving it a master key to the building.

Permission sets are the second boundary

The next boundary is authorization.

In IAM Identity Center, a permission set is assigned to a user or group for one or more AWS accounts. It can include AWS managed policies and customer-defined inline policies.

For an agent-assisted workflow, I do not want to use a broad administrator permission set by default. I want permission sets that correspond to actual kinds of work:

• read-only inspection
• Terraform planning
• limited development environment changes
• billing or cost visibility
• specific service administration

A simple agent workflow could start with something like:

AgentReadOnly
  -> ViewOnlyAccess or ReadOnlyAccess-style permissions
  -> enough for inspection, inventory, and diagnosis

AgentDevOpsLimited
  -> selected service permissions
  -> no broad IAM mutation
  -> no unrestricted iam:PassRole

AgentBreakGlassAdmin
  -> powerful access
  -> short session
  -> used rarely and intentionally

The exact policies depend on the account and task. The important part is that the agent should not begin every task from the maximum possible permission level.

This is where I need to be careful with my own laziness. When the agent fails because access is denied, the easiest fix is to give it more permission. But that teaches the workflow the wrong lesson. An access-denied error is often useful information: it shows where the boundary actually is.

Permission boundaries are the third boundary

Permission sets define what the identity can receive. Permission boundaries are different: they define the maximum permissions an IAM user or role can have.

A boundary does not grant access by itself. If the identity has no policy allowing s3:PutObject, the boundary does not magically allow it. But if a policy does allow s3:PutObject, the boundary can still cap where and how that permission applies.

This becomes important when the agent is allowed to create or modify IAM roles.

Without careful controls, IAM modification can become privilege escalation. A dangerous pattern is:

agent can create or update a role
agent can attach broad policies
agent can pass that role to a compute service
compute service now has more power than the original session should have had

That is why iam:PassRole and direct IAM policy manipulation need special attention. Passing any role to Lambda, EC2, ECS, CloudFormation, or another service can become a path to administrator-level access if the role scope is too broad.

A permission boundary can help enforce that roles created by Terraform or by an agent-assisted workflow stay inside an expected ceiling. For example:

Terraform-managed app role
  -> may receive app deployment permissions
  -> must include boundary: AppRoleBoundary
  -> cannot exceed services/resources allowed by that boundary

This is the part that makes the sandbox feel less like a single policy and more like layers:

short session
  + limited permission set
  + scoped iam:PassRole
  + permission boundary on created roles
  + Terraform-managed infrastructure

No layer is perfect. The point is that one mistake should not automatically turn into total account control.

Terraform and CI/CD need a separate path

Another thing I want to avoid is mixing local agent work with deployment authority.

For infrastructure, Terraform should be the source of truth. If an agent helps me write or modify Terraform, that is different from letting the agent freely mutate live infrastructure through ad hoc CLI commands.

The cleaner model is:

local agent session
  -> inspect resources
  -> edit Terraform
  -> run plan
  -> maybe apply in controlled environments

CI/CD OIDC role
  -> assumed by workflow identity
  -> applies approved Terraform changes
  -> scoped to repository, branch, environment, or workflow

For CI/CD, I prefer OIDC-based role assumption instead of storing static AWS keys in a CI secret. The workflow identity should assume a role with a trust policy scoped to the CI provider and project. That role should have only the permissions required for the deployment path.

This keeps the human/agent session and the automation session conceptually separate:

• my local session is for exploration and authoring
• the CI/CD role is for repeatable deployment
• Terraform defines the desired state
• IAM policies define what each path is allowed to do

I still need to work out the exact boundaries, but this distinction already makes the architecture feel less muddy.

The tooling layer: aws-sso-cli

One third-party tool I am exploring is aws-sso-cli.

The reason it interests me is not that it changes the fundamental AWS model. The fundamental chain is still:

Identity Center login -> selected account/role -> temporary AWS credentials -> AWS CLI/API call

The useful part is that it improves the daily experience around selecting roles, exporting credentials, and managing SSO-backed access. It also focuses on encrypting tokens and credentials on disk using secure storage, whereas the stock AWS CLI caches SSO material under AWS config/cache paths.

That matters because the SSO access token is powerful. If exposed, it may be used to fetch credentials for roles that the user has access to. The temporary nature of credentials helps, but local storage still deserves attention.

At the same time, I do not want the helper tool to become the real architecture. The durable design should be the IAM Identity Center assignments, permission sets, boundaries, profile conventions, and deployment roles. The helper CLI is there to make the workflow safer and less annoying, not to replace understanding.

The uncomfortable part

The technical goal is to sandbox an agent. The emotional reason is that I do not want to become a person who lets agents build black boxes around my work while I nod along because the output looks plausible.

AI agents are genuinely useful. I am amazed by what they can do. But the more capable they become, the more I feel the need to understand the operational details around them. If I cannot keep up with every implementation detail, then I at least need to understand the boundaries, credentials, logs, and failure modes.

That is probably why IAM Identity Center feels like the right place to start. It forces the question into concrete terms:

• Who is authenticated?
• Which account are they entering?
• Which permission set did they receive?
• How long does the session last?
• Which roles can they pass?
• Which resources can they modify?
• What remains visible afterward?

Those questions are not philosophical. They are operational. But they also answer part of the emotional discomfort. They turn "the agent can do anything" into "the agent can do these things, for this session, in this account, through this credential path."

That is a much less magical sentence.

What still feels unfinished

I do not think this exploration gives me a perfect agent sandbox yet. It gives me a direction.

The next concrete work is probably:

• define separate IAM Identity Center permission sets for agent-assisted read-only, development, and break-glass workflows
• create Terraform-managed permission boundaries for roles the workflow is allowed to create
• tightly scope iam:PassRole
• make CI/CD use OIDC instead of static AWS credentials
• keep local AWS CLI sessions short-lived
• log and review what the agent actually does

The bigger unresolved question is harder:

What exactly is my relationship with the AI agent?

Is it an assistant, a junior operator, a compiler for intent, a dangerous shell with better language skills, or something else? What are the things only I can still do?

I do not know the answer yet. For now, the most honest answer is that I need to keep the agent close enough to be useful, but bounded enough that I still understand the system we are changing together.

Summary

My current sandboxing model is layered:

IAM Identity Center for human login
short-lived AWS CLI sessions
limited permission sets
scoped IAM actions, especially iam:PassRole
permission boundaries for created roles
Terraform as source of truth
OIDC roles for CI/CD
logs and review for accountability

This does not remove the need for judgment. It gives judgment somewhere to attach. The agent can move quickly, but the boundary should be designed before speed becomes the default.