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.

Keep the Identities Distinct

Object	Meaning	Identifier relationship
Console account	A human authenticated to operate the console.	Not a workload Subject.
Application	A confidential client that asks STS for authority.	May act as itself or for a Federated user.
Subject	The stable JWT `sub` an application acts for: the application itself or a Federated user.	Grouping key in the Subjects workspace.
Authority record	One STS-issued authority anchor.	Its ID is carried as protocol `session_id`; it is not a Coordinator Session ID.
Session	A governed execution owned by Coordinator.	Its ID is carried as `agent_session_id`.
Delegation	Bounded authority from one Session to another.	Anchored by source and target Session IDs.
Approval	A human-decision hold raised for a requested action.	May link to Subject, Authority record, Session, Resource, and scopes.

Investigate a Subject

Open Subjects and pick a view: All Subjects, Application Subjects, or Federated users. Search by identity, sort by standing or recency, and open a Subject detail to see its 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.

Every Subject is one of two kinds. An application Subject appears when the application exchanges as itself. A Federated user appears when the application exchanges that user’s identity token from a registered Federated user issuer; the console records the issuer but never authenticates those users.

Intervene in Sessions

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.

Review and Revoke Delegation

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.

Decide Approvals

Approvals lists holds in these implemented states:

State	Meaning
`pending`	Waiting for an eligible approver until expiry.
`approved`	An approver satisfied the hold; the requesting exchange has not consumed it yet.
`consumed`	A retry used the approval; it cannot be reused.
`rejected`	An approver denied the request.
`expired`	The decision window ended.

A pending hold is decidable in the console only when its approver class is Zone operator or Operator or federated user. A Federated 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.

Correlate Every Intervention

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.