Trust
What we do with your data, who else touches it, what our AI is and isn’t allowed to do, and how to get all of it deleted. If your security team has a questionnaire, most of it is answered below — send them here first.
§1
The short version
- Your data is never used to train AI models. Not ours, not our providers’.
- We use 5 subprocessors. They’re named below, with what each one can see.
- Connected-platform access tokens are encrypted at rest with AES-256-GCM. Raw tokens are never logged, never echoed, and never shared with a subprocessor.
- Deletion propagates within 30 days of a disconnection or a deletion request.
- No AI agent in our system can write to an external platform. Every change is proposed to a person and confirmed by a person.
- One client’s data cannot be queried alongside another’s without a written reason, which is recorded in our audit log before the query runs.
§2
Subprocessors
Last reviewed:
| Subprocessor | Purpose | Data it may process | Region |
|---|---|---|---|
| DigitalOcean (via Cloudways) | Application + database hosting (compute, managed MySQL) | Encrypted tokens at rest; cached aggregate metrics; account identifiers | US |
| Resend | Transactional email delivery (connect links, notifications) | Recipient email address + message content (NO connected-platform data, NO Gmail data) | US |
| Sentry | Error monitoring / diagnostics | Redacted diagnostics + non-reversible identifiers only — NEVER a token, app secret, signed_request payload, or raw app-scoped user id | US |
| Anthropic (via the DevJock prompt gateway) | LLM inference for analysis/recommendations | Masked provider bundles (aggregate metrics, no tokens). Connected-platform + Gmail data is never used to train models | US |
| OpenAI (via the DevJock prompt gateway) | LLM inference for select governed agents | As above — masked bundles only; never used for model training | US |
Each subprocessor is bound by confidentiality and security obligations and receives the minimum data needed to do its job. Connected-platform and Gmail data are never sold or transferred for anyone’s independent use.
When this list changes materially, it changes here and, where it affects the public disclosure, in our privacy policy. Our retention and deletion guarantees don’t depend on who’s on this list.
§3
What our AI is allowed to do
It cannot write to your systems. 14 tools are available to our agents. Every tool that would change something on a property of yours is a proposal — it returns a link for a person to confirm. The direct write path isn’t restricted; it isn’t implemented. (One tool writes to our database, recording a content idea as an advisory draft for review. It publishes nothing and touches nothing of yours.)
It cannot spend without a ceiling. Every agent carries a hard per-call dollar limit and a timeout, set in code. The cost is checked when the call returns, and an overage stops everything downstream. It does not downgrade the model and continue.
It cannot act on your behalf outside a classified workflow. Every scheduled process is registered with a blast-radius class, and any process that can reach the outside world requires typed confirmation to run manually.
It cannot be switched on by accident. Every agent and specialist fleet is off until its identifier is provisioned, and every scheduled process that can reach a customer is off until someone explicitly enables it. Deploying our code does not activate a capability. One process is deliberately exempt and cannot be switched off: the job that redacts personal data after 30 days.
It cannot invent a finding. Where our agents produce analysis, code independently verifies that every finding traces to a real source record and discards any that doesn’t.
§4
Separation between customers
113 tables carry an explicit tenant scope. Automated rules fail our build if any query against them is missing the correct filter, or attempts to reach them through raw SQL. A dedicated test suite runs 20 cross-tenant probes and every one must return zero rows before anything ships.
Querying across customers requires an explicit bypass that will not run without a written reason, and an audit record carrying that reason is written before the query executes — so a bypass cannot happen without a trace, even if the query itself fails.
The honest limit: this is enforced at build time and verified by tests, not by runtime row-level security. Automatic runtime filtering is planned, not shipped. We’d rather you read that here than discover it in a questionnaire.
§5
Retention and deletion
Audit records: personally identifiable fields are redacted automatically after 30 days by a nightly job driven by a rule registry. Where no rule exists for an action type, the job warns rather than guessing.
Erasure requests: run as a defined job with a cascade across related records and a retry queue, not as a manual database session. Agent activity attributed to the subject is included.
Disconnection: when you disconnect a platform or revoke access, the stored token and cached platform data are purged within 30 days.
Diagnostics: what our error monitoring retains contains no tokens, secrets or personal data.
/data-deletion.html — the request mechanism/privacy.html — the full policy/privacy-choices
§6
Access and identity
Human accounts support time-based one-time passwords, hardware security keys, recovery codes and trusted-device registration. Sessions can be invalidated centrally.
A client’s AI agent authenticates with a key scoped to that client and cannot reach beyond it. Our internal agents authenticate individually against a server-side allow-list — an agent’s permissions are enforced somewhere the agent can’t reach, not stated in its instructions.
Secrets are rotated on a scheduled basis against 15 documented procedures, with commit scanning and dependency scanning in our build pipeline.
§7
Regulated industries
We maintain a registry of regulated industry categories — healthcare, financial services, legal, insurance, supplements, real estate and others — each carrying a severity classification and a set of required disclosures. Where an industry’s rules are blocking rather than advisory, output can be gated on them.
If you operate somewhere with content rules, that constraint can live in the system rather than in a reviewer’s memory.
§8
What we don’t have yet
We are not SOC 2 or ISO 42001 certified. We are a small firm and both are on a roadmap rather than in a filing cabinet. What we have instead is in the open: the controls above, the build-time enforcement, the test suite, and 68 written operational runbooks. If a certificate is a hard procurement requirement, we’ll tell you at the first call rather than the fifth.
We have not had an external penetration test. It’s a planned gate, not a completed one.
Runtime tenant filtering is not implemented — see “Separation between customers” above. Enforcement is at build time and in tests.
Our public integration surface is not open yet. The authentication layer is built and tested; the client-facing tool interface is not finished. When it is, it’ll be documented here.
Questions this page didn’t answer?
Reply to whoever you’re talking to at Bobos, or email info@bobos.ai. If your security team needs a questionnaire completed, send it over; we’d rather fill it in than have the deal wait.