The assistant has no privileges of its own.

Each person connects once, in a browser, using Salesforce’s OAuth 2.0 authorization-code flow. They authenticate on Salesforce’s own login page, at a salesforce.com address. Their username and password are typed into Salesforce, not into anything of ours, and never pass through our systems.

If you asked us to produce one of your people’s Salesforce passwords, we could not. We have never held it, in any form, at any point.

If your Salesforce login is itself behind single sign-on or multi-factor authentication, that applies here unchanged, because it is Salesforce doing the authenticating. Connecting the assistant does not create a second way into your org that bypasses your own login policy.

The authorization exchange is hardened against interception

• PKCE with SHA-256 protects the exchange, so an authorization code intercepted in transit cannot be redeemed by anyone but the browser that started the flow.
• A single-use random state value, bound to that person and verified when Salesforce returns, so a callback that did not originate from a request we issued is rejected.
• The Connected App’s client secret is exchanged server-to-server with Salesforce directly. It is never placed in a browser, a URL, a redirect or a page we serve.
• We request two scopes and no more — API access, and a refresh token. We do not request full access, web access, or any administrative scope. Anything outside those two is not available to the assistant even if it tried.

After that one-time consent, what we hold for each person is a Salesforce refresh token, and nothing else. No password. No security token. No Salesforce session. No copy in a browser or on a phone.

• One token per person, not one per company. Each is stored under its own separate key, encrypted at rest.
• There is no master key to your org, because no such thing exists in the design. The most any single token can reach is exactly what that one person can reach in Salesforce — their profile, their permissions, their sharing rules — and every use of it is stamped with their name in your own audit trail.
• The token grants API access only. It cannot be used to log in to the Salesforce user interface as that person.

You can revoke us three ways, and each is immediate

Any one of these is sufficient on its own.

1. Suspend a person’s access in our console. This deletes that person’s refresh token from our storage outright. It is a deletion, not a flag.
2. Clear your organization’s Salesforce binding, which detaches the whole company.
3. Revoke the connected application from inside your own Salesforce. This one requires nothing from us and we cannot delay or block it — Salesforce stops honouring the token, and every token we hold becomes inert.

Salesforce field values are never written to our systems. What we retain is a deliberately value-free record: what the assistant did, to which record id, which field names changed, counts and timestamps — never the values.

This is enforced at three layers, and tested rather than asserted.

1. At the write sites. Audit rows carry record ids and field names only, and the tests prove the values are absent from the stored row rather than assuming it.
2. In memory, not on disk. The working set for a live call is held in memory only and is wiped when the call ends, with a sweeper as a backstop.
3. At the vendor. The call transcript and recording are deleted from our voice provider at the end of every call.

A caller’s spoken PIN is removed from the transcript before it is sent for summarization, and the removal is verified against that person’s own stored PIN hash rather than pattern-matched, so it cannot mistake an invoice amount for a credential.

Log content is enforced in continuous integration

A check in our blocking test lane asserts that no diagnostic log line anywhere in the application can publish a caller value, a transcript, a PIN or a tool argument. A change that would introduce one fails the build and cannot be merged.

We treat a log-retention regression as build-breaking because a leak into a log aggregator — unlike a cosmetic defect — cannot be taken back out.

• The caller proves identity with a PIN, chosen by them, stored salted-hashed. Two independent brute-force lockouts are live: three wrong attempts per call, and five per phone number per 24 hours.
• Enrollment requires possession of the phone, by a code sent to a number an administrator pins in advance. An administrator can start a PIN reset but cannot complete one — the person’s own phone must, and they choose the new PIN. We verify this end to end, including against a spoofed caller ID, which is refused.
• A verified call expires. Authorization is bound to the call and to a bounded window, so a historical call identifier is not a standing credential.
• The administration console uses bcrypt-hashed passwords with signed sessions that expire in twelve hours, behind a login rate limiter scoped so that an attacker cannot lock a legitimate administrator out.
• Multi-factor authentication is available on the administration console — time-based one-time codes from any standard authenticator app, with single-use recovery codes, and an organization-wide requirement we can switch on for your organization at setup.

Isolation is proven by a dedicated suite of over a hundred assertions across two organizations — including one person enrolled in both with different PINs and different Salesforce tokens — covering verification, data access, cross-call memory, cross-organization administrative attacks and OAuth cross-binding. It runs on every change, in the test lane we treat as blocking.

Secrets are encrypted at rest, all vendor traffic is HTTPS, and the application and database are hosted in the United States.

Who our vendors are, what each receives and why, is a separate document we can share. Ask us for it, along with anything else your security review needs.

Ask us a security question → Try the demo