Grants and GrantBundles

A GrantBundle is the stable root of delegated User authority. It joins one User, requesting client Application, target gateway Application, and canonical Resource URI. A Grant is one independently managed Connector authority under that root. Together, they link an Application’s Axec authorization to the exact upstream credential source a User approved.

Root and children

flowchart TD
  Bundle[GrantBundle]
  GrantA[Grant: Connector A, credential source, capabilities]
  GrantB[Grant: Connector B, credential source, capabilities]

  Bundle --> GrantA
  Bundle --> GrantB

The root binds the client profile revision, optional workload identity, expiration, status, and authority revision. Each Grant carries independent Connector authority, so revoking one Grant preserves active siblings.

Root modes

Mode	Lifetime anchor	Refresh behavior
session	Original browser session	No Refresh Family
offline	Fixed root expiry	One active Refresh Family may exist

At most one active root exists for a User, client Application, and gateway. Compatible authorization can reuse it. Changing its mode, client profile, workload identity, or gateway Resource revokes the old root and creates a new one.

What a Grant pins

Each Grant binds:

• The immutable delegated consent event.
• The Application Connector attachment and Connector.
• The credential mode and exact User Connection or workspace Vaulted Credential.
• Allowed scopes and capability keys.
• Authorization, credential-configuration, and effective-contract digests.

These bindings prevent consent from drifting when an attachment, credential, Connection, or Connector contract changes.

Grant lifecycle

Status	Meaning
active	Current authority for this root and Connector
superseded	Changed consent created and linked a replacement Grant
revoked	The authority was removed by consent, root lifecycle, the User, or restriction tooling
expired	Cleanup reached the Grant’s own expiry

Unchanged consent can reuse an active Grant. Changed consent creates a replacement rather than mutating the immutable approval record. Revoking or expiring the final active Grant terminally revokes the root and its active Refresh Family; whole-root revocation removes every active child.

Live authority lifecycle

A bearer token references authority; it does not copy a Grant into a permanently valid claim set. For delegated work, every operation reloads the tenant and User, browser session or Refresh Family, client Application and exact credential, gateway Resource, GrantBundle, Grant, attachment, Connector contract, and exact Connection or Vaulted Credential.

Application-principal authority instead uses the Application’s own active gateway attachment path and cannot use User Connections. Service Account management requests independently reload the tenant, Service Account, exact credential, audience, and permission ceiling.

Rotating an Application Credential, reconnecting a User, changing consent, or changing an incompatible root property creates replacement authority rather than silently rewriting prior approval. Disabling or revoking any required link prevents later operations without waiting for every issued bearer to expire. Policies and approvals can further narrow an admitted operation, but cannot create missing authority. Evidence records the result without becoming an authority source.