Access Module

Access is not authority.
Every escalation is governed.

Role changes, permission grants, and MFA config changes are the highest-value targets after initial compromise. Strix places a governed checkpoint before every one of them — regardless of who is asking.

What Strix stops

👤

Insider promotes themselves

Without Strix

User with 'member' role calls PATCH /api/members with role: 'owner'

With Strix

Strix intercepts. Decision required. Two approvals for HIGH-risk role change.

🛡️

Compromised admin session

Without Strix

Attacker with stolen session token attempts to grant 'admin' to an external account

With Strix

Action flagged as CRITICAL. Strix requires a second approver from a different session.

🤖

Automated escalation

Without Strix

AI agent script attempts to elevate its own capability scope mid-task

With Strix

Execution token required. Agent cannot issue its own tokens. Blocked.

🔕

MFA enforcement change

Without Strix

Admin disables MFA requirement for all users via settings mutation

With Strix

CRITICAL action. Self-escalation blocked. Second human approver required.

How enforcement works

Evaluated at execution. Not before, not after.

📋

Role change attempted

Any mutation that touches role, capabilities, or MFA settings is classified as CRITICAL or HIGH by the kernel.

⚖️

Policy evaluates

PolicyEngine assesses risk tier, self-escalation flag, quorum requirement, and SoD (Separation of Duties). Output is deterministic and content-addressable.

🔏

Approval artifact minted

Each approval produces a 1:1 signed canonical artifact. Chain-hashed within the decision. Verifiable by any third party against the public JWKS.

Enforcement specification
Risk tierCRITICAL for role changes, HIGH for permission updates
Approvals required2 for CRITICAL · 1 for HIGH (configurable)
Self-escalationBlocked — actor cannot approve their own role change
Token bindingApproval bound to exact payload — cannot be replayed against a different target
EvidenceSigned artifact per approval + signed evidence record per decision
Audit retentionPermanent — approval artifacts preserved independently of the decision row

Separation of Duties

You cannot approve your own escalation.

Strix enforces SoD at the policy layer — not the UI layer. The actor requesting the role change cannot be the same actor who approves it. Approval artifacts carry the approver's identity in the signed canonical payload. Any attempt to self-approve fails policy evaluation before an approval row is ever written.

// PolicyEngine SoD check
requestActor: "usr_alice"
approvalActor: "usr_alice"
→ SoD violation detected
→ Decision: DENY
→ evidence record: signed

See a role change get intercepted.

In the demo, we attempt to promote a user to owner — and watch Strix create a decision record, block self-approval, and require a second human approver. All in a live production system.