# Identity, authorization and access decisions

Sign-in identity, task capability and approval for important actions are three different credentials; an action runs only when identity, action, authorization, data, budget and risk conditions all hold at once.

> Document ID: MYRILUM-DOC-ARCH-015
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: DRAFTED
> Governance: APPROVED
> Capability state: IN_DEVELOPMENT
> Availability: NOT_AVAILABLE
> Authorization: PUBLIC_INFORMATION
> Freshness: CURRENT
> Safety class: INFORMATIONAL
> Owner: Web3Capital Documentation Steward
> Approvers (assignment only; not approval evidence): Stephen
> Canonical authority: SRC-ARCHITECTURE-ATLAS-V2-2
> Source commit: 6b41cce4496de03c67a501aa94cd41ec6ac0e85a
> Content digest: cdeb6e74bcf01895e64bb10c823ca6ddd3d09e407788890deb869a99c799f66a
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /en/architecture/identity-and-authority

<a id="overview"></a>

## What this page covers

This is MYRILUM's target architecture. It does not mean everything on the map is live; whether a capability can be used today is stated in “Current availability”.

Central identity, resource-level permissions, task delegation and approval of high-impact actions are four different layers of control. This page states principles only; implementation details are not published.

<a id="three-credentials"></a>

## Three credentials that never substitute for each other

Sign-in identity proves who you are; task capability states what a task may do; approval for an important action covers this one time and this one object. Each is issued and checked on its own, and none can stand in for another.

<a id="all-conditions"></a>

## Every condition must hold at once

Allowed to run = valid identity ∧ lawful action ∧ matching authorization ∧ data allowed ∧ budget available ∧ risk cleared. Anything not explicitly allowed is treated as not allowed. Being able to use a product feature is not the same as permission over its data or its actions.

<a id="bound-approval"></a>

## Approval is bound to one specific action

An important action is approved by an authorized person on the basis of evidence, and the approval holds only for that plan version, recipient, environment, key data flows and budget; if any of them changes, the approval no longer applies. A model can never issue an approval on a person's behalf.

<a id="recheck-and-revoke"></a>

## Checked every time, revocable at any time

Permission is not checked only once when a task is created; it is checked again before every important action. After revocation or freezing, new actions stop at once; actions already accepted externally are queried or compensated. Every time leaves a record of who acted, on what basis, on which object and when.

<a id="regions"></a>

## The two regions' identity is kept apart

Identity authentication for the China region and the global region runs in separate environments. Data, permissions and forbidden actions are hard boundaries and are never relaxed because a model is cheaper or delivery would be faster.

<a id="source"></a>

## Source

This page follows A15 of the MYRILUM architecture map v2.2. Under the public boundary it publishes principles only and carries no diagram. Related: “Business domains and fact authority”; “Agent runtime and failure recovery”; “Deployment and trust boundaries”.

---

This document is read-only, grants no command authority, and does not authorize deployment, payment, provider modification, or any other real-world action.