Overview & Architectural Primitives
SoldierX AI SIEM ships with a full, granular access-control system for multi-user, multi-role organizations - named policies made of explicit allow/deny statements, attached to users, groups, and roles, with support for temporary assumed-role sessions and an organization-wide audit log.
IAM Dashboard
The IAM area has its own section of the product, reachable to anyone holding at least one IAM viewing permission. Opening it lands you on the first screen you actually have access to, in priority order: Dashboard, Users, Policies, Roles, Groups, or Audit Log.
The Dashboard itself is five headline metrics at a glance:
Total Users
Total Roles
Total Policies
Total Groups
Users With No Access
Alongside the metrics, four charts break the account down further:
- Policy-type distribution - how your policies split across Managed, Inline, Guardrail, and Boundary.
- Group size - a member-count breakdown across your groups.
- Assumable-role share - what portion of your roles are marked assumable.
- OTP enforcement - how many of those assumable roles require the one-time-code trust condition before assumption.
Security Recommendations panel
Authentication vs. Authorization
Authentication (AuthN) and Authorization (AuthZ) are two separate concerns in SoldierX AI SIEM:
Authentication (AuthN)
Verifies who you are. Sign-in is email and password - there is no separate day-to-day multi-factor step on every login. One-time email codes are used for two specific flows only: confirming a new account's email during registration, and resetting a forgotten password.
Authorization (AuthZ)
Verifies what you are permitted to do. Your effective access is the union of every policy attached to you directly, through your groups, and through your roles - with an explicit deny always winning over any allow. See the Evaluation Logic module for the full step-by-step breakdown.
Core Building Blocks
Every access grant in SoldierX AI SIEM is assembled from four building blocks:
| Primitive | Scope | Description |
|---|---|---|
| Team Member (User) | Individual identity | A person in your organization. Can hold direct (inline) policies, be assigned roles, belong to groups, and carry a personal permission ceiling. |
| Group | Standing container | A permanent, always-on bundle of policies attached to a set of users. There is no temporary-session equivalent for a group - unlike a Role, a Group cannot be assumed. |
| Role | Standing, or assumable | A container of policies assigned to users, functionally the same as a Group, except a Role can additionally be marked assumable - letting a user temporarily switch into it for a bounded, trust-policy-gated session. |
| Policy | Reusable or inline | A named set of Allow/Deny statements. Each statement grants or denies one or more actions, optionally restricted to specific resources. Comes in four types - see below. |
Policy Types
A policy is one of four types, depending on how broadly it applies and who is allowed to create it:
| Type | Who can create it | Description |
|---|---|---|
| Managed | Any authorized administrator | Standalone and reusable. Build it once, attach it to as many users, groups, or roles as you like. Detaching it leaves the policy itself intact. |
| Inline | Any authorized administrator | Authored for a single attachment, for one-off cases. Detaching an inline policy deletes it permanently, since it was never meant to be shared. |
| Organization-wide Guardrail | Account Owner only | A hard, deny-only limit that applies across every member of the account. Can only ever restrict access, never grant it. Doesn't work by attachment - it applies tenant-wide the moment it exists. |
| Permission Ceiling (Boundary) | Any authorized administrator | A deny-only limit attached to one specific user or role, capping what that individual can ever do regardless of what else is granted to them. At most one ceiling per user or per role. |
The Account Owner
Every subscription has an Owner - the account that originally created the organization.
The Owner is always fully privileged
- Guardrail authority: Only the Account Owner can create organization-wide guardrail policies.
- Billing control: Billing and subscription administration (viewing/changing the plan, retrying payments, managing payment methods, opening the billing portal) stays with the Owner by default, and can be separately delegated to specific team members through the same permission catalog used everywhere else.
- Recovery path: If a misconfigured ceiling or guardrail locks other administrators out of part of the product, the Owner's unrestricted access is what lets the account be fixed.
The Two-Axis Scoping Model
Permissions aren't just all-or-nothing. Many actions support finer-grained restriction along one or both of two independent axes:
Restricts which resources the permission applies to - typically specific assets or specific cases, or every resource of that kind in the account.
Restricts the caller's own context - typically limited to items they personally own, or an explicit list of other users the grant applies to.
The two axes are tracked and enforced independently, and can be combined. The one action in the whole catalog where they mean genuinely different things at the same time is siem:caseassignment:update: the resource restriction limits which cases can be reassigned, while the scope restriction separately limits which teammates can be assigned onto them.
{
"Effect": "Allow",
"Action": "siem:caseassignment:update",
"Resources": ["case-prod-9812", "case-prod-9813"],
"Scope": ["user-analyst-04", "user-analyst-07"]
}