Configuration reference
The verified startup settings and local defaults are documented in Getting started: configuration.
Configuration follows ASP.NET Core providers, so environment variables use __ for nesting. Persisted Model Provider, Model Profile, and Runtime Profile resources are Management data rather than host configuration. Prefer those resources for governed execution settings.
Do not commit API keys. HTTP payload capture is disabled by default, and sensitive prompts, documents, credentials, and agent output must not be logged by default.
Authentication
Agentstration:Authentication:Mode is Local, Oidc, Hybrid, Development, or Disabled. Local is the offline default. Development and Disabled are rejected outside Development and Testing.
Local mode uses ASP.NET Core Identity and ConnectionStrings:Identity, defaulting to .agentstration/identity.db. A fresh instance redirects the Console to the server-rendered /bootstrap page; the equivalent programmatic API remains available at GET/POST /api/auth/bootstrap. The submitted account has no default credential, becomes the first Platform administrator and Workspace Owner, and the bootstrap becomes inaccessible after initialization. /login, /logout, and /access-denied form the public Web authentication boundary. State-changing Web forms use antiforgery tokens and accept only local return URLs. Hybrid adds explicit OIDC login while retaining local accounts.
The Identity schema is managed by versioned EF Core migrations. Existing databases created by the earlier EnsureCreated implementation are baselined only after every expected legacy table is verified; a partial schema stops startup. ASP.NET Core Data Protection keys persist under Agentstration:Authentication:DataProtectionKeysPath, or in data-protection-keys beside the local data file by default. The directory must be writable and must be protected and backed up as sensitive instance state. Restoring the Identity database without its corresponding key ring invalidates existing cookies and lifecycle tokens. See ADR-0044.
After bootstrap, Platform administrators manage local accounts through /api/identity/accounts or Console Organization > Members. Workspace memberships are exposed under /api/identity/workspaces/{workspaceId}/memberships. Built-in roles are Owner, Admin, Member, and Viewer; the last Owner cannot be removed or demoted.
Instance administrators are listed with GET /api/identity/platform-administrators; PUT and DELETE /api/identity/platform-administrators/{principalId} grant and revoke the instance role. Console Organization > Members > Member details exposes the same operations. To replace the bootstrap administrator, grant an active successor, authenticate as that successor, then disable and optionally revoke the predecessor. Self-revocation, self-disable, granting a disabled Principal, and removal of the last active administrator are rejected. Disabling retains the grant until it is explicitly revoked. See ADR-0046.
Authenticated local users manage their credential from /account/security. Changing the password requires the current password and refreshes the current application cookie. The Sign out other sessions action rotates the ASP.NET Core Identity security stamp, invalidating other application cookies while retaining the current session. There is intentionally no anonymous password-recovery flow in this iteration.
Security-sensitive identity and authorization operations are appended to SecurityAuditEvents in the Management Control Plane database. Platform administrators can inspect the latest 200 records through /api/identity/audit-events or Console Organization > Security audit. Events contain identifiers, bounded outcome codes, scope, timestamps, and trace correlation only; they never contain credentials, submitted usernames, email addresses, claims, or tokens. Retention, export, and cryptographic sealing are not yet implemented. See ADR-0045.
OIDC mode requires Authority, Audience, and ClientId; ClientSecret is required for confidential clients. RequireHttpsMetadata defaults to true. OIDC uses authorization code with PKCE and APIs validate JWT bearer access tokens. Agentstration never uses email as a subject, never maps an IdP tenant to a Workspace automatically, and never issues OAuth access tokens. See ADR-0042.
Platform administrators link an existing Principal to an external identity through /api/identity/principals/{principalId}/external-identities or Console Organization > Members > Member details. Enter the exact case-sensitive iss and sub values emitted by the configured provider. The pair is instance-unique; the same subject from another issuer remains distinct. Agentstration rejects removal of the final authentication method and does not auto-link by email or auto-provision unknown logins. See ADR-0047.
Each Console API endpoint supports ForwardSessionCookie. It is false unless explicitly configured; the shipped standalone profile enables it because Management, Runtime, Work, and Flow APIs are routes of the same process. The handler forwards only the Agentstration application cookie to the exact configured origin, disables redirects, and transmits the resolved Workspace selection without bypassing membership or policy checks. Leave this option disabled for a remote API unless it is deliberately part of the same Web session boundary. Independently deployed APIs should use audience-bound Bearer access tokens instead. See ADR-0043.