Data Controls
What data reaches the platform, where it sits, and which of those things a customer can change. For the ownership split and the binding agreements, see Terms and Policies.
What is sent, and when
Nothing reaches the platform except by an explicit call.
| Data | Sent | Frequency |
|---|---|---|
| Policy text | Policies.save | Once per edit. Never with a check. |
| Content under check | checkText, checkImage | Per call. |
| An API key | Every call | Per call, to authenticate. |
The distinction in the first row is the one that matters most. A policy is compiled ahead of time and configures the service; it is not re-sent with each request. The per-request payload is the content being checked and nothing else.
What comes back
{ verdict, reason } // reason only with { showReason: true }
Deliberately small. The platform keeps per-hour counts of checks, violations and tokens per project and policy set, for the dashboard and billing. Nothing about your end users is in the response, because nothing about your end users was sent.
Controls you have today
Project isolation
An API key belongs to one project, and that project scopes everything. A key for one project cannot read or check against another project's policy sets: a set with the same name in another project is simply a different set. See Projects.
Per-environment keys
Use a separate project, with its own keys, for development, staging and production. This is what makes a revocation survivable — see Revoke compromised API keys.
Policy deletion
Policies.remove(name) deletes a policy set. Checks naming a removed set fail
rather than silently passing. Deleting a project deletes its policy sets and
revokes its keys.
await new Policies(creds).remove('threats-and-weapons');
Where inference runs
Deployment shape decides where data physically sits, and two of the three keep it on your premises:
| Deployment | Where content is processed | What leaves the site |
|---|---|---|
| SDK / API | Platform | The content under check. |
| Industrial monitoring | Local edge node, platform on-prem or cloud | Streams and detections. Nothing is retained in the cloud — storage and the operator console are local. |
| Robotics | On the device | Nothing on the critical path. The cloud is reached asynchronously for revalidation only. |
For an on-premises deployment, the platform box in the architecture is labelled by ownership rather than location precisely because it can sit either side.
Pseudonymous end-user mapping
The platform never receives an end-user identity, so linking a verdict to a user is something you do on your side by recording your own identifier with each check you make. See Safety identifiers for why to set this up before you need it.
Minimising what you send
Two habits reduce exposure without changing the verdict:
- Check the narrowest thing that decides the policy. If a rule is about a message body, send the body rather than the whole record around it.
- Redact before you check where the policy allows it. A policy about threatening language does not need the account number in the same string. Redaction that removes evidence the policy depends on will change the verdict — test it, do not assume it.