Module 5docs/iam/guardrails-and-boundaries

Guardrails & Permission Ceilings

Name: SoldierX AI SIEM
Brand: SoldierX

SoldierX AI SIEM utilizes a two-tier boundary architecture to enforce organizational invariants and sandbox delegated identities without sacrificing operational agility.

Organization-wide Guardrails

An Organization-wide Guardrail is an account-level, deny-only policy enforced across every single member of the subscription:

Only the Owner can author one

A guardrail is evaluated after your own grants, alongside your personal permission ceiling if one is set, and can only restrict access, never grant it. If a guardrail denies an action, no standing policy, group membership, or assumed role can override it.

An organization-wide guardrail is the right tool when a rule should apply to literally everyone, regardless of role - for example, a standing rule that no one may ever delete a policy, no matter who they are or what else they're granted:

organization-guardrail-example.json

{
  "Effect": "Deny",
  "Action": "iam:policy:delete",
  "Resources": ["*"]
}

Permission Ceilings (Boundaries)

A Permission Ceiling (Boundary) is an identity-level policy attached to a specific user or role. It establishes the maximum possible permissions the identity can ever exercise:

At most one ceiling: An identity may have zero or one permission ceiling attached, at the user level or at the role level.

Deny-only: Like an organization-wide guardrail, a ceiling is made up of Deny statements. It never grants anything on its own - it only ever takes permissions away from what the identity's own policies, groups, and roles already grant.

Decision Matrix: Guardrails vs. Ceilings

Use the following matrix to select the appropriate boundary mechanism:

Dimension	Organization Guardrail	Permission Ceiling (Boundary)
Scope of Impact	Entire subscription / all users	Single user or single role
Author Authority	Account Owner only	Any authorized IAM admin
When It's Evaluated	After the identity's own grants	After the identity's own grants
Primary Intent	A rule that applies to everyone, no exceptions	Capping one specific person or role, no matter what else they're later granted

Why Both Tools Exist

A permission ceiling is the right tool when you want to cap one specific person or role no matter what else they're ever granted later - for example, a contractor account that should never be able to exceed a fixed set of actions even if someone accidentally assigns them a broader role down the line.

An organization-wide guardrail is the right tool when the rule should apply to literally everyone, regardless of role - a standing deny that no role or policy anywhere in the account can override, for anyone, including people not yet hired.

The Administrative Ceiling Rule

To prevent privilege escalation when delegating IAM administration:

You can't grant what you don't hold

An administrator can never grant someone else a permission, resource, or scope they don't themselves hold. Attempting to build a policy or role that exceeds your own access is rejected with an explanation of exactly what you're allowed to grant. The Account Owner is exempt from this rule, since they hold unrestricted access by definition.

If an administrator does not hold iam:user:create, they cannot save a policy containing iam:user:create. If their effective scope on siem:loganalysis:read is restricted to Asset A and Asset B, they cannot attach a policy granting Asset C to another user.