Skip to content

Manage Runtime Authority

Use these console workspaces when access is already configured and a person needs to understand or interrupt live authority. They are not runtime CLI workflows.

ObjectMeaningIdentifier relationship
Console accountA human authenticated to operate the console.Not a workload Subject.
ApplicationA confidential client that asks STS for authority.May act for itself or a federated Subject.
SubjectThe stable JWT sub an application acts for.Grouping key in the Subjects workspace.
Authority recordOne STS-issued authority anchor.Its ID is carried as protocol session_id; it is not a Coordinator Session ID.
SessionA governed execution owned by Coordinator.Its ID is carried as agent_session_id.
DelegationBounded authority from one Session to another.Anchored by source and target Session IDs.
ApprovalA human-decision hold raised for a requested action.May link to Subject, Authority record, Session, Resource, and scopes.

Open Subjects and search by identity or kind. A Subject detail groups Authority record history, governed Sessions, pending Approvals, and provider connections.

Use the Subject kill switch for credential compromise or offboarding when individual cleanup would be unsafe. The implemented cascade revokes live Authority records, terminates linked Sessions, revokes Delegations, and revokes provider connections. Confirm the selected Subject and zone before acting.

The kill switch ends authority that already exists; it does not disable the credential behind it. A Subject backed by an application can establish fresh authority on its next exchange, so containing a compromised application credential also requires rotating that application’s secret from its detail panel in the same intervention.

Subjects are supplied by the application’s identity system or fall back to application identity when no accepted subject token is exchanged. The console does not authenticate those end users.

Open Sessions to filter active, suspended, or terminated executions and inspect their tree, lifecycle, leases, invocations, Authority linkage, and inbound or outbound Delegations.

  • Suspend pauses an active Session subtree.
  • Resume returns a suspended subtree to active operation.
  • Terminate is terminal and stops the Session subtree.

Task Sessions expire by TTL. Service Sessions use heartbeat leases. A Session can reference an Authority record for attribution without changing the IDs into the same object.

The Sessions workspace exposes Delegation views and lineage. Inspect source and target Sessions, resource and scope bounds, constraints, expiry, and traversal state before revocation.

Revocation ends the delegated authority represented by that edge. Requests must still pass the consuming verifier’s revocation checks; use Audit to confirm denial after intervention.

Approvals lists holds in these implemented states:

StateMeaning
pendingWaiting for an eligible approver until expiry.
approvedAn approver satisfied the hold; the requesting exchange has not consumed it yet.
consumedA retry used the approval; it cannot be reused.
rejectedAn approver denied the request.
expiredThe decision window ended.

A pending hold is decidable in the console only when its approver class is Zone operator or Operator or end user. An End user only hold remains visible but has no console approve/reject action. These labels map to the policy data values operator, any, and subject in approval_tiers. Before deciding, inspect the requester, privacy mode, resource, scopes, Session lineage, expiry, and recent matching decisions.

Approval does not itself issue a credential. The waiting client retries the mint, which consumes the hold exactly once. A second consumer receives an already-consumed failure.

Use links from Subject, Session, Delegation, and Approval details into Audit. Filter by request ID, Authority record ID, or Session ID to confirm the original decision and the effect of a revoke, suspend, terminate, approve, or reject action.