Secrets Management
Secrets Management covers the two supported operating modes for credentials:
local development with secrets.json and production deployment with Azure Key
Vault backed configuration. It also outlines rotation discipline, application
scoping, and source-control hygiene.
Use this guide whenever you are provisioning a new environment, rotating keys, or reviewing whether credential handling meets production security standards.
Secrets Management
Keeping API keys and credentials secure requires different approaches for local development and production deployments. VeriProof uses a tiered secrets model: a local secrets.json file for development and Azure Key Vault–backed configuration for production. This guide explains both tiers and the practices that keep your VeriProof API keys out of source code.
Never commit API keys or secrets to source control. If a VeriProof API key is accidentally committed, rotate it immediately from the application’s API Keys settings.
Local Development
During local development, VeriProof configuration is stored in config/secrets.json in your project root. This file is excluded from source control by .gitignore.
Initializing local secrets
.\veriproof.ps1 secrets initThis creates config/secrets.json with placeholders for all required values.
Required values
| Key | Description |
|---|---|
VeriproofApiKey | Your application’s VeriProof API key (copied from the portal) |
VeriproofApplicationId | The application ID assigned when you registered the application |
VeriproofIngestEndpoint | The ingest API endpoint (defaults to https://ingest.veriproof.app) |
Validating local secrets
.\veriproof.ps1 secrets validateThis checks that all required values are present and that the API key can successfully authenticate to the ingest API.
Production: Azure Key Vault
In production deployments, secrets are stored in Azure Key Vault and referenced from appsettings.Production.json using Azure’s @Microsoft.KeyVault(...) reference syntax:
{
"VeriproofApiKey": "@Microsoft.KeyVault(SecretUri=https://your-vault.vault.azure.net/secrets/VeriproofApiKey/)",
"VeriproofApplicationId": "@Microsoft.KeyVault(SecretUri=...)"
}The Azure Functions runtime resolves these references at startup. Your deployment identity must have Key Vault Secrets User role on the vault.
VeriProof does not store or have access to your API keys in Key Vault. The Key Vault references are resolved by the Azure infrastructure at runtime and passed to the VeriProof SDK as environment variables.
API Key Rotation
Rotate API keys when:
- A key may have been exposed (leaked to logs, accidentally committed, shared via insecure channel)
- An employee with access to the key leaves the organization
- Your security policy requires periodic rotation (recommended: 90-day cycle for production keys)
Rotation procedure
Create the replacement key
In the portal, navigate to Applications → [your application] → Config → API Keys and click Add Key. Give it a descriptive label (e.g., “Production key — rotated 2026-03”).
Copy the new key value.
Deploy the new key
Update the secret in Azure Key Vault (or your local secrets.json for development) with the new key value. Deploy your application so the new key is active.
Verify the new key is working
Check Applications → [your application] → SDK Health — within a few minutes you should see heartbeats arriving with the new key.
Invalidate the old key
Return to Applications → [your application] → Config → API Keys and click Delete on the old key. The old key is invalidated immediately.
There is a brief window between deploying the new key and deleting the old one where both keys are valid. This is intentional — it minimizes the risk of a zero-session gap during rotation. Minimize this window to reduce exposure.
Key Scoping
Each API key is scoped to a single application. A key issued for the “Loan Assistant” application cannot ingest sessions for the “Claims Processor” application. If a key is compromised, only the sessions for that application are exposed to unauthorized ingest — not your entire tenant’s data.
For additional isolation, deploy separate applications per environment (Production, Staging, Development), each with its own API key.