Security & key custody

Last revised July 29, 2026

Cortya ("Cortya," "we," "us," or "our") runs your agent teams on the API credentials you connect (BYOK) — your model key, and keys for the tools each agent watches. Those credentials are the one thing we protect above all else, so Cortya is built so that a breach of our database — or our logs — never exposes them. Just as important: Cortya does not access your PHI or other sensitive data or systems — your agents act on your own keys, and for regulated workloads they run inside your own environment so that data never reaches us.

The plaintext of your connected credentials exists in exactly two places: Azure Key Vault, and transient server memory for the moment your agents use them. It is never in our database, never in a log line, never in an HTTP response, and never in an audit record.

Key custody model

Encrypted at rest in Azure Key Vault. Each credential is stored as a secret in Azure Key Vault, which envelope-encrypts secrets at rest under HSM-protected keys. We operate the vault; the plaintext is written to it and read from it only by our server.
Decrypted server-side only, transiently. When your agent needs to act, the server fetches the credential from Key Vault into memory, uses it for that operation, and discards it. It never leaves the server and is never returned to your browser.
Never logged. Our logging redacts secrets; any key-shaped material (e.g. sk-ant-) is stripped before a log line is written. Credentials never appear in error messages, traces, or audit detail.
The database holds only a pointer. Our application database stores the Key Vault secret's name, the last four characters (for display), and status metadata — never the credential. A dump of our database yields no usable secret.
Validated before storage. A newly connected or rotated credential is checked before anything is stored, so a bad key can never overwrite a working one.
Every access is audited. Each time the plaintext is read from the vault for an operation, we record an audit entry attributable to your organization.

Where your agents run

Your agents execute on your own keys. For regulated or PHI-adjacent workloads, they run inside your own environment (on-prem or your cloud), so your sensitive data and Cortya stay on opposite sides of your compliance boundary — only non-sensitive operational metadata (what an agent triaged, routed, or notified) is ever sent to Cortya to power your dashboards, and only when you enable it.

Tenant isolation

Each organization's credentials are stored under their own vault secrets, and every data query is scoped to your organization. One customer's credentials or data are never used to serve another. The application connects to the database as a least-privilege role — it cannot alter schema or reach other tenants' rows outside its scoped queries.

Authentication

Sign-in is passwordless: you receive a one-time code and link by email that expire quickly. The at-rest hashes of those codes are peppered, and session and CSRF state ride signed cookies. There are no passwords for an attacker to steal or reuse.

Data in transit and at rest

All traffic is served over HTTPS. Secrets are kept out of source control and configuration; the application reads them through a single validated accessor fed from Key Vault at deploy, and refuses to start if required secrets are missing or malformed.

How to remove your credentials

You are always in control:

From Cortya: remove or rotate a connected credential from your account. This deletes the stored key material and stops all further access immediately.
From your provider: rotate or delete the key in your Anthropic (or connected tool) account. Cortya's copy stops working at once; reconnect with a new key when you're ready.

Reporting a concern

Found a security issue or have a question about this model? Email hello@cortya.com and we'll respond promptly.