The architecture, principle by principle.
Three zones that do not trust each other, transport in three independent layers, a sealed, exportable audit chain. What we publish here are the principles; the detailed file is handed over in due diligence.
Three zones, no trust by default.
The platform separates three logical zones, each deployable on separate infrastructure. Every exchange between them is mutually authenticated, authorised by policy and recorded in an immutable audit chain.
- Exposed bastion
- The only zone exposed to the internet: the cockpit, the public API, authentication and a catalogue of non-sensitive metadata. Compromising it gives access neither to the agents nor to the audit chain.
- Private hub
- Reachable only over the encrypted private network. It carries the orchestrator, the audit chain and the trust score. No route from the internet, no public DNS resolution.
- Isolated agents
- One agent, one machine. Volumes, network, secrets and collections dedicated to each client. A compromised agent has no path to another client's data: isolation is physical before it is logical.
The principles that hold it together.
Security is the structure, not a layer.
Concentric layers: compromising one does not open the next. Here we describe the posture; operational details stay in the due diligence file.
- Perimeter
- A single zone exposed to the internet. Every other component can only be reached over the encrypted private network, with no public DNS resolution.
- Identity
- Mutual authentication between all services, with short-lived identities. For people: password plus a mandatory second factor, on every account, without exception. Never a code by SMS.
- Authorisation
- Versioned, signed policies, central decision, local enforcement, deny by default. Every decision is recorded.
- Runtime control
- Every tool an agent uses goes through a controller that checks the action against a versioned policy. Anything outside the policy is refused and logged.
- Per-client isolation
- Volumes, networks, secrets and memory dedicated to each client. No logical path between two clients.
- Secrets
- Injected at runtime, never in the code, never in the logs. Identity secrets and the secrets that seal the audit chain are strictly separate.
- Observability
- Logs, metrics and audit events go to separate destinations. Audit events are sealed and chained, independently of operational logs.
- Resilience
- Critical state is replicated. Backups are encrypted and restored periodically to check that they work.
Three transport layers, independent.
Between two zones, three layers stack up. Each brings its own guarantee; none depends on the others to work.
- L1
An encrypted private networkThe private zones talk over an encrypted mesh, the modern equivalent of a leased line. It does not carry application security: it can be replaced without touching the rest.
- L2
Mutual authenticationBefore any exchange, each zone proves its identity to the other and checks the other's. A compromised node can be revoked individually, without touching the rest. Even over a public network, exchanges stay authenticated and encrypted.
- L3
An application tunnelA persistent, bidirectional encrypted connection carries the business requests: audit, trust score, orchestration.
An attacker who breaks one layer does not reach the business exchanges: all three have to be broken at once.
Public standards, and one key per purpose.
Cryptographic choices follow current ETSI and NIST standards. No deprecated algorithm in the critical path, no home-made cryptography.
- In transit
- Every exchange is encrypted, with forward secrecy, between your teams, the platform and your agents.
- At rest
- Conversations kept by the platform are encrypted on disk, in authenticated mode.
- One key, one purpose
- The secrets that prove identities never seal the audit chain. Compromising one does not contaminate the other.
- Lifecycle
- Keys generated outside the source code, private material never distributed in clear, rotation on decision or on suspicion, old keys archived so the history stays verifiable, revoked certificates refused by the platform.
Three categories, three perimeters.
Data is separated by sensitivity and lifecycle. Access to one category gives no access to the others.
Metadata
Exposed bastion
User identities, agent descriptions, interface settings. Non-sensitive by design: no business data.
Memory and context
Isolated agents
Working memory, task context, content produced for the client. Dedicated to each client, accessible to the owning agent only.
Audit trail
Private hub
Decisions, sensitive actions, state transitions, sealed. Append-only, exportable; every read is itself recorded.
The lifecycle
- CollectionEvery incoming item is tagged with its category, which sets where it lives and who can access it.
- ProcessingAn agent only processes its own client's data. Context never leaves its zone; third-party models, when used, only receive the minimum necessary.
- RetentionPeriods set per category and per contract; the audit trail is kept for the applicable legal period.
- ErasureOn request for the catalogue and memory. The audit trail cannot be erased: it may be subject to legal retention, never to silent rewriting.
- PortabilityStructured export of your data on request, in a documented, verifiable format.
Data residency
All client data resides in the European Union, on infrastructure controlled by Easylab AI or by subcontractors subject to European law. No transfer outside the EU is made without standard contractual clauses, and no subcontractor subject to an extraterritorial access law touches runtime data.
Each obligation, and the mechanism that covers it.
The platform is designed for regulated, demanding professions, such as finance. The detailed file maps each article to the technical mechanism that answers it.
The chain proves, the score measures.
The audit chain proves what happened; the trust score measures what is happening.
- Append-only
- No event is ever changed or deleted. A correction is a new event, itself recorded.
- Sealed
- Each event is sealed together with the previous one: any later change breaks the chain.
- Verifiable
- From the cockpit, at any time: the platform recomputes every seal with the agent's key. The log can be exported for your auditor.
- Reads recorded
- Every read of the trail produces a sealed event of its own: the auditor is never invisible.
Each agent is assessed every six hours by code, never by the model; the trust service adds the integrity of its audit chain. The score governs what it is trusted with and feeds the governance reports.
How the score is calculatedPortable, open, no lock-in.
Building blocks are chosen for portability and maturity. No closed dependency in the critical data path.
- Runtime
- Standard containers, with no dependency on a particular cloud orchestrator.
- Services
- Mature open-source languages and ecosystems for orchestration, the API, memory and data processing.
- Cockpit
- Web application, server-side rendering for sensitive screens, authentication delegated through an open standard.
- Catalogue
- Relational database, sensitive fields encrypted, encrypted backups.
- Memory
- Vector search, a graph of relations over time and a cache of recent context, isolated per client.
- Deployment
- Reproducible builds, signed artefacts; authorisation policies are deployed as artefacts in their own right.
How an agent runs.
Delegation, tools, memory, restarts, language: each mechanism is bounded by a versioned policy and leaves a trace in the audit chain.
- Isolated sub-workers
- Heavy or risky tasks go to ephemeral sub-workers with minimal tools and permissions, and no access to the agent's full context.
- Governed tool adoption
- An agent only acquires a new tool within the authorised scope, and every change in its capabilities is logged.
- Deterministic recall
- On top of similarity search, a full-text index guarantees that anything written to memory can be found again exactly.
- Memory provenance
- Every memory carries its origin. What the agent produced itself is never re-ingested as an external fact.
- Continuity
- Active sessions survive a restart. A resumption is announced and recorded, never silent; history is never rewritten.
- One language per agent
- Each agent works in its user's language, end to end, with no global setting imposed.
Honest about our maturity.
The platform is at V1: architecture in place, cryptographic primitives in production, regulatory mappings covered. V2 hardens the whole for the most demanding professions, regulated finance among them; the timeline is shared under agreement.
V1, today
- Three-zone architecture and physical isolation per client
- Transport in three independent layers
- Append-only, sealed audit chain
- Continuous trust score
- Isolated sub-workers, governed tool adoption
- Memory with deterministic recall and verifiable provenance
- Session continuity across restarts, language per agent
- Public, downloadable AI Act documentation
V2, the hardening
- Root keys protected by a certified hardware module
- Events centralised to a SIEM hosted in the EU
- Online certificate revocation checking
- Systematic application-level encryption of runtime stores
- Annual external penetration tests
- Independent ISO 27001 and SOC 2 Type II audit
- Continuity and recovery plans exercised and attested
- Formal threat model, reviewed every quarter
We do not claim to be the most mature solution on the market; we claim to be the most honest about our maturity. The current scope is described, the hardening steps are named, and no client is ever presented with a fait accompli.
For your file.
The detailed architecture file (topology, transport, cryptographic primitives, article-by-article mappings) is confidential: it is handed over on request, as part of a due diligence.