--- title: "Manage Runtime Authority" url: "https://docs.caracal.run/v1.0/runtime-console/agents/" markdown_url: "https://docs.caracal.run/markdown/v1.0/runtime-console/agents.md" description: "Investigate Subjects and Authority records, intervene in Sessions and Delegations, and decide eligible Approvals." page_type: "workflow" concepts: [] requires: [] --- # Manage Runtime Authority Canonical URL: https://docs.caracal.run/v1.0/runtime-console/agents/ Markdown URL: https://docs.caracal.run/markdown/v1.0/runtime-console/agents.md Description: Investigate Subjects and Authority records, intervene in Sessions and Delegations, and decide eligible Approvals. Page type: workflow Concepts: none Requires: none --- 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. ## Related Pages * [Sessions and Revocation](/v1.0/concepts/sessions-revocation/) * [Session Delegation](/v1.0/concepts/delegation/) * [Approvals](/v1.0/concepts/approvals/) * [Inspect Diagnostics and Audit](/v1.0/runtime-console/observability/)