Credential Handling for AI Agents: How DAVE Stores Provider Keys Securely

An API key for a conventional SaaS integration is a nuisance if it leaks: someone might read data they should not. An API key for an AI provider is a different category of risk. A leaked OpenAI or Anthropic key can generate thousands of dollars of charges in minutes, expose proprietary prompt logic, and give an attacker access to any data your agents are processing. The blast radius of a leaked AI provider key is larger, faster, and harder to contain than most credential leaks.

This is why the security model for AI provider credentials deserves explicit scrutiny, not just a checkbox on a vendor security questionnaire. The relevant questions are specific: Where is the key stored? What encryption is used? Can the key be retrieved through the API? Who can see it in the UI? Is it ever written to a log? Each of those questions has a concrete answer in DAVE, and each answer is a control you can verify rather than a claim you have to take on trust.

The second reason credential handling matters for AI specifically is the centralisation model. In DAVE, provider credentials are not stored per-agent or per-workflow: they are stored once in a provider record, and every agent that uses that provider references the same credential. This is the right architecture for key rotation and access control, but it means the provider record is a high-value target. The security controls on that record need to match its importance.

When you save an API key in a DAVE provider record, it is encrypted before it is written to the database. The encryption algorithm is AES-256-GCM, an authenticated encryption scheme that provides both confidentiality (the key cannot be read without the encryption key) and integrity (any tampering with the ciphertext is detectable).

The GCM (Galois/Counter Mode) component is significant. Unlike older encryption modes, GCM produces an authentication tag alongside the ciphertext. When the value is decrypted, the authentication tag is verified first. If the ciphertext has been modified in any way, decryption fails rather than silently producing garbage output. This means that even if an attacker gains access to the encrypted database and modifies a stored credential, the modification is detected at decryption time rather than passed through to an agent call.

Encryption is applied at the application layer, before the value reaches the database. This means the database itself never holds a plaintext API key. A database backup, a database replica, or a direct database query returns only the encrypted ciphertext, not the original key value.

The encryption is per-tenant: each tenant's credentials are encrypted with keys scoped to that tenant. A compromise of one tenant's encryption context does not expose another tenant's credentials. This is part of DAVE's broader per-tenant isolation model, which also applies to workflow data, audit logs, and user records.

Once an API key is saved in a provider record, DAVE's UI treats it as a write-only field. The key field uses a password input and is masked by default: the value is displayed as dots rather than characters. This applies both when viewing the provider list and when editing an existing provider record.

The eye icon next to the API key field toggles visibility temporarily for the current session. This is a UI convenience for verifying that a key has been entered correctly before saving, not a mechanism for retrieving a stored key. Once the provider record is saved, toggling the eye icon reveals the masked field, not the underlying plaintext value.

This masking behaviour is enforced at the UI level and reinforced at the API level. The API does not return credential values for stored providers. If you retrieve a provider record through the API, the response includes the provider's name, type, base URI, and model catalog, but not the API key. The key is write-only from the perspective of any API consumer, including the frontend application itself.

The practical implication is that key rotation in DAVE is a one-way operation per entry: you can overwrite a stored key with a new value, but you cannot retrieve the old value to compare or archive it. This is the correct behaviour for a credential store. If you need to verify which key is stored, the correct approach is to test connectivity using the Fetch Models button, which exercises the stored key against the live AI service without exposing the key value.

API keys in DAVE are transmitted only over HTTPS. This applies to both directions: the key you enter in the browser is sent to the DAVE backend over an encrypted TLS connection, and when DAVE calls an external AI service using the stored key, that outbound call is also made over HTTPS. There is no plaintext transmission path for credential values.

Keys are never logged in plain text. DAVE's audit log captures a sanitized version of request details: known sensitive fields, including API keys, passwords, secrets, and tokens, are automatically redacted before the event is written to the audit log. This means that even if the audit log is exported and shared with an external auditor, it cannot be used to recover credential values. The redaction happens at capture time, not at display time: the plaintext value is never written to the log storage layer.

This logging behaviour is relevant to SOC 2 and GDPR compliance. Both standards require that audit records do not themselves become a new attack surface. A log that captures raw API keys in request bodies would satisfy the letter of audit logging requirements while creating a credential exposure risk. DAVE's automatic redaction of sensitive fields closes that gap.

The combination of HTTPS-only transmission and plaintext-free logging means that the only place a credential value exists in plaintext is in memory during the brief window between decryption and use in an outbound API call. It is never persisted in plaintext form at any layer of the stack.

Provider management in DAVE is restricted to the Admin role. Of the six default tenant roles (Admin, Create, Curate, Use, Reporting, and Financial), only Admin users can view the provider list, create provider records, edit credentials, delete providers, or trigger model fetches. All other roles are blocked from the Providers page entirely.

This access restriction is enforced at both the API and frontend levels. A non-Admin user who navigates directly to the Providers URL or constructs an API request to the providers endpoint receives an authorisation error, not a filtered view. The restriction is not a UI affordance that can be bypassed: it is a permission check applied before any provider data is returned.

Access to the Providers page is itself an auditable event. When SOC 2 or GDPR compliance mode is active in the tenant's audit log settings, read access to sensitive endpoints, including the providers endpoint, is captured in the audit trail with a timestamp, the actor's email and user ID, the source IP address, and a compliance tag. This means you can produce an evidence record of who accessed provider configuration and when, which is relevant for both SOC 2 CC6 (Logical and Physical Access) controls and GDPR Article 30 (Records of Processing Activities).

Key rotation is operationally straightforward because of the centralised provider model. To rotate an AI provider key, an Admin navigates to Admin, then API Management, then Providers, clicks the pencil icon on the relevant provider card, enters the new API key in the masked field, and clicks Update Provider. Every agent that references that provider immediately uses the new key on its next invocation. There is no need to update individual agents, workflow graphs, or environment variables. The rotation is atomic from the perspective of the agents: they either use the old key (before the update) or the new key (after the update), with no partial state.

Use this checklist when setting up a new tenant, onboarding a new AI provider, or conducting a periodic security review of your DAVE configuration.

1. Confirm that provider access is restricted to the right Admin users. Navigate to Admin, then API Management, then Providers and verify that only the users who should have credential access hold the Admin role. Navigate to Admin, then Settings, then Users and Roles to review role assignments. The Admin role grants full access to provider credentials: treat it with the same care as a root credential.

2. Use descriptive provider names that include environment context. Name providers by purpose and environment, for example "OpenAI Production" or "Anthropic Staging", so that any admin reviewing the provider list can immediately identify which credential is in use where. For Azure OpenAI, include the deployment name in the provider name, since Azure endpoints are deployment-specific.

3. Test connectivity after every key rotation. After updating an API key, click Fetch Models on the provider card to verify that the new key authenticates successfully against the live AI service. A successful fetch confirms the key is valid and the provider is reachable. Do not rely on the next workflow execution to discover a bad key: a failed agent call during a live workflow instance is a worse discovery mechanism than a deliberate connectivity test.

4. Enable SOC 2 or GDPR compliance mode if your organisation requires audit evidence of provider access. Navigate to Admin, then Settings, then General, then System Parameters, then the Audit Log section and enable the relevant compliance standard. With either standard active, read access to the providers endpoint is captured in the audit log with full actor and timestamp context. This gives you an evidence record of who accessed provider configuration during any given period.

5. Remove providers that are no longer in use. An inactive provider with a valid API key is an unnecessary attack surface. Before deleting a provider, verify that no active agents reference it: an agent that loses its provider will fail on its next invocation. Update any dependent agents to point to an alternative provider first, then delete the unused record. A smaller set of active providers is easier to audit and easier to rotate.