Module 3docs/iam/roles

Standard Roles vs. Assumable Roles

Name: SoldierX AI SIEM
Brand: SoldierX

SoldierX AI SIEM differentiates between standing functional identities used for daily operations and temporary elevation containers activated under strict trust conditions.

Standing Functional Roles

A Standard Role is a permanent operational bundle assigned directly to a team member. Its policies are constantly evaluated as part of the user's baseline permissions:

Job responsibilities: Standard roles model day-to-day duties, such as "SOC Manager", "Compliance Auditor", or "IT Operations".
Combined, not separate: A role is functionally the same kind of container as a Group. Its permissions are included in the same union as group policies and direct user policies when computing effective access.
No assumption step: A standard role isn't marked assumable, so its permissions are simply part of the user's standing access, with no verification step or session timer involved.

Assumable Roles & Temporary Elevation

An Assumable Role is a role marked to allow temporary elevation, for sensitive operations that shouldn't be part of someone's everyday standing access (e.g. "Incident Commander" for a major incident response).

Full replacement, not addition

While a role is active, your effective permissions are exactly that role's permissions, plus your organization's guardrails. Your own everyday access is set aside for the duration, not stacked on top of it.

Being assigned a role isn't the same as being able to assume it

Assigning a user to an assumable role only makes them eligible for it. Actually assuming it separately requires the iam:role:assumeRole permission, scoped to that specific role. If a user holds the role but not this permission, the Roles > Assigned Roles view flags it with an inline warning rather than letting the mistake fail silently the first time they try to use it.

Trust Conditions

An assumable role's detail page exposes a trust-condition editor with three independent conditions, all optional and all combinable:

Condition	What it does
One-time verification code	Requires a one-time code, sent to a destination email you configure, before the session activates.
IP allowlist	Requires the assumption request to come from an approved IP address or network range. Exact addresses and address ranges are entered separately.
Maximum session length	Caps how long the elevated session can last, in minutes. Defaults to up to 24 hours if left unconfigured, with a 5-minute minimum on any shorter duration you explicitly set.

The Single-Level Cap (Strict Prohibition of Role Chaining)

In SoldierX AI SIEM, the maximum role assumption depth is strictly capped at 1.

No chaining

You cannot assume a role while already operating under an assumed role. You must return to your base identity first. This keeps privilege escalation auditable and bounded to one level.

Every assumption, and every switch between identities, is recorded in the audit log - so a chain of elevation is always traceable back to the operator's base identity, without needing multiple nested levels to reconstruct it.

Session Reversion & Safeties

Temporary sessions are bounded by active safety controls:

Always visible: A persistent on-screen banner shows whenever you're operating under an assumed role.
Always reversible: A single click on the banner switches you back to your normal identity at any time.
Re-entry without re-verifying: There's an equally simple way to switch back into the assumed session again, without having to satisfy the trust conditions from scratch, as long as the original session hasn't expired.

Standing Functional Roles

A Standard Role is a permanent operational bundle assigned directly to a team member. Its policies are constantly evaluated as part of the user's baseline permissions:

Job responsibilities: Standard roles model day-to-day duties, such as "SOC Manager", "Compliance Auditor", or "IT Operations".

Combined, not separate: A role is functionally the same kind of container as a Group. Its permissions are included in the same union as group policies and direct user policies when computing effective access.

No assumption step: A standard role isn't marked assumable, so its permissions are simply part of the user's standing access, with no verification step or session timer involved.