Security is enforced at runtime.
Most AI security policies are documents. Ours run in production: every sensitive action is arbitrated the moment it goes out, by a defence in depth made of several independent layers.
One agent, one machine.
Each agent runs on its own dedicated machine. Isolation is physical before it is software: even if compromised, an agent has no path to another client's data.
Nothing travels in clear.
Conversations kept by the platform are encrypted on disk, in authenticated mode. Nothing travels in clear between your teams and your agents.
- At rest
- Conversations kept by the platform are encrypted with AES-256-GCM, with a key stored outside the database.
- Remote access
- Through encrypted tunnels only. The gateway listens on the machine's local interface only.
- Exposure
- Any public exposure is prohibited in production.
- Outbound flows
- Encrypted and documented: the reasoning model, plus memory embedding in a standard installation. A sovereign installation blocks everything else.
The audit log is sealed.
Every action is timestamped, hashed with SHA‑512 and chained to the previous one with HMAC‑SHA‑512: any later change breaks the chain. The log can be verified from the cockpit and exported for your regulator.
- Timestamped
- Every decision and every action of the agent.
- Chained
- Each sealed event depends on the previous one.
- Exportable
- For your regulator, your auditor, your CISO.
No component raises its own rights.
The agent works inside a perimeter set for it. It can neither widen it nor touch the rules that bound it.
Read the details
- Per-agent profiles
- Allowed tools, safe binaries, restricted scope. A KYC agent does not have the tools of a reporting agent.
- Locked configuration
- Files locked at operating-system level: the agent can change neither its configuration nor its security rules.
- Permission pipeline
- Every sensitive action goes through fixed rules first, then a classifier for ambiguous cases. Destructive commands are refused and logged. When in doubt, the action is refused.
Who decides what.
- 1
Your teamDecides what the agent is entrusted with. Can ask at any time for it to be stopped or replaced.
- 2
Easylab AISets and deploys the rules, tools and permissions of each agent.
- 3
The agentOperates within the set perimeter, with no autonomy beyond the permissions granted.
Hosted in Europe, with no public exposure.
Your agents run on dedicated machines, at Easylab AI or on your premises, in the European Union. Your data and your agents' memory stay in Europe.
Read the details
Easylab AI's list of sub-processors is published on the Compliance Hub.
The other layers.
What still protects, once everything else is in place.
Read the details
- Deny list
- Destructive commands are refused by fixed rules, built into the execution core, ahead of the classifier.
- Blocking checkpoints
- Every tool use is intercepted before execution, and can be blocked depending on context.
- Locked-down workers
- A worker whose authorisation checkpoint is missing does not start: never a permissive fallback.
- Injection resistance
- Multi-pattern filtering of external content, built into the core of orchestration.