Review configuration changes

Tasks

Current coverage

Recorded operations include application Settings saves, onboarding, provider, route, and pool updates/deletes, network-filter and trusted-proxy configuration, cluster OIDC and legacy portal OIDC configuration, tool-access overrides and rescan intervals, capture and optimization settings, effectiveness configuration, and team creation/metadata updates with their SSO group bindings. Team deletion, membership replacement, team model permissions, personal datasource credential creation/replacement/deletion, PAT revocation and administrator model-scope edits, and local service-account creation/deletion/secret rotation are also recorded. Global model-ceiling changes, developer override removal, gateway OAuth-client registration/deletion, administrator and developer SSO key uploads, and policy creation, editing, condition appends, cloning, enable/disable, enforcement-mode changes, and deletion are also recorded. Configuration audit retention, purges, upstream credential-encryption migration, and mutation attempts rejected by role middleware are recorded as well.

Policy-exception creation/editing, enable/disable and deletion, direct administrator configuration-exception grants, and individual granted-exception revocation are recorded as well.

Local user creation, edits (including passthrough permission), deletion, portal password changes, and administrator password resets now commit with their audit events. Developer PAT creation, model-scope changes, and revocation are also recorded. Failed audit writes preserve the previous user or token state and do not return a new password or token.

Setup and bootstrap users, OIDC user/team provisioning, profile edits, proxy-user creation/editing/deletion and password changes, explicit session revocation/resume, administrator PAT issuance, and OAuth connection creation/replacement/refresh/deletion are now recorded by the SQL-backed paths.

Modern administrator/developer SSO saves, automatic OAuth client registration and updates, license installation/removal, startup setting seeds, budget migration, and built-in/external policy seeding are also recorded.

Developer model grants, session-request decisions and their model/budget/session changes, exception escalation and co-sign decisions, and developer access approval/rejection are also recorded.

MCP server creation, edits, deletion, quarantine decisions, drift-response mode, default tool action and data classification are recorded. Access-binding and toolset creation, edits and deletion are also recorded by the SQL-backed paths.

Explicit session creation, service-account sessions, replacement handoffs, and purpose/ticket edits are recorded. Failed audit persistence prevents new token delivery and preserves the previous session state.

Managed integration saves, manual identity attribution mappings, governed-agent creation, identity autonomy-tier changes and stale-identity deletion, project creation/edits/deletion, legacy organization saves/deletion, model-cost/catalog refresh, skill-risk settings, workload enforcement enable/disable, workload registration deletion, and notification routing are also recorded by the SQL-backed paths.

Two limits remain. Effects that reach an external provider (Okta provisioning, OAuth issuers, notification deliveries) cannot be rolled back together with the local record; each such workflow documents its recovery steps below. Multi-stage sign-in and declaration-to-enforcement flows record each stage they complete rather than one end-to-end event. User-management and service-account mutations require an identity provider that supports audited persistence; providers without that capability reject the write.

Review and export

Administrators and viewers can read configuration audit history. The Configuration tab and its exports exclude session lifecycle events; those appear under Session lifecycle. Each tab’s count represents its own category. The Gateway count stops at 10,000 and shows 10,000+ when more gateway records match; the All activity count then also ends in +. Narrow the time range or actor filter for an exact count. The other tab counts are always exact. Open in Session and Open in Configuration open the selected source event, even outside the current page or filters. Closing its drawer clears the record link; an unavailable session record offers a retry.

The All activity API returns an opaque nextBefore cursor. Pass it back unchanged as before to retrieve the next page. Pages respect the requested limit even when thousands of records share a timestamp. Older timestamp-only before values remain accepted.

OAuth token refresh preserves the caller’s audit identity and request metadata when provided; background refreshes are attributed to the system. Developer session revocation records the authenticated owner’s email when no richer caller identity is available.

1. Open Security → Activity and select the Configuration tab. The All activity tab on the same page shows configuration changes in one timeline with security events and gateway calls, so you can see what followed a change.
2. Choose a time range and filter by actor email or ID, action, category, outcome, or search text. The actor filter matches any part of a recorded ID or email, ignoring letter case; percent signs and underscores are treated literally. Search matches the event summary and target name.
3. Select a row, or focus it and press Enter or Space, to inspect its actor, target, request context, and recorded before and after values. Redacted means the value was deliberately omitted; it does not mean the value was empty. In JSON exports, absent before/after evidence is an empty object ({}), and an empty changed-field list is [], including for older events.
4. Choose Export → Export CSV or Export JSON to download matching events. Export uses the filters, independently of the current table page.

The actor filter and time range are shared across Activity tabs and their counts.

To investigate verification without registration, filter the Configuration tab by category workloads and action workload_protection.verified_without_registration. The system event records the workload's cluster, namespace, kind, name, verification reason, and enforcement operator and time. It is emitted once per entry into Discovered · Verified. If audit persistence fails, reconciliation preserves the previous workload record and retries on a later pass.

A link containing only a start or end time keeps that bound in each tab and its export. The time picker shows From or Until for these open-ended ranges; choose All time to clear the bound, or complete the missing date to apply a bounded range. Record rows in All activity and Session lifecycle also open with Enter or Space when focused. Gateway exports preserve the shared actor and exact time range; All time exports have no time bounds. The drawer’s Around this time panel uses an exact recorded email or ID match within ten minutes of the selected record. If nearby activity cannot be loaded, choose Retry; a failed lookup does not mean that no related records exist. A related record outside the visible rows opens as an isolated 1 / 1 record. Changes made in Security or Configuration stay selected when you switch tabs. With no time range selected, Gateway shows All time.

On a large audit log, Gateway shows a loading indicator until its first page arrives. Its row total, pagination, and export labels stop at 10,000 and show 10,000+ when more records match; narrow the time range to count exactly. The standalone Live Activity page opens on Last 24 hours and the embedded Gateway tab opens on All time; pick either range in the time range picker. A request to the audit events API that asks for a bounded total (capTotal=true) and names no time range, session or event searches the last 24 hours unless it sends allTime=true. If counting takes more than a few seconds, the page of rows still loads and the total shows a lower bound with +. If the read itself times out, Gateway shows Could not load Gateway activity with a Retry button instead of an empty table, and narrowing the time range or filters makes the request cheaper.

Observer events and session navigation: The Observer tab loads its events only while it is open, and its list leaves out prompt, tool input, tool result and response text; that text is loaded when you open an event. Stepping to the previous or next event in a session works for sessions of any length: the drawer looks up the neighbouring event rather than loading the whole session.

Opening a Gateway record by a direct link can show an event outside the loaded page or filters. A malformed or unavailable record ID never substitutes another event. Its drawer shows 1 / 1 and disables previous/next navigation until you select a record from the table.

Record drawers on the Activity tabs cover half of the window. On windows narrower than 900 pixels, they fill the window.

On the Security, Session lifecycle, and Configuration tabs, the page URL contains the open record, for example ?tab=configuration&record=<id>. Copy the URL to share the record. Opening a record adds an entry to your browser history, so Back closes the drawer. Moving to another record with the arrow buttons or the ← and → keys replaces the entry instead, so one Back still returns you to the list. If you open the drawer from a shared link, Close removes the record from the URL and keeps you on the page. The arrow keys don't run while your cursor is in a text field. A link with an empty, malformed, or deleted record ID shows a message and opens the list without a drawer. If the record fails to load for another reason, the page keeps the link and offers Retry.

On All activity and Session lifecycle, select Load older activity when it is available, even if the current filters show no matching rows. Older matches may remain beyond the events scanned so far. Exports continue through these pages automatically.

Exports contain at most 10,000 events. A partial export is explicitly marked: JSON includes truncated, CSV includes exportTruncated, and the page displays a warning. Narrow the filters when you need a complete export within that limit.

Opaque configuration values are omitted because they can contain credentials. Reviewed scalar settings show their before/after values when they are safely typed: booleans, finite numbers, and explicitly allowed product enums such as session grouping and HITL timeout action. Unknown or invalid scalar representations remain redacted. JSON/YAML documents, credentials, URLs, tokens, free-form text, and arbitrary metadata remain redacted. Team metadata changes show the changed fields; arbitrary label values are redacted.

Personal datasource credential events identify the owner and datasource without exposing the token, prefix, encrypted value, or fingerprint. Unchanged saves and repeated deletion/revocation do not create duplicate events. If credential storage is unavailable, deletion returns an error instead of reporting success.

Manage retention

Only administrators can change retention or purge history. Retention controls stay disabled if the current settings cannot be loaded; select Retry to load the stored value before editing.

1. Open Settings → Data → Configuration audit.
2. Set the retention period in days and select Save retention. The default is 365 days; 0 keeps history forever. Retention is independent of AI request logs.
3. To remove older events immediately, enter an age of at least one day, select Purge history, and confirm the cutoff.

Automatic cleanup runs daily. Manual and automatic purges record each committed deletion batch. If storing that evidence fails, the corresponding deletion batch is rolled back. A later batch failure can leave earlier batches committed; the returned deletion count reports the committed work.

For audited configuration writes, an audit-storage failure also rolls back the configuration change. Retry after storage is healthy. An authorization refusal remains a refusal even if its audit record cannot be saved.

SSO key uploads reject a concurrent configuration change with HTTP 409; retry the upload after refreshing the configuration. Identical encrypted keys do not create duplicate audit events. If a configured encryption key cannot encrypt the upload, the save fails. Gateway-client evidence omits credentials, key material, and redirect URI contents. Deleting a gateway client prevents new sign-ins through it; previously issued access tokens retain their own expiry and revocation lifecycle.

Policy saves, clones, and condition appends fail if their audit event cannot be persisted. If the policy changes after the server reads it for an edit or clone, the request returns HTTP 409; reload and retry. Clones remain disabled until enabled explicitly. Policy content is redacted in audit evidence, including YAML and descriptions, while the changed fields remain visible.

Exception writes and individual grant revocations roll back when their audit event cannot be persisted. A concurrent exception edit returns HTTP 409; reload and retry. Revocation retries preserve the original revoker and timestamp and do not send duplicate notifications. Direct configuration grants distinguish invalid requests (HTTP 422) from persistence failures (HTTP 500). Grants made through the approval workflow are recorded in the same transaction as the decision that produces them. Session-scoped grants are revoked and recorded together with the session revocation or expiry that ends them, with expiry revocations attributed to the system.

User edits compare the server-read record with the stored record before saving. If another write wins during that request, refresh and retry after the HTTP 409 response. Password changes also reject an authenticated password snapshot that a concurrent reset has replaced. User labels and password hashes are redacted from evidence.

Developer PAT events identify the owner and changed model scope. Token values, hashes, prefixes, and free-text descriptions are omitted or redacted. Scope edits and revocation check ownership again during the write; repeated unchanged scope edits and revocations do not create extra events.

Administrator token issuance saves the token, its ingest scope, any required PAT enablement, and welcome-password changes together. If auditing fails, the previous configuration and passwords remain in place and no new token or password is returned. Issued welcome passwords must be changed at the next sign-in.

OIDC login saves newly provisioned users, teams, group bindings, and team assignments together. A failed save prevents that login from issuing a session. Existing administrator-assigned roles are preserved.

Explicit session revocation records the session transition and revokes its current active session-scoped exception grants in the same transaction. Resuming a paused session is audited; repeating a resume or revoke does not repeat the same transition event.

OAuth refresh refuses to overwrite a connection that was disconnected or replaced while the provider request was in flight. Audit persistence failure stops credential delivery. An OAuth provider can rotate its refresh token before local persistence fails; in that case, reconnect the account if the previous refresh token is no longer accepted.

SSO saves commit the developer configuration, derived console configuration, and legacy compatibility setting together. An audit failure leaves all three unchanged and prevents live reconfiguration. If applying the saved configuration fails, the server attempts an audited restoration of the previous settings. A restoration failure is reported explicitly; another administrator's newer save is preserved. Database persistence and live identity-provider state do not share a transaction, so a peer may briefly observe a committed configuration before restoration.

License upload and removal require successful audit persistence. Removal also verifies that the license has not changed since its blocked status was checked. License contents are omitted from evidence. Startup setting and policy seeds identify their system writer; unchanged policy content does not generate repeat events.

Session-request approval saves its decision and the resulting model grant, budget change, resume, or extension together. Exception co-sign decisions save the vote, quorum result, and grant or denial revocation together. If any audit insertion fails, those changes roll back and the request can be retried. Repeated decisions do not repeat a grant or budget increase.

Developer access approval saves account creation or reactivation, the welcome-password reset, and the request status together. A failed audit returns no new password and sends no welcome notification. Approval notes, rejection reasons, password hashes, and arbitrary grant parameters are redacted from configuration-audit evidence.

MCP server changes and their audit evidence commit together. When connecting or editing a server automatically adds its host to the global egress allowlist, that setting and its evidence commit with the server. Discovery previews the proposed host while preserving narrower restrictions; live tools and forwarding credentials change only after the save succeeds. If persistence fails, the previous configuration remains active. Server deletion also removes cached tools in the audited transaction.

Access-binding and toolset saves and deletions fail when their audit record cannot be persisted. Unchanged saves do not add duplicate evidence. These events show changed fields, but redact credentials, URLs, command arguments, descriptions, and serialized selectors.

Managed integration saves fail if their audit evidence cannot be stored. The previous configuration remains active, and the refresh revision used by other replicas is saved with the configuration. If another save changes the integration while your request is merging masked credentials, your save is rejected; reload the form and retry. Credentials are omitted from audit evidence.

Model-cost refresh saves the cost table and model catalog together before applying them. A concurrent edit returns HTTP 409; refresh and retry. An audit failure preserves both previous documents and prevents live publication. Skill-risk saves also require successful audit persistence before applying the new weights.

Manual identity mapping changes save the mapping, affected pull-request attribution, history and audit evidence together. Project and identity changes show the changed column names while redacting stored values. Creating a governed agent records its local registration; provider provisioning is a separate operation.

Deleting an organization through the legacy organization API also removes its group mappings and repairs affected users' team assignments. Users with no remaining team move to the default team; primary-team assignments remain valid. The built-in default team cannot be deleted. If auditing fails, the organization, mappings and memberships remain unchanged.

Workload enforcement events record the saved operator decision; enforcement still depends on controller reconciliation. Deleting a workload registration removes the registration, not the running workload. Notification routing saves commit the entire submitted batch with its evidence; an audit failure leaves the previous routes in place.

Per-agent identity provisioning now requires an unchanged governed-agent record and successful audit persistence before returning credentials. Per-server OAuth client replacement, for shared and per-agent setup, commits in place with its audit event; failures preserve the previous client. Concurrent edits or agent deletion reject the stale save. Okta-side changes are separate from local persistence; see provisioning recovery.

Shared identity provisioning also commits its encrypted identity record with audit evidence before returning a private key. A concurrent setting change returns HTTP 409 and preserves the newer record. Persistence failures return no key; Okta-side changes may already exist and require the same provider-state review before retrying.

MCP-server deletion now includes its local OAuth-client records as well as cached tools. Rejecting any client or final server audit event rolls back the whole deletion. Concurrent Agent OIDC per-server client provisioning either commits before that cleanup or rejects the missing server; it cannot commit a client for a deleted server. Automatic quarantine placeholders also use audited insertion with a serialized capacity check.

Public OAuth dynamic registration also checks a scoped MCP server inside the audited save. If the server is deleted during registration, the request returns HTTP 409 without a client ID; reload the server configuration before retrying. Global OAuth registration remains supported. These events identify the caller as unauthenticated rather than as a system job. Registration cannot overwrite an existing client on an ID collision.

Credential issuance and failed sign-in

GitHub-token exchange saves the replacement PAT, revokes previous GitHub-exchange PATs for that user, and records those changes together. If this save fails, the previous PAT remains active and the cached upstream GitHub token is unchanged. Upstream token sharing between replicas remains a separate operation after the PAT is saved.

Self-service and authorization-code PAT issuance, OAuth PKCE tokens, and ID-JAG access tokens are returned only after their credential record and audit event are saved. Events identify the verified user and authentication method; they do not contain bearer tokens or token hashes.

If issuance fails after a code or grant has been consumed, start sign-in again or obtain a fresh ID-JAG assertion. Reusing the same code, organization-selection link, or grant will fail. A lost success response can mean the credential was saved but not received; its one-time value cannot be recovered from the audit trail.

Platform passwords and provider keys

Password updates received from the managed platform save the local password, temporary-password flag and audit event together. If this save fails, the local password stays unchanged. The event identifies the verified platform service making the request. A password already changed in the external platform is a separate operation; retry synchronization when local persistence is available.

Provider-key creation and virtual-key issuance, revocation and deletion are recorded with the verified administrator identity. If auditing fails, no new virtual token is returned and existing keys remain unchanged. Deleting a provider key also deletes its dependent virtual keys; all deletion events are saved together. If the provider disappears while a virtual key is being issued, creation returns HTTP 409 without a token. Reload the provider list before retrying.

Deletion blocks subsequent use of the removed keys. It cannot recall requests that already resolved a credential. These transactions do not repair virtual-key rows left behind by deletions made before this behavior was introduced.

History resets and finding decisions

Administrative history resets record the selected scope and deleted-row counts. Resetting audit history or metrics affects only that data. Reset-all also removes budget windows, agent risk scores, baseline state and alerts, and skill inventory and behavior profiles. The configuration audit trail is preserved, including the reset event. If that event cannot be saved, the deletions are rolled back and the request fails. An empty reset is recorded too.

The local history view is cleared only after the database save succeeds. Active traffic can immediately add new history; another replica may still show cached entries. A reset does not stop ingestion across the deployment.

Confirming a false-positive finding with Disable detector now saves the report decision and detector change together. If either save or its audit event fails, the report remains pending and the detector setting is unchanged. Retry after persistence is restored. A malformed detector setting must be corrected before retrying. Dismissing a report or deciding a policy-only report does not disable a detector. Concurrent confirmations preserve each other's detector changes, and an already-decided report cannot be decided again.

Tool baselines and Okta connections

Blocking an ungoverned MCP server, accepting a tool's current schema as its new baseline, and refreshing tool baselines now save the change and its audit event together. If audit persistence fails, the previous baseline remains and refreshed tools are not published. If another scan or re-pin changed the baseline, retry the refresh. Updating only when a tool was last seen does not add an audit event.

Connecting or disconnecting either Okta connection saves redacted evidence of the change. A failed save preserves the previous credential and trusted-provider state. Disconnecting the read-only Discovery connection or the write-scoped setup connection retains the other connection and the separately provisioned agent identity. It does not remove external Okta objects. Runtime trust updates on other replicas converge after the database save.

Project candidate decisions

Confirming or dismissing a project candidate saves all affected sessions and their audit events together. If persistence fails, none of the batch is accepted; retry after persistence is restored. Repeated decisions with no remaining matches do not add events. Project names and model explanations are redacted in the evidence.

A background attribution sweep preserves assigned projects and dismissed candidates, including when its model response arrives after your decision. Dismissing a candidate does not remove a project that was already assigned. Your decision applies to the sessions in that batch; it does not prevent new suggestions on future sessions. Malformed stored candidate data must be repaired before the batch can succeed.

Session budget increases

A direct session budget increase saves the new budget, extension count, and audit event together. If audit persistence fails, the previous budget and count remain. The event records the administrator and the before/after budget and count. Concurrent increases preserve each accepted amount.

Increasing a budget does not resume a session or extend its expiry. Each accepted request adds the amount again. If a response is lost, check the current budget and audit history before resubmitting the same increase.

External operations and multi-stage workflows

The configuration audit covers the supported administrative mutations. External provider operations, multi-stage sign-in, and declaration-to-enforcement workflows have the transaction and recovery limits described below. A committed audit event confirms the recorded stage; check the downstream state before assuming the whole workflow has finished.

OAuth revocation returns HTTP 503 if its database or audit write fails; retry the revocation instead of assuming the credential was revoked. Unknown or already revoked tokens still return success. Workload-trust settings take effect only after the setting and its audit event are saved.

A multi-field settings request can save earlier fields before a later field fails. Reload the settings and review committed events before retrying. External Okta operations have separate recovery limits.

Workload registrations and personal preferences

Onboarding or editing a workload registration saves the registration, its override, and the audit event together. If auditing fails, the previous registration remains. A conflicting edit returns HTTP 409; reload before retrying. A saved registration does not mean controller reconciliation or enforcement has finished.

Coach defaults, leaderboard consent, and notification delivery preferences save with the verified user's identity. Partial updates preserve omitted fields, even when different preferences are changed concurrently. Empty or unchanged updates do not add events. If auditing fails, existing preferences stay unchanged. Preference values are redacted in the audit trail. Changing delivery preferences does not recall messages already queued or being delivered.

Sign-in identities, platform licenses, and workload declarations

Automatic identity metadata changes are audited; last-seen and request counters do not create audit events. Password, email-OTP, and OIDC session events identify the verified caller and authentication method. Identity or builder registration failure during OIDC sign-in withholds the credential. A later issuance failure can leave an already-audited identity or user record. Start sign-in again when a code or OTP has been consumed.

License uploads from the managed platform identify the verified platform service. Failed audit persistence preserves the previous license.

Kubernetes policy apply/delete has separate requested and completed/failed events linked by request ID. A requested event alone is not proof of enforcement. After a timeout or missing outcome, inspect live policy status and let reconciliation retry. SQL persistence cannot undo a Kubernetes change that has already happened.

The Actor column shows the recorded identity and its type: User, Service account, PAT, or System. Actor sorting uses the displayed email, falling back to the recorded identity ID. Target sorting likewise uses the displayed name, ID, or type. Open an event to inspect its authentication method. Changes to PAT availability show boolean before/after values; credential contents remain redacted.

Concurrent changes and retrying operations

If an MCP server save succeeds but its tools cannot be published, the request reports that configuration was saved. In the Add/Edit MCP Server drawer this appears under a Could not complete save banner (not Connection failed) with the server's message. Reload the server list and use Refresh to retry discovery and publication. For per-developer authentication, use Edit with a discovery token when required. Existing live tools remain available when an update's baseline save fails; newly discovered tools are withheld.

Editing an MCP server that someone else modified concurrently returns HTTP 409; reload the server's current configuration and reapply your change. In the Add/Edit MCP Server drawer this appears as a Saved by someone else banner, distinct from the Connection failed banner shown when the upstream server itself cannot be reached — your changes were not saved, so close the drawer, refresh the list, and reapply them to the current configuration. The same banner covers a server name that was just created by another concurrent request, one that was deleted while your drawer was open, and one that gained a stored record while your drawer was open.

Not every 409 on these endpoints is a concurrent change. The ones that are not appear under a Could not save banner with the server's own message, rather than asking you to reload and reapply — none of them is resolved that way:

• Adding a server under a name that already exists reports that the name is taken. Edit the existing server, or add yours under a different name. The existing server is never overwritten by an add, including when two people add the same name at the same time — one succeeds and the other gets this message.
• Adding a discovered app that someone already promoted reports already added as <name>.
• Editing a server whose name comes from the config file reports that it always takes precedence and cannot be edited through the API.

If the stored MCP server records cannot be read, the server list reports Could not load MCP servers rather than showing an empty or partial list — an incomplete list would hide quarantine state and stored-record status, and the page never presents a failed read as "no servers configured". Everything derived from that list fails closed with it: the server cards are hidden, including any that were on screen before the read failed; the counts above them read Server counts unavailable rather than reporting a stale tally as current; and an Add/Edit drawer left open from before the failure shows Server list unavailable — saving is paused and disables its save, because the record version it is holding may no longer be current. Whatever you have typed is kept — reload the page and reopen the server to save it. Adding a new server is unaffected.

If a save succeeds but AIControls cannot confirm it is safe to publish — the stored records became unreadable between saving and publishing — the request reports HTTP 503 with configurationSaved: true, and the previous configuration stays live. Your change is stored; reload the server list and use Refresh to apply it. This is distinct from a save that was simply superseded by someone else's newer edit, which succeeds: their edit governs what is live.

If the records become unreadable only after publishing, the save succeeds: the new configuration is live, and only the cached tool list was not refreshed. The update reports success with a warning that tool counts may be out of date until the next Refresh — there is nothing to re-apply.

Adding or editing a server can automatically widen the Global egress allowlist to cover its host. If that widening is stored but cannot be applied to the running proxy, the request reports HTTP 503 with configurationSaved: true and says the network allowlist could not be applied: the server is saved, but calls to it may be denied until the allowlist reaches the proxy. Reload the server list and use Refresh — a successful save never reports the allowlist as applied when it is not.

You can edit the purpose and ticket of a paused session. A conflicting context edit returns HTTP 409: reload the session before retrying. Expired or revoked sessions cannot be edited. Revoking an unknown PAT, or a PAT you do not own as a non-admin, returns HTTP 404.

Approvals for a session that has been deleted or has ended can still be resolved. The decision is recorded without changing or recreating the session; an approved request alone does not prove that the requested session effect occurred.

Source IP uses the client address resolved by trusted-proxy middleware when available, and otherwise the connection's peer address. Forwarding headers alone are not trusted. Key lifecycle events retain status, expiry, spending cap and recognized provider values; credentials and free-form metadata remain redacted.

Policy saves return HTTP 503 if the required audit storage is not configured; no policy is saved. Other persistence failures return HTTP 500.

Discovery workload-kind settings return HTTP 503 when the audited save cannot be persisted. Retry after storage is available. Workload-trust persistence errors are recorded in server logs; the API response keeps internal database details private.