Security briefing · for CISOs, DPOs and architects
A security control should never guess.
This briefing explains how Sluss sits in your network, why its decisions are deterministic, how rollout avoids disruption, and what evidence you hand your auditor.
01 · Architecture
One gateway. No agents. Nothing leaves your perimeter.
Central reverse proxy
Sluss runs as one gateway in your data centre, DMZ or EU cloud tenant. Clients reach models only through it.
No endpoint agents
Nothing is installed on laptops. Applications, agents and IDEs change one base URL to point at Sluss.
Egress enforced at the network
Block direct traffic to public LLM APIs at the firewall, and Sluss becomes the only sanctioned path out.
Blocks that explain themselves
A blocked request returns 403 with a block code, task class and data class in the response — never prompt content. Reroutes carry the reason too, so users understand instead of opening tickets.
Shadow mode built in
Compare a candidate policy against live traffic before activating it, and dry-run any prompt from the command line.
No call-home
Self-hosted and open source. Prompts, logs and policies never leave your infrastructure.
Split routing · a router, not a wall
Teams keep their AI. Sensitive data just takes a different road.
public
Public / general
→ Approved cloud
OpenAI · Anthropic
sensitive
Personal data · secrets
→ Local EU model
Ollama · vLLM on your hardware
no route
No approved destination
→ 403 · fail-closed
Explained to the user · audited
Zero-agent deployment
One base URL. No software on laptops.
Sluss runs as a central proxy in your network. Block direct AI egress at the firewall and it becomes the only sanctioned path out.
# before — straight to a US cloud OPENAI_BASE_URL="https://api.openai.com/v1" # with Sluss — inside your perimeter OPENAI_BASE_URL="https://sluss.internal.example/v1"
02 · Deterministic by design
Why no LLM decides what leaves the building.
Using a model to police a model puts a probabilistic, injectable component inside your security control. Sluss uses rules and checksum validation instead.
| Question | LLM-based filter | Sluss |
|---|---|---|
| Decision latency | Hundreds of ms per call | Under 1 ms, in memory |
| Cost per request | Extra tokens on every prompt | Zero tokens |
| Same input, same result | Not guaranteed | Always |
| Prompt injection | The filter can be talked out of it | Rules do not read instructions |
| Explaining a decision | "The model judged it" | Named rule, matched pattern, timestamp |
| Where inspection happens | Often a third-party cloud | Inside your perimeter |
03 · Rollout
Strict where it matters. Invisible everywhere else.
Monitor
Run on real traffic with nothing blocked. See what would have been caught and where data was heading.
Tune
Adjust rules and routes with your DPO. Checksum validation (e.g. Luhn for Swedish personal ID numbers) keeps false positives low.
Enforce
Switch to enforce per policy pack. Sensitive prompts reroute to local models; only unroutable requests are blocked.
04 · Evidence
What you put on the auditor's desk.
- 01Each entry records the caller, matched rule, data class, destination and decision.
- 02Every entry includes the hash of the previous one, so any edit or deletion breaks the chain.
- 03Auditors verify the exported chain offline with the open-source audit-verify tool — no access to Sluss needed.
05 · Regulatory mapping
How Sluss supports your obligations.
| Regulation | Relevant provisions | How Sluss supports it |
|---|---|---|
NIS2 DIR (EU) 2022/2555 | Art. 21(2)(d) supply-chain security · Art. 21(2)(i) access control and asset management | Egress control to AI providers, agent permission gates, decision logging |
DORA REG (EU) 2022/2554 | Art. 9 protection and prevention · Art. 10 detection of anomalous activities · Art. 28 ICT third-party risk | Policy-bound routing to approved providers, fail-closed blocking, audit evidence |
GDPR REG (EU) 2016/679 | Art. 5(2) accountability · Art. 25 data protection by design · Art. 32 security of processing · Art. 44–46 third-country transfers | Personal data kept on local or EU models, third-country transfers blocked by default |
AI Act REG (EU) 2024/1689 | Art. 12 record-keeping · Art. 26(5) deployer log retention — high-risk systems | A complete, tamper-evident record of which AI systems received which data |
Indicative mapping — not legal advice. Sluss supports controls; compliance depends on your full programme.
Match your policy
Paste your own rules. See how Sluss covers them.
Enter your organisation's AI or data-handling rules. Each one is mapped to a Sluss control and marked Covered, Partial or Not covered.
Rule-by-rule coverage will appear here.