Credential broker

Agents should never receive raw, long-lived secrets. The Credential Broker stores or references credentials outside agent prompts, issues short-lived scoped grants for approved work, and injects the real material only at the execution boundary. Every issuance, use, expiry, and revocation is audited, and everything fails closed.

Records vs grants

A CredentialRecord holds metadata only — kind, owner, backend, allowed scopes, rotation status, and an opaque backendRef (an installation id or token id). A raw secret is never stored in a Jentrix row.

A CredentialGrant is the short-lived, scoped, action-class-bound capability issued from a record:

bound to exactly one actionClass (e.g. repo:push);
short-lived (default ≤ 30 min, template-configurable);
policy-gated at issuance (the CREDENTIAL policy domain runs first);
fails closed on expiry, revocation, or an emergency-disabled record.

Not every governed action is brokered: a local commit (repo:commit, the harness commit boundary's first step) needs no remote credential, so Jentrix cannot mint one for it — it is a permission check + SHA/diff report under the runner contract (it honors freeze, leases, and policy, but is never brokered). Only the externally visible boundaries — push (repo:push), PR (repo:pr_create), merge (repo:merge), deploy/rollback — are brokered.

Injection boundary

The real secret is resolved only by resolveGrantForExecution(grantId, actionClass) at the moment of execution. It asserts the grant is ISSUED, unexpired, unrevoked, the record is not disabled, and the action class matches — then mints material from the backend and marks the grant USED. The raw secret is returned to the runner and never persisted (only an opaque materialRef is stored).

Backends

Backend	Status	Mints
`STACKS_TOKEN`	live	a scoped, short-TTL Jentrix PAT (`tm_…`) pinned to the workspace, with least-privilege scopes derived from the record's `allowedScopes`.
`GITHUB_APP`	live	a GitHub App installation token (the long-lived app key never leaves the server).
`VERCEL`	live	the configured `VERCEL_API_TOKEN` (cloud deploy/rollback). Vercel has no short-lived-token mint, so the single-use claim + short grant TTL are the boundary; the token is returned to the execution boundary and never persisted. Absent `VERCEL_API_TOKEN` ⇒ fails closed.
`CLOUD_STUB` / `COMMUNICATION_STUB` / `DOCS_STUB`	modelled	throw — the surface exists, the backend is not configured.

Per-operation delivery brokers

Inline governed delivery writes don't go through request_credential_grant (an admin-role tool) — they call a per-op broker that reuses the same machinery (CREDENTIAL policy gate, single-use CredentialGrant claimed ISSUED→USED before the mint, audited issuance) but is shaped for a member agent/op under governance, not an admin:

brokerRepoToken mints a per-op, repo-scoped, short-lived GitHub contents/pull_requests write token (branch / push / PR / merge), so the standing sync token stays contents-excluded.
brokerCloudToken mints a per-op, single-use VERCEL grant for the deploy:production / release:rollback delivery boundaries.

Every caller must first enforce workspace/task access, policy-gate the matching repo:* / deploy:* / release:* action, and (for the merge/deploy gates) resolve the human approval gate — the broker gates only credential issuance.

Revocation & emergency disable

Revoke a grant flips it to REVOKED and revokes any Jentrix token it minted.
Emergency disable a record sets disabledAt, blocks all future grants, and revokes every active grant the record issued.

A revoked or disabled grant fails closed: resolveGrantForExecution throws and yields no material.

Redaction everywhere

redactSecrets scrubs known secret shapes (GitHub / Jentrix / Slack / AWS / JWT / PEM keys) and any caller-supplied literal grant material from run logs, artifacts, Work Order materialization, agent-authored comments, and approval payloads — so a raw secret never lands in a prompt, an artifact, or a UI.

Where it lives

Manage records and grants at Settings → Credentials (admin-only): create a record (Jentrix-token / GitHub-app / Vercel backends are live), watch the grants table with status + expiry countdown, revoke a grant, or emergency-disable a record. Brokered credential events also surface in the Control Tower credential queue.

The broker has no read MCP surface — credential metadata and grant audit trails are admin-only and never expose secret material. The request_credential_grant admin-scope write tool is live: it mints a short-lived, scoped, action-bound grant, and the secret material is injected only at the execution boundary — never returned in the tool response.