Skip to content
StratoNext

IAM roles reference

The StratoNext onboarding template creates up to five IAM roles in your account. All of them are trusted only by StratoNext’s dedicated credential-broker role: a single, least-privilege StratoNext role whose only ability is to assume the roles you create, and the only StratoNext identity your trust policies name. Agents never assume roles in your account directly.

Agents never hold long-lived cloud credentials. When an agent needs to perform an AWS operation:

  1. The agent pauses its task and emits a credential request.
  2. The request enters the approval flow governed by your automation policy.
  3. On approval, the StratoNext credential broker assumes the appropriate role in your account and mints a short-lived credential scoped to that specific task.
  4. The credential is held in memory only for the duration of the operation and never persisted.

A unique ExternalId is required when deploying the template. It is embedded as a condition in every role’s trust policy to protect against confused-deputy attacks, and you enter the same value in the StratoNext wizard when connecting. StratoNext may also restrict trust to its own AWS Organization for defense in depth.

Every credential StratoNext mints is stamped with an STS source identity and session tags: the agent, your organization, the environment, and, for approved escalations, the task and the approval. These appear on the AssumeRole events in your own CloudTrail, so you can always trace which agent obtained which access, for what, and under which approval, with no extra setup on your side.

The role trust policies allow sts:TagSession and sts:SetSourceIdentity for this, and require every session to carry a StratoNext source identity scoped to your organization. Nothing StratoNext does in your account is ever unattributed, and the roles cannot be assumed under another tenant’s identity.

Always created. Used by the platform to validate the connection and keep your environment in sync: it can describe CloudFormation stacks and read templates so StratoNext can discover and map your deployed resources.

Created when EnableAgentDeployment is true. Used by the platform to deploy and manage agent runtimes on Bedrock AgentCore in your account: creating and updating agent runtimes, managing their endpoints, and passing the runtime role. Deletion permissions are scoped so it can only remove workload identities that StratoNext itself created.

Created when EnableAgentDeployment is true. The identity a StratoNext agent runs with when deployed inside your own AWS account on Amazon Bedrock AgentCore. It can invoke Bedrock models, write its own logs and telemetry, and store its tokens in a scoped SSM parameter path. It has no sts:AssumeRole permission. Even in-account agents get their operations credentials from the credential broker, never by assuming roles themselves.

Created when EnableAgentAccess is true. The baseline access agents work with. The credential broker assumes this role and hands short-lived credentials to the agent. The agent never assumes it directly. The default policy is read-only: describing EC2, S3, Lambda, DynamoDB, and RDS resources, reading CloudWatch metrics, and querying CloudWatch Logs.

Customize this role’s policy in your account to widen or narrow what agents can do by default.

Created when EnableAgentAccess is true. The escalation ceiling. When an elevated action is approved, the credential broker assumes this role and scopes the session down to the approved action and resource set via an STS session policy. An approval can never grant more than this role allows.

Tune its policy to your risk tolerance, and keep it a sensible ceiling, never AdministratorAccess.

The gap between the Operations Role and the Operations Max Role is your guardrail: the baseline runs autonomously, the ceiling caps what any approval can grant, and the space between is what an agent requests approval for.

Delete the CloudFormation stack to remove all roles and revoke StratoNext’s access to your account immediately. Because all access is short-lived STS sessions, there are no keys to rotate.