Skip to content

Platform Settings

The Admin page holds all platform-wide settings: users, agents, source control, and issue trackers. It is visible in the sidebar only to members of the Cognito platform-admin group (see Setup for bootstrapping the first admin); every underlying API is independently gated on the same group.

The page is organized into five tabs.

A read-only Deployment strip sits above the tabs, showing the canonical application URL, environment, and region. The hostname it reports is the one the backend puts in its OAuth redirect URIs, so it is what every provider's callback URL must match. If you are browsing a hostname other than the canonical one — a deployment with a custom domain still answers on the CloudFront domain and on every alias — the strip says so, because the callback URLs shown further down deliberately use the canonical hostname rather than the one in the address bar.

The hostname itself is not editable here. It is set by the app_domain Terraform variable, and changing it needs a certificate, a CloudFront update, and a frontend rebuild. See Setup → Custom domain.

Users

User Management — grant or revoke the platform-admin role for local Cognito users. Changes apply at the user's next sign-in. Self-demotion is blocked, so an installation cannot remove its current local administrator by accident. Federated users show their identity provider and effective mapped roles, but their role control is read-only because the external IdP is authoritative. See Enterprise SSO.

Day-to-day space access is not managed here — it lives in each space's Members tab.

Agents

Everything the agent runtime needs to run:

  • Platform Agent Credentials — fallback Bedrock Bearer Token (used by Claude Code, OpenCode, and Codex) and Kiro API Key values. Platform admins manage these SecureString parameters; a personal or space credential takes precedence. See Credential hierarchy and Prerequisites → Agent authentication.
  • Agent CLIs — enable or disable each agent CLI (Kiro, Claude Code, OpenCode, Codex) for the whole platform. A disabled CLI is greyed out on the intent compose page and in Space Settings → Agent, and the API rejects selecting it (agent_cli_disabled) when an intent starts, when you compose a draft with AI, or when a draft discussion assist runs. At least one CLI must stay enabled. Intents that already started on a CLI keep using it after it is disabled. All CLIs are enabled by default. Operators can pre-seed the set for a new deployment with the disabled_clis Terraform variable. Terraform applies that value only on first creation; after that, this switch owns it. A default model (including the codex_model Terraform default) only pins which model a CLI uses; it does not enable the CLI.
  • Default Models — the platform-wide default model per CLI (Kiro, Claude Code, OpenCode, Codex), selected from a dropdown of models discovered from the runtime (or "No default — use CLI built-in"). Codex uses Bedrock's OpenAI models with exact openai.* IDs (e.g. openai.gpt-5.5) — the chosen model must be available in the deployment Region. Spaces can override these per-CLI in Space Settings → Agent.
  • Graph Enrichment — a switch controlling whether the platform adds LLM-generated summaries to derived artifacts in the knowledge graph (llm or off). The setting takes effect for the next intent, never mid-run; enrichment spend is metered and surfaced on each intent's Audit page.

Credential hierarchy

Bedrock and Kiro credentials are resolved independently with this precedence:

personal > space > platform
  • Users manage personal credentials in Account Settings.
  • Space owners and admins manage shared credentials in Space Settings → Agent.
  • Platform admins manage fallback credentials in Admin → Agents.

The APIs return configured state and the effective source, never secret values. When a user selects a CLI for draft AI composition, a Quorum discussion assist, or intent start, the backend resolves that user's effective credential and sends only an opaque binding to AgentCore. AgentCore reads the bound SecureString for each invocation rather than retaining secrets in the long-lived process environment.

Starting an intent pins the selected CLI and credential binding for the run's lifetime. Rotating the value at that same scope takes effect on the next invocation; clearing or invalidating it fails the run instead of falling through to another scope.

Before a key is saved or cleared, the server checks which work already uses it. If nothing that has already started is affected, the change is saved straight away and the card says what it now means. Otherwise the card asks you to confirm and names, in plain words, the work that would lose access, needs reconnecting, or could not be checked, with Show details for the specifics. The server rejects the save if work or configuration changed after that check; save again to repeat it.

There is no intent-level credential store in this feature. An intent binds to one of the three managed scopes above but never owns a separate API key. Dedicated per-intent secrets would require a separate lifecycle and authorization design.

Environments

The environment area contains two administrator views:

  • Environments — compose exact published tool versions over a protected base, build and scan the resulting ARM64 image, validate its AgentCore runtime, and publish it for space assignment.
  • Tools — import, verify, publish, and recommend immutable tool versions. Java, Go, Rust, Maven, and Gradle are shipped as tool definitions rather than predefined environments. Administrators can add other tools such as .NET.

Only Standard is published as a system environment. Existing intents remain pinned to their exact environment revision when assignments, bases, or recommended tool versions change.

See Managed tools and environments for the complete administrator workflow: adding a tool, source provenance, build verification, security review, publication and recommendation, environment composition and updates, space assignment, and intent pinning.

Source Control

Platform-wide code-host configuration:

  • GitHub — GitHub OAuth app status and GitHub App identity/private-key configuration are shown simultaneously. Spaces choose OAuth or App independently; there is no global mode or installation ID. See Git integration → Space-bound authentication.
  • GitLab — the GitLab OAuth app credentials.
  • AWS CodeCommit — one shared connection for the whole deployment: the IAM role ARN and region every space uses. The card shows the platform principals, the deployment external ID, and the trust and permissions policies to hand to the AWS admin who owns the repositories; paste the role ARN and region and click Test & save to verify the trust and store the connection. Spaces then pick CodeCommit repositories from the usual list, with no ARN or IAM to supply. There is no per-user external ID. See Git integration → CodeCommit and Setup → CodeCommit.
  • Default PR strategy — Intent PR opens only the final intent-to-base review; PR per unit also opens draft unit-to-intent reviews and integrates them in dependency order. Spaces may inherit or override this default. The default is Intent PR.

Trackers

Issue-tracker OAuth apps and data migrations:

  • Jira Cloud — the Atlassian OAuth 2.0 integration credentials.
  • Source-control trackers — configuration status of GitHub Issues and GitLab Issues (these reuse the Source Control OAuth apps).
  • Tracker Migration — the one-time bulk migration for installs with pre-#194 data; shows a live count of legacy records and a Migrate all action. See Git integration → Migrating from legacy issue integration.

Until a provider shows Configured here, its Connect buttons across the product stay disabled with a hint pointing back to this page.

Not everything operator-facing lives on the Admin page:

  • Workflow and block authoring — the Workflows area, also gated on platform-admin.
  • Infrastructure-level settings — the upstream methodology pin (aidlc_repo_ref), the custom domain (app_domain), and the rest of the deployment configuration live in Terraform; see Setup.