Control access, protect sensitive data and decide where model requests can go. Keep a record your team can inspect and verify.
Access starts with Microsoft, Google or Apple sign-in, authenticator-app 2FA, roles and workload credentials. From there, your policy travels with each model request.
Welcome Alex Morgan
Welcome PERSON_1
8f21… → b40a… → d93c…Example request · your policy determines the action.
Choose detection profiles for personal data and secrets. Replace detected values with reversible tokens before the request reaches the model.
Your policy can tokenize, mask, block or log detections. On protected scans, handwriting and ink the OCR cannot read are destroyed, not guessed. No detection profile guarantees complete coverage.
Explore data protectionEU-only by default. Hosting region, provider ownership and your allow-list determine which model routes are eligible.
An EU hosting region and EU provider ownership are separate controls.
Explore residency and DPAEach request is recorded once, with the checks that ran on it grouped underneath: name recognition, data protection, scope guard and security scan. Routing and outcome join a hash-chained audit trail you can export and verify independently.
With content retention on, the request trace shows each tool call’s input and output together.
Try verifying a recordEach record is linked to the one before it. Changing a sealed record breaks the chain’s verification.
Try it with this sample: change the scope guard verdict, then restore it to see the difference.
……………This local example recalculates the hashes. No customer records are used.
The audit log lists each request once, with the checks that ran on it grouped underneath. Expand a row to see each layer’s verdict and cost.
Configure how long request and response content is retained. Content can be purged while audit metadata and hash links remain available for verification.
Retained content and caches are encrypted at rest. Turn content retention off for a metadata-only ledger; response caches are then disabled too.
Explore retention controlsPrepare a welcome email for Alex Morgan.
Start with the documentation. Bring your questions, procurement requirements and security questionnaire to our team.
Read the standard agreement and review your organisation’s sub-processor annex in the console.
See the providers your organisation can reach, including region and ownership.
Review methods, measured results and limitations for the detection layers.
Discuss your requirements with the team and request the supporting documents.
Send security reports privately to hello@sluis.ai.
No. Hosting region and legal ownership are separate controls. The EU-owned-only setting excludes EU-region deployments of providers owned outside the EU.
No detection profile guarantees complete coverage. Choose the layers for your data and review benchmarks and outcomes. Optional hosted inspection processes remaining eligible text with a provider and adds latency and cost.
The coding agent and working files stay on the developer’s machine. Sluis governs its model traffic and exposed MCP tools. The provider chooses the serving region for subscription-backed agent requests, which is recorded as unverified.
Yes. Sluis Edge runs the data plane, retained content, credentials and audit ledger in your environment. Use local models when model traffic must stay inside your network.
No. Pseudonymization works one way: it protects what your organisation sends out. In Sluis Workspace, public web search results reach the model unaltered. A value your conversation already tokenized stays tokenized inside those results, so a result cannot reveal what a token stands for.
We’ll work through the data flow, controls and evidence with you.