The security brief.
Updated · 2026-07-28
This is the long version of our security posture, published in full rather than sent on request. Each item is a control we either hold today or have explicitly marked as planned. Where the product and the promise differ, the difference is stated here.
1. Threat model
Invice acts in your name, so the design assumes the credential is the target. Three classes of secret are defended: your model API key (bring-your-own-model), the OAuth tokens for the mailboxes and calendars you connect, and the tokens agents use to talk to each other. The working assumption is that any one of these, if exposed, lets someone act as you — so each is encrypted at rest, scoped to a single workspace, and revocable. We do not defend against a model provider you bring or an app you authorize; those run under your own credentials and your own trust boundary, and we say so rather than pretend otherwise.
2. Prompt injection and action authorization
No model-driven system can honestly promise that prompt injection is impossible. Invice instead assumes every model-readable input may be adversarial and limits what manipulated content can authorize, disclose, or execute.
Untrusted inputs: Email, documents, web pages, connector responses, model output, and generated summaries remain evidence. Text inside them cannot become system policy, an approval, or permission.
Code-owned policy: Every model-selectable action has a closed manifest defining its effect, boundary, risk, data classes, approval floor, and egress requirement. The model cannot rewrite that manifest.
Exact review: When policy requires review, approval binds the workspace, mission, action, destination, canonical payload hash, reviewer, expiry, and one-time nonce. A changed recipient, body, file, or parameter requires a new review.
Scoped autonomy: An action can run without a one-off click only inside explicit mission and workspace policy. Dynamic connector tools and code-classified destructive actions retain a non-optional approval floor; document sharing opens a dedicated review.
Single outbound gate: Automated external mutations are checked again immediately before the provider call. Missing execution context, scope drift, or destination drift fails closed; approval-gated actions also reject expired, changed, or already-consumed grants.
Connector isolation: Dynamic MCP and guided REST tools require exact approval before credentials are decrypted. User-controlled URLs pass SSRF and redirect validation, and connector metadata cannot label itself trusted.
Remaining human boundary: A reviewer can still intentionally approve a harmful payload, a broadly configured autonomous mission can carry more risk than a narrow one, and a connected provider can mishandle data it was authorized to receive. The controls reduce authority confusion; they cannot replace careful review, narrow permissions, or provider due diligence.
3. Encryption at rest
Stored secrets are encrypted with AES-256-GCM. The key is derived from an application secret held only in the server environment, never in the database. Each ciphertext carries its own 96-bit IV and 128-bit authentication tag, so tampering is detected on decrypt rather than passed through silently. Your model API key is encrypted before it reaches the database, decrypted into isolated session memory only for the duration of an active call, and discarded immediately after. It is never written to logs and never placed into any model prompt or message.
4. Encryption in transit
Traffic to and from Invice is encrypted with TLS, and HSTS prevents supported browsers from falling back to plaintext connections.
5. Document vault
Uploaded documents live in a private, workspace-scoped store protected by row-level security: a file is reachable only by members of the workspace that owns it, enforced at the database layer on every request, and encrypted at rest by the storage layer. Per-file application-layer key wrapping — a distinct key per document, held separately from the file itself — is on the roadmap and not yet live. We list it as planned rather than claim it as shipped; this brief is updated when that changes.
6. Key handling and rotation
No secret is hardcoded; all come from the server environment. The key-derivation function is versioned, which lets us re-derive and re-encrypt stored secrets without downtime when the application secret is rotated. You can revoke your model API key at any time, and revocation takes effect immediately because the key is read fresh for each session rather than cached.
7. Authentication and access
Authentication runs on Supabase Auth over a PKCE flow. On the server we verify identity with getUser(), which validates the token against the auth server on every request, rather than trusting an unverified session cookie. Time-based one-time-password (TOTP) multi-factor authentication is available and checked through assurance-level gating in the app shell. SSO and SAML are offered on Enterprise.
8. Agent-to-agent authentication
Connections between agents use bearer tokens issued per workspace. The raw token is shown to the issuer exactly once; only a SHA-256 hash is stored, so the database never holds a usable token. Invitations, live API keys, and session tokens all follow the same shown-once, hash-at-rest pattern. Tokens are revoked when a connection ends — there is no long-lived inter-agent credential.
9. Inbound webhook secrets
Webhook and CRM secrets are generated server-side, shown to you once, and stored only as a SHA-256 hash. Inbound requests are verified with a constant-time comparison to avoid timing leaks, and the secrets are never logged.
10. Audit format
Every agent action writes one audit row through a single enforced code path. Actions are a closed vocabulary — each is a named action with a fixed payload shape — and no payload field may carry verbatim user text. PII is reduced at write time: email addresses are stored as their domain only, and free text is replaced with a length proxy. Errors are sorted into a fixed set of classes rather than logged verbatim. The record says what happened, not what was in it.
11. Data residency
The primary database and uploaded files are stored in Canada (Montréal), and server functions are pinned to the Montréal (yul1) region. Your own model provider processes prompts under your API key and may run elsewhere; that is outside our control and disclosed as such. Two kinds of processing run under our own key rather than yours, and both currently happen outside Canada. Vault embeddings go to OpenAI (US), and the model calls Invice makes on its own behalf go to Anthropic (US): reading and classifying uploaded documents, parsing replies, summarising conversations, and similar internal steps. We are moving embeddings to a Canadian region. Both flows are listed as sub-processors below and are under privacy review. Enterprise can request region-locked deployments.
12. Sub-processors
The services that may process data on our behalf. Optional ones run only when you enable the feature that uses them. The full register, with what reaches each party, in what form, and its assessment status, lives at /security/subprocessors.
Supabase: Postgres database, authentication, and encrypted file storage.
Vercel: Application hosting and serverless compute, pinned to the Montréal region.
Stripe: Subscription billing for your Invice plan; card details are entered with and held by Stripe, never by Invice.
Resend: Transactional and notification email: owner notifications (which may contain end-client summaries), teammate invites, playbook comment notifications, and gateway one-time passcodes.
Google / Microsoft: OAuth for the mailboxes and calendars you connect; tokens are limited-scope and revocable.
Your model provider: Anthropic, OpenAI, Google, or another, running under your own API key. Invice routes selected mission context to that provider; its handling is governed by your contract and settings.
Anthropic (under our key, not yours): Separate from the provider you connect. Invice makes some model calls on its own behalf, under its own Anthropic key, and these process in the United States: reading and classifying uploaded documents, parsing inbound replies, summarising conversations, drafting entity notes, and similar internal steps. The content of the documents, emails, and conversations involved can reach this flow. The mission-learning step replaces the contact names, addresses and phone numbers it matches from your records with neutral placeholders before content reaches this flow, and prefers your own connected model where one exists; details it does not match, including any typed inside a message, can still be included, a note dated August 21, 2026 that will be removed when learning inference runs in a Canadian region. It is disclosed here and its privacy assessment is open.
Embeddings: Vault indexing and retrieval run under our own key: OpenAI (US) today. We are moving embeddings to a Canadian region; provider selection is pending evaluation.
Browserbase (optional): Headless web browsing, only when a mission needs it.
SerpAPI / Google Custom Search (optional): Web search, only when enabled.
Slack (optional): Posts mission messages to a channel you connect, only when a mission uses it.
Inngest (optional): Background job scheduling, when configured.
13. Retention and deletion
Active account data is retained for the life of your subscription. On cancellation there is a 30-day export window, after which data is permanently deleted. You can request deletion at any time; account deletion cascades through your missions, vault files, and connections, and the deletion itself is recorded in the audit log with PII redacted.
14. Compliance and your rights
Invice is not SOC 2 certified today. We are building toward SOC 2 Type II, and we will state that plainly here rather than imply a certification we do not hold. Canadian users are covered under PIPEDA and EU/UK users under GDPR; you have the right to access, correct, export, and delete your personal data. Security or privacy questions: hello@invice.ai.
15. Outbound email, consent, and CASL
Every client email goes out through your own connected Gmail or Outlook account, and by default nothing sends until you approve the exact draft. You are the sender of every message, so responsibility for having consent or another lawful basis to contact each recipient, under CASL and any other law that applies to your practice, stays with you. Invice does not decide or verify who you may contact; it gives you the approval gate, the audit trail, and the controls. Newsletter campaigns carry an unsubscribe link on every send, and unsubscribes are honored on every future campaign.