Capabilities & operations
Security & privacy.
For: reviewers, security readers, and operators
Cardinal handles a customer's working data, so its security posture is not an afterthought — it is built into the shape of the system. Secrets never live in artifacts, identity is keyless, sensitive content is gated, and nothing reaches a third party without a human pressing the button. This page explains how, and what each guarantee rests on.
What we're protecting, and from what
The assets are a customer's working data — decisions, risks, documents, conversations — and the integrity of the record of what was done. The surfaces that could threaten them are the operator's machine, the cloud resources, the tool servers the agents use, and the outbound paths to third parties. The design narrows each of those surfaces deliberately.
The assets
- Customer working data in the database
- The tamper-evident record of decisions and actions
- Credentials and signing keys
The surfaces
- The desktop host and its local cache
- The cloud resources and their identities
- The tool servers the agents call
- Every outbound channel to a third party
Secrets & identity
The single most important rule: secrets never live in artifacts. No connection string, key, or token appears in a skill, a role brief, a workflow, an engagement pack, or anything that gets synced or committed. Credentials live in a managed secret store and an encrypted local cache. Access to the database is keyless — a directory-bound identity exchanges a short-lived token and adopts a least-privilege role per session. There is no database password to leak, because there isn't one.
Where secrets live
- A managed secret store (Key Vault), accessed by identity
- An encrypted local cache on the operator's machine
- Never in any file that is synced, shared, or committed
How identity works
- A user-assigned managed identity for the app and agents
- A short-lived token, refreshed — never a stored password
- A least-privilege database role adopted per session
- Web sign-in restricted to an explicit allow-list
Sensitive data
Documents carry sensitivity labels, and reads are gated on them: a reader sees a document's contents only if their clearance and the document's label allow it. The agents that watch the outside world — the scouts — are read-only and route anything regulated or confidential for review rather than ingesting it. A scout enqueues a one-line summary, never a body, an attachment, or a diff.
Outbound: the human-in-the-loop guarantee
This is the guarantee that matters most to a customer: nothing reaches a third party without a human deciding it should. Agents draft outbound, but they stage it — they never send. A person reviews and presses Publish, and only then does anything dispatch. There is no code path by which an agent sends a customer-bound message on its own.
How outbound is gated
- Agents draft and stage — never auto-send
- A human reviews the exact content and recipients
- Publishing is an explicit, human-pressed action
- A rejected publish is recorded, not silently dropped
Honesty as a rule
The system never fabricates a human action. If a step needs a person, it is staged for a person — never auto-completed by an agent pretending to be one. That honesty posture is firm, and it is what makes the human-in-the-loop guarantee real rather than nominal.
The audit guarantee
Every write — agent or human — appends a row to a hash-chained ledger, each row linked to the one before it. You cannot quietly alter history without breaking the chain, and the Steward verifies the chain continuously and raises an alarm if it ever fails. For a reviewer, this is the strongest assurance the system offers: not "trust us," but "follow the chain."
See the guarantees in the end-to-end flow → · The infrastructure they rest on →