Security
It only ever reads, except where it acts in your name.
Two different products with two different answers, and the difference is the point. This page is written for the person who has to approve it rather than the person who wants it, and every answer here is a structural fact rather than reassurance.
- Read-only by construction
- Scoped per person
- Revocable in one click
POST/v1/audiences (does not exist)
scoperead only, on every connector
- status404
- write_paths0
Not a permission set to deny. There is no write endpoint on a read connector, so there is nothing to misconfigure.
The split that matters
One of these reads. The others act.
Grouping them together would blur exactly the question you are here to answer, so they are kept apart everywhere on this site.
Data Agent
Every connector is read-only by construction. It cannot change a campaign, a record or a setting, because there is no write path to misuse.
- Queries only
- Scoped per person
- Every query audited
Responders
These speak in your name, so they carry a different answer. Grounded in your own approved knowledge base, with review before send, and you define what they may never say.
- Your knowledge base
- Review before send
- You set the never-say list
Custom build
Scoped to one workflow with one defined output and a handover date. Human in the loop first; the loop is removed only once accuracy is proven.
- One scoped workflow
- Human in the loop
- Documented at handover
The boundary, drawn
A report goes where it was registered to go, and nowhere else.
This is the property that makes the whole loop safe to automate. An instruction hidden inside a row of data telling the system to send your numbers somewhere has nowhere to arrive.
No path exists
Access
Who can reach what, and how fast you can take it away.
- Every connector is read-only. There is no write path to a source, so there is none to misconfigure
- Access is granted per person, per source and per destination, never per company
- Five roles, and the read-only ones cannot send under any configuration, because it is enforced by the role rather than by a setting
- Reports go only to destinations registered in advance. There is no free-text send
- Revocation takes effect on the next request, not on the next billing cycle
- Every query and every send is written to an append-only audit trail the account holder can read
- Each client runs in its own isolated environment with its own credentials, configuration and audit trail
- Inference happens in your own AI account, under the agreement you already signed
- Your client creates every credential, at least-privilege scope, in their own account
- On exit you keep the accounts, the data, the outputs and the documentation
Data
The questions a reviewer actually asks.
Raised here before you raise them, because having the answer written down is worth more than having it ready.
Why would we give an outside party access to our data?
You do not hand anything over. You create every credential yourself, at least-privilege scope, inside your own account, and you can revoke it in one click without asking us. We never hold an account. That answer is structural rather than contractual.
What if it sends our numbers somewhere it should not?
It cannot. Dispatch reaches only destinations registered in advance, so an instruction hidden inside a data row telling the system to send a report elsewhere has nowhere to go. It is refused at the boundary rather than by the model deciding well that day.
What if the AI says something wrong to our customers?
Only the responders speak to anyone, and every reply is grounded in your own approved knowledge base rather than model memory. Review before send is available throughout onboarding, and you define what it may never say. Data Agent speaks only to your team, in answer to a question.
Does our data train anyone's model?
No. Inference runs inside your own Claude or ChatGPT account, under the agreement you already signed and the retention settings you already chose. Your data does not pass through a vendor's model on the way.
What stops one client's data reaching another?
Separate environments, separate credentials, separate configuration and separate audit trails. There is no cross-client path, so there is nothing to misconfigure and nothing anyone has to remember.
What happens if you disappear?
Client-owned credentials from day one, a documented runbook, and on exit you keep the accounts, the data, the outputs and the documentation. Lock-in through value, never through holding anything of yours.
Will this replace our team?
It removes the exports, the forwarding, the reply backlog and the report building, which is the work nobody was hired to love. Judgement stays with your team, and every output that faces a customer keeps a human checkpoint until you decide otherwise.
Still have a question
Send this page to whoever asks.
That is what it is for. If your reviewer needs something that is not here, ask and we will answer it plainly rather than in a brochure.