Users and Workload Identities

A User is the human principal who authenticates, owns upstream Connections, and approves delegated authority. An Application identifies the client software. An optional workload identity attributes the specific actor operating through that client.

Axec preserves those identities separately:

User
  delegates to Application
    optionally operated by workload identity
      for an exact gateway Resource and Connector authority

User authority

The User’s browser session anchors session-mode authorization. The User’s immutable consent event and exact credential choice become Grants under a GrantBundle. Disabling the User, expiring the required session, or revoking a Grant removes a live dependency.

Workspace groups are directory facts, not authority by themselves. They do not grant Workspace roles, Application access, Connections, Grants, OAuth tokens, or MCP capability access.

Workload attribution

A workload identity does not replace the Application Credential or the User. When present, it is bound to delegated authority and can be evaluated as a typed actor by governance policy. Changing the workload identity is an authority change that replaces the compatible GrantBundle root rather than silently reusing it.

Other non-human principals

A Service Account is for tenant management automation and does not inherit User or Application authority. An agent is an Application doing agentic work, not another authentication kind.

See Grants and GrantBundles for the durable delegated relationship.