Identity, grants, and application access¶

TrustMint authenticates human console sessions and machine integrations through DotID and delegates authorization to the DotID Policy Decision Point (PDP). TrustMint services do not maintain a second user, group, role, permission-set, or policy store.

Principal boundaries¶

Principal	Intended use	Console profile
Account root user	Administration of a standalone account	Yes
Workforce user	Human access through an organization’s Identity Center	Yes
Service user / factory service	Non-human signed API calls	Never
Workload identity	Deployed service-to-service calls	Never
Platform administrator	Platform governance in the admin shell	Yes

Do not model a factory service or deployed TrustMint service as a workforce user. Service users cannot receive console access, and a workload identity is registered and federated separately from an account-owned service user.

Authorization contract¶

Your token proves authentication and supplies tenant context. It does not carry authorization: no realm role, client role or group in it is read as permission. For every operation the platform asks a central Policy Decision Point whether the principal may perform an action on an FRN resource:

principal + account context + action + resource FRN -> PDP -> allow | deny

Three consequences you have to design around:

A 403 is a policy decision, not a missing claim. Re-issuing a token with an extra role changes nothing. The fix is a permission-set or policy change on the platform side.
It fails closed. A decision that cannot be reached is a denial. Expect a 403 or 503 under fault, never an accidental allow — so do not treat a transient authorization error as a reason to retry with elevated assumptions.
An allow is not a widening. List operations still apply the selected account and the resource-visibility constraints; an allow decision never turns a tenant endpoint into an unrestricted platform query.

Managed policies and permission sets are authored and assigned in DotID. TrustMint documents the actions it registers, but does not invent UI-only roles. Common human grants should be delivered through reusable permission sets; service users receive only API policies required for their integration.

Tenant and platform separation¶

Tenant users launch ThingMake, ThingHub, ThingFeed, ThingIO, ThingLogic, ThingBand, and ThingLab from https://console.flexgalaxy.ai. Every browser request is scoped to the account selected by the shell.

Platform administrators launch Arsenal and DeckLoad from https://admin-console.flexgalaxy.ai. Arsenal governs certificate authorities and certificates. DeckLoad performs audited cross-account grant overrides. These applications do not appear in the tenant product switcher.

SuperCrew is a DotID platform-administration application. It manages accounts, organizations, and standalone-account users within its own documented scope; it does not author tenant IAM for TrustMint.

See Console applications and private APIs for route ownership and the complete application map.

Machine access¶

Factory integrations use an AK/SK pair revealed once when the factory service is created. Requests use FGAI-HMAC signing as documented in Registration. Store the secret in a secret manager, rotate it through the supported factory integration flow, and never place it in browser storage.

Service-to-service calls inside the platform use workload identities, which are registered and federated separately from an account-owned service user. They are not a credential you can obtain or present, and no external integration path depends on one.