What we hold, where it sits, and what we have not done yet.
You are handing us your client list. This page is written to be forwarded to whoever asks you hard questions about that — including the section listing what we have not built.
Tenant isolation.
Agencies on this platform compete with each other. A leak between two of them is not an incident, it is a business-ending event — so isolation is treated as the control that matters most rather than one item on a list.
- Every request resolves a tenant context server-side before it touches data, and every data-access path is scoped by it.
- Every page inside the application resolves its own context. In this framework a layout and its page render concurrently, so a layout check protects the chrome and not the screen — a build-time test fails if a new page forgets.
- A request for another agency’s brand is refused as if the brand did not exist. An authorisation error would confirm that it does.
- Agency-supplied branding values are validated before they reach a page, because a stored colour that is substituted into a stylesheet is an injection surface, not a preference.
Access and authentication
- Accounts are provisioned by the agency. There is no public registration path.
- Sessions are validated against the database on every protected render, not merely inferred from a cookie.
- Roles: owner, admin, member — configuration changes that alter a denominator are held above account-manager level.
- Authentication failures are deliberately non-specific: “those credentials were not accepted”, never “no such user”.
- Rate limiting on authentication endpoints.
Sub-processors, in full.
Every third party that touches platform data, what it holds, and where. Published because a sub-processor list you have to request is a sub-processor list somebody is hoping you will not read.
| Sub-processor | What it processes | Region |
|---|---|---|
| Vercel | Application hosting; request handling | Global edge; compute in configured region |
| Neon | Primary database — agencies, users, brands, prompts, results | EU (Frankfurt) |
| Cloudflare R2 | Raw answer captures and report artifacts | Configured bucket region |
| Anthropic | Grounded answer acquisition and the analysis pass | US |
| SERP vendor | Google AI Overviews and AI Mode acquisition | US |
| Inngest | Worker orchestration — job metadata, not answer content | US |
| Axiom | Structured application logs, 30-day retention | US |
Three United States hops, named. Answer acquisition, worker orchestration and log storage sit in the US. That is a cross-border transfer under POPIA and under the UK/EU GDPR, and it is disclosed here rather than buried in a schedule. If your client requires EU-only processing, tell us at the demo — it changes what we can offer and we would rather say so early.
Never used for training
Prompts, brand configuration, captured answers and results are never used to train models — ours or anyone else’s. Vendor agreements are selected on this basis.
Encrypted in transit
TLS everywhere, with strict transport security and a content security policy on the application. Object storage is private; there are no publicly addressable capture URLs.
Tiered retention
Result rows are permanent — they are the trend line. Answer payloads are erased on a twelve-month rolling window or on request, leaving a tombstone so a link to an erased capture answers honestly.
Erasure on request
An agency can require erasure of a brand’s captures at any point, including on contract end. Stored objects are deleted before the rows that reference them, so nothing is orphaned.
Export on demand
Everything the interface shows is exportable — results, sources, captures — through the read API or as files. Leaving is a supported operation, not an escalation.
What we do not collect
No end-consumer data, no visitor tracking on your clients’ sites, no analytics pixels installed anywhere. We observe public AI engine output, not people.
The honest gaps.
A trust page listing only strengths is the document a security team learns to distrust fastest. These are the things a mature vendor would have and we do not, with what we do instead.
| Not yet | Status | What we do instead |
|---|---|---|
| SOC 2 or ISO 27001 | No certification. We are not going to imply one. | Structured pre-launch audits across security, reliability, observability and privacy, with findings tracked to closure. |
| Independent penetration test | Planned before general availability | Internal threat modelling and audit-driven remediation; the two launch-blocking findings were closed before deployment. |
| EU-only processing option | Not available — answer acquisition and log storage are US | Full disclosure of every transfer, so the decision is yours rather than a surprise. |
| Formal uptime SLA | Not offered pre-launch | Health endpoint, cycle-failure alerting, and a reconciler that closes stalled cycles rather than letting a dashboard look stable. |
| SSO / SAML | On the roadmap, demand-led | Role-based access with agency-provisioned accounts. |
Found a vulnerability?
Report it privately to security@rhinoceros.africa. We will acknowledge within one business day, tell you what we found, and tell you when it is fixed. We will not threaten you, and we will credit you if you want to be credited.
If you believe another agency’s data is visible to you in the product, stop, do not explore further, and mail that address immediately. That one is treated as an emergency.
Bring your security questionnaire to the demo
We would rather answer it in the first forty minutes than in month three. If there is a question on it we answer badly, that is worth both of us knowing before a contract.