For the person who has to approve this
The security review, without the meeting.
These are the questions we get asked in every review. They do not change between customers, so there is no good reason to make you book time to hear the answers. Most of them you can verify yourself in an afternoon, and where you cannot, we say so.
What leaves the browser
The shortest version: numbers, never media. Face and voice analysis happens on the device, and only the scores it produces are sent.
Do you receive video or audio?
No. No frames, no image files, no recordings, no face mesh. The analysis runs in the page and emits floating-point scores, frequency sub-scores, and hardware booleans. There is no endpoint that accepts media, so this is not a policy we could quietly relax.
Check it yourself: Put a proxy in front of the sideband connection and read the payloads. They are small JSON objects of numbers.
What is actually stored?
The scores, the verdict, the action being decided, and a signed record of the decision. Credentials are stored only as SHA-256 digests, so a dump of our database yields nothing you can authenticate with.
Is anything sent to a third party?
Only where you configure it — your own SIEM endpoint or Pub/Sub topic. Those payloads are built from an explicit field allowlist rather than by serialising internal records, and a test asserts the exact field set so a new signal cannot start leaving by accident.
What happens when Presence fails
Verification runs beside your transaction, never inside it. If we are slow or unreachable, your users should not be able to tell.
If your service is down, does our payment flow stop?
No. Telemetry travels on a separate channel from your transaction. Losing that channel degrades verification and nothing else — you keep operating without us.
Check it yourself: Block our hostname at your egress and run your flow. It should behave identically.
Can you add latency to our critical path?
The scoring channel is asynchronous, so delay there is invisible to the user. The decision call itself is one request you control and can time out on like any other dependency.
Check it yourself: Inject two seconds of delay on our endpoint and measure your own path.
Can a bad rule of yours block our customers?
Only if you have turned enforcement on, and only until you turn it off. A workspace starts in watch-only, where the true verdict is computed and sealed but your caller is always told to proceed. One switch returns you there, and it applies to the very next request rather than at the next deploy.
Evidence you can check without us
The point of the signed record is that it does not require trusting the party that produced it.
How do we know a decision record is genuine?
Every decision response carries a verification bundle: the sealed payload, its chain hashes, and an Ed25519 signature. Our signing keys are published at a well-known JWKS URL, and a ~100-line dependency-free verifier script — served from this site with its checksum — checks both offline, with nothing sent to us. OpenSSL alone verifies the signature too; the script exists because reproducing the canonical JSON bytes is the step shell tools get wrong.
Check it yourself: node verify-dossier.mjs <dossier>.bundle.json --jwks presence-dossier-jwks.json
Could you alter a record after the fact?
Not without detection on the record itself: the signature covers the payload and its chain hash, so any alteration invalidates it. Each record also names its predecessor's hash. One honest caveat — the chain's continuity across our own restarts is not yet independently anchored, so treat the per-record signature, which you can verify yourself, as the hard guarantee.
Are blocked attempts recorded too?
Yes, and so are the ones a rollout stage softened. During watch-only the record states what policy actually decided alongside what your caller was told, which is what makes that period a measurement rather than a gap in the audit trail.
Access and identity
Who can see evidence, who can change enforcement, and how those are kept apart.
Can we use our own identity provider?
Not yet. Console sign-in runs on Google Cloud Identity Platform with per-customer isolated tenants, and roles separate reading evidence from changing configuration. Bringing your own IdP via SAML/OIDC federation is on the roadmap, not shipped — see the limits below.
Who can turn enforcement off?
Only an administrator credential, which deliberately cannot approve a transaction or resolve a case. Disabling the control and then exploiting it takes two compromised credentials rather than one. Every change is itself signed evidence naming who made it.
Can one customer see another's data?
Reads take a tenant and filter by it at the repository, and a record belonging to another tenant returns the same answer as one that does not exist — existence is itself a disclosure.
What we do not claim yet
A security page with no limits is a security page nobody examined.
- Single sign-on against your own identity provider is not available yet. Console access uses isolated Google Cloud Identity Platform tenants; SAML/OIDC federation is planned.
- Some platforms do not offer every control. Zoom has no REST mute, and Slack exposes no way to mute or remove anyone from a Huddle — so we lock the approval instead and say so on the connector page rather than implying we can do more.
- Mobile device attestation is implemented for both platforms and has not yet been exercised against a real Apple attestation object or a Play-distributed build.
- We hold no SOC 2 Type II or ISO 27001 certificate today. This page, and the architecture behind it, is what we offer instead — and we would rather you found that out here than in week three.
Still want to talk to someone? That is fine too.
Nothing here is a substitute for your own testing. The fastest way to check any of it is to run a sandbox against your own traffic in watch-only mode, where we cannot affect a single customer.