What leaves. What never does.
This page is specific on purpose. Where your data lives, which credentials belong to you and which belong to us, what does and does not reach a language model, and the certifications we do not have.
- Sign-in
- Passkeys — no passwords stored
- Isolation
- Per workspace, per request
- Model training
- Never on your data
Never sent to a model
- API keys, OAuth tokens and mailbox passwords — no credential is ever placed in a prompt
- Your customer list, your deal records or your CRM contents
- Mailbox contents beyond the specific thread a draft is being written against
- Anything at all as training data — model calls are inference only
The qualification judge cannot browse and cannot reach the database. It sees the evidence rows it is handed, and nothing else.
Boundariesthree zones, two crossings
Everything that crosses a line here is a short, fixed list.
The useful question is not whether we take security seriously — everyone says yes. It is where the lines are, what is allowed over each one, and what is refused at the line rather than by a policy somebody has to remember.
Z1Public sources
- A company's own site, listings and filings
- Job feeds, ad libraries, web archives, domain records
- Material that company published about itself
harvest
- the claim
- the source URL
- the observed timestamp
- anything behind a login
- bought contact databases
Z2Your workspace
- Evidence rows — claim, source URL, observed at
- Your profile, campaigns, leads, deals and replies
- Your secrets, server-side, referenced by id
- Resolved once per request and carried in context
prompt
- numbered evidence rows
- the business profile
- the draft in hand
- credentials
- your customer list
- another workspace
Z3The model call
- Inference only — never training
- Cannot browse. Cannot reach the database
- Assembled from a fixed set of fields
Every line here is a mechanism described in prose on this page. No certification, auditor or badge is claimed by this diagram — see “what we do not claim” below for the list we do not hold.
Credential ownership
One rule decides who can see a key.
If Arvyn pays for it, only Arvyn can see it — otherwise one customer could read a key that every other customer runs on. If you own the underlying account, it is yours, and hiding it from you would be wrong.
Arvyn holds
Shared infrastructure. Invisible in every customer workspace.
- model_provider_key
- The inference key behind qualification, drafting and coaching. One key serves every workspace, so no workspace may read it.
- verification_keys
- Email-verification providers. Billed to us, rate-limited across all customers.
- enrichment_keys
- Contact matching, place data and hiring feeds used on the paid tiers.
- oauth_app_credentials
- The registered applications for mail and CRM connections. The application is ours; the connection it creates is yours.
- platform_auth_secrets
- Session signing, enrolment tokens, relying-party configuration.
- global_send_ceiling
- The platform-wide daily limit. One customer must never be able to throttle another.
You hold
Your accounts, your content, your obligations. Visible and editable by you.
- mailbox_connections
- Gmail and Microsoft grants, and SMTP credentials. Your mailbox, your consent, revocable by you at the provider.
- crm_connections
- HubSpot and Salesforce grants. Your data, moving under your authorisation.
- api_keys_and_webhooks
- The keys you generate for your own programmatic access, and where we post events.
- sending_identity
- From-name, signature, reply-to. Your brand on every message.
- per_inbox_caps_and_windows
- Daily caps, warm-up ramp and the hours a campaign is allowed to send in. Your infrastructure, your policy.
- suppression_list
- Your do-not-contact obligations. Applied before every send and never shared across workspaces.
The split is maintained as a written contract that verification runs check the running code against. A setting that is not classified does not ship.
Seven invariants the code has to satisfy.
These are written as invariants rather than intentions, so they can be checked instead of believed. Each one names the mechanism that holds it up.
If you find a case where one of them does not hold, that is a security report and we want it.
- INV-1
No route you can reach returns a platform credential.
Not the value, not a masked version of it, not a hint that reveals its length or its last four characters. Shared infrastructure keys — the model provider, the verification providers, the maps and enrichment services — are never serialised into any response a customer session can receive.
Enforced byroute-level role check + response allow-list
- INV-2
Only a platform operator can write the server environment.
There is exactly one code path that writes the environment file, and it is reachable by the operator role and nothing else. A customer session cannot reach it, and neither can a customer's API key.
Enforced bysingle writer module, operator role only
- INV-3
Operator surfaces return 404, not 403.
A 403 confirms that a door exists. Every operator route and operator API answers a non-operator request as though the page were not there, because the existence of the surface is itself information.
Enforced bymiddleware — not-found response for non-operators
- INV-4
Every read and write is scoped by the session's workspace.
Not by a parameter in the request, and not by a global that a concurrent request could change underneath it. The workspace is resolved once, at the edge of the request, and carried through the call stack in context so that a query cannot accidentally run unscoped.
Enforced byrequest-scoped context, resolved before any query
- INV-5
An operator working inside your workspace sees only your workspace.
Support sometimes has to look at a real account. When that happens the operator's session is bound to that one workspace and reads exactly what you would read — nothing from any other customer leaks into the same view.
Enforced byimpersonation binds the same workspace scope
- INV-6
Your own secrets are never sent to a browser.
Mailbox passwords, OAuth refresh tokens and API keys you generate are write-only from the interface's point of view. They are stored server-side, referenced by id, and the settings screens render metadata about them rather than the values.
Enforced byserver-side storage, no secret in any client payload
- INV-7
The public API resolves your workspace from the key, not the session.
A programmatic request is scoped by the owner of the API key that made it. There is no path where a session cookie, a header, or a body parameter can widen what a key is allowed to see.
Enforced bykey-owner lookup at the API boundary
Access
There is no password to steal.
Sign-in is a passkey bound to your device. Nothing that could be phished, reused from another breach, or read out of our database exists in the first place.
Passkeys only
Registration and sign-in use the WebAuthn standard. The private key never leaves your device and we store only the public half, which is useless to an attacker who takes it.
Recovery is deliberate
There is no reset link in an email. Re-enrolment requires a token issued by an operator, because an email inbox is exactly the thing an attacker already has.
Sessions are scoped
A session carries one workspace and one role. Switching workspace re-resolves the scope; it does not widen the one you already had.
A language model only ever sees the evidence.
The qualification judge cannot browse the web and has no connection to the database. It is handed a numbered set of evidence rows and the business profile they are being weighed against, and it has to name the rows it used for every score it returns.
That design exists to stop the model inventing reasons, but it has a second effect worth stating plainly: there is no path by which a credential, a customer list or an unrelated mailbox ends up inside a prompt, because the prompt is assembled from a fixed set of fields.
Model calls are inference only. Your data is not used to train a model, ours or anyone else’s.
Sent
- The business profile compiled from your website and onboarding interview
- Evidence rows — a claim, the source URL it came from, and when it was observed
- The draft being written, and the case file it is being written from
- Meeting audio you explicitly start a session on, for live coaching
Never sent
- API keys, OAuth tokens and mailbox passwords — no credential is ever placed in a prompt
- Your customer list, your deal records or your CRM contents
- Mailbox contents beyond the specific thread a draft is being written against
- Anything at all as training data — model calls are inference only
Public sources in. Nothing resold out.
The evidence behind a qualification comes from material a company has published about itself — its own site and listings, public advertising libraries, job feeds, web archives, domain records, public review counts. We store each finding with the URL it came from and the moment it was observed, because a claim without those two things is not evidence.
Your side of it — your business profile, your campaigns, your replies and your CRM records — stays inside your workspace. It is not pooled into a shared dataset, not sold, and not used to improve anyone else’s results.
- Evidence row
- Claim, source URL, observed timestamp, shelf life, confidence. Rows expire, and scores built on them decay as they do.
- Your content
- Business profile, ICPs, campaigns, sequences, leads, deals, tasks and replies — scoped to your workspace on every query.
- Secrets
- Mailbox passwords, OAuth tokens and API keys are stored server-side and never rendered back to a browser.
- Hosting
- A single dedicated server we control, reached over encrypted transport. Not a patchwork of third-party services holding pieces of your account.
- Subprocessors
- An inference provider, email-verification providers, enrichment providers, and the mail and CRM services you connect yourself. A current list is available on request.
- Deletion
- On request we delete the workspace and its rows. Say the word and it goes; we will confirm when it has.
- Suppression
- Your do-not-contact list is applied before every send and is never visible to another workspace.
We hold none of these, so we will not imply that we do.
Security pages tend to list badges. Ours lists the badges we have not earned, because a young company that quietly omits this section is inviting you to assume the opposite.
What is above this section is the whole answer today: how sign-in works, how workspaces are isolated, where credentials live, and what never reaches a model. When we hold one of the items on the right, it will move up this page with the date it was granted.
If your procurement process requires one of these, tell us which one and we will tell you honestly whether it is on the roadmap or not.
- SOC 2 Type I or Type IInot held
- ISO/IEC 27001not held
- HIPAA business associate agreementnot offered
- Third-party penetration test reportnot yet commissioned
- Cyber insurance certificatenot held
Reporting a vulnerability
Send it to security@arvyn.io with enough detail to reproduce it. We read every report, we will tell you what we did about it, and we will not threaten anyone who reports one in good faith. We do not run a paid bounty programme yet, and we will say so rather than let you assume there is one.
Questions this page did not answer?
Security and data-handling questions go straight to the people who wrote the code. Ask the specific one — a generic questionnaire will get a specific answer back anyway.