[Feature]: Hierarchical agent credentials and per-intent CLI selection

[JWThewes]

Description

Agent credentials are currently configured only at platform level. The Bedrock bearer token and Kiro API key are shared by every space and user, so all usage is charged to one Bedrock key or one Kiro identity. In a multi-user installation this makes cost attribution difficult and can exhaust the credits of the shared Kiro user very quickly.

The agent CLI is also selected at space level today, although the CLIs a user can actually run depend on which effective credentials are available when that user starts an intent.

Add agent credentials at three scopes:

1. User
2. Space
3. Platform

Resolve each credential type independently with this precedence:

user > space > platform

An unset value falls through to the next scope. A configured but invalid credential must fail with an actionable error instead of silently falling back and charging a different scope.

Use case

Organizations should be able to provide a platform-wide fallback, let a space use its own budget, or let an individual use personal credentials. This distributes usage and cost to the intended Bedrock account or Kiro user while retaining convenient shared defaults.

A user starting an intent should see and choose only the CLIs supported by the effective credentials available to that user in that space. If no credential is available at any scope, the intent cannot start and the user is directed to configure a personal credential first.

Area

Agents / AI

Additional context

Proposed behavior

Credential scopes and permissions

• Platform admins manage platform credentials in Admin -> Agents.
• Space owners/admins manage space credentials in Space Settings -> Agent.
• Each user manages personal credentials in their user/profile settings.
• APIs never return secret values after saving them. They return only configured state and the effective source (user, space, or platform).
• Clearing a credential makes that scope unset and restores inheritance from the next scope.

Precedence is evaluated separately for the Bedrock bearer token and Kiro API key. This allows combinations such as a personal Kiro key together with a space-level Bedrock key.

CLI and harness availability

CLI availability is the intersection of installed runtime capabilities and effective credentials:

Effective credential	Available CLI / harness
Kiro API key	Kiro
Bedrock bearer token	Claude Code, OpenCode, Codex
Both	All installed CLIs above
Neither	None

Kiro must never appear as available unless an effective Kiro API key exists. Likewise, the Bedrock-backed CLIs must not be selectable without an effective Bedrock bearer token.

Intent start

• Move the execution CLI choice from being a space-level source of truth to the intent compose/start flow.
• Require the user to explicitly select one of the currently available CLIs before starting the intent.
• A space-level CLI setting may remain as a suggested default, but it must be confirmed at intent start.
• Snapshot the selected CLI on the intent so resumes and later stages use the same harness.
• Resolve credentials in the context of the user who starts the intent and bind the run to an opaque credential reference/source, not to a plaintext secret. Later gate answers by other collaborators must not silently switch the billing identity.
• If the bound credential is removed, unavailable, or invalid during a run, park/fail the run with an actionable credential error. Do not silently switch to another scope mid-intent.
• When no CLI is available, disable start and show a direct action to add a personal Bedrock or Kiro key.

Runtime and secret handling

The runtime currently reads platform credentials at container startup. Supporting space and user credentials requires per-run resolution rather than relying only on global environment variables.

• Resolve the effective credential server-side at intent start/dispatch.
• Store credentials in an encrypted secret store with scope-specific paths and authorization.
• Persist only an opaque reference and credential source with execution metadata.
• Fetch/inject the secret only inside the execution boundary that needs it.
• Never include secret values in intent records, API responses, event payloads, logs, transcripts, or observability data.

Acceptance criteria

• Bedrock and Kiro credentials can each be configured at platform, space, and user scope.
• For each credential type, resolution follows user > space > platform and falls through only when a value is unset.
• Effective CLI availability follows the credential mapping above, including mixed credential sources.
• Users choose the CLI when starting every new intent.
• Starting is blocked with a clear personal-key setup action when no CLI is available.
• The selected CLI and opaque credential binding are stable for the lifetime of the intent.
• Existing platform credentials continue to work as the fallback without migration by operators.
• Existing intents keep their already-snapshotted CLI behavior.
• Authorization prevents users from reading or modifying credentials outside their permitted scope.
• Automated tests cover precedence permutations, mixed Bedrock/Kiro scopes, no-credential behavior, authorization, credential removal/rotation, and secret redaction.