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 agent. 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.
Read the details
- 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 one identity per machine, revocable within a minute. For people: password plus a mandatory second factor, on every account, without exception. Never a code by SMS.
- Authorisation
- Fixed rules first, a classifier for ambiguous cases, deny by default, enforced on the agent's machine. Every decision is logged.
- Runtime control
- Every tool an agent uses goes through a controller that checks the action against fixed rules, then a classifier. Anything outside the authorised perimeter is refused and logged.
- One machine per agent
- Volumes, networks, secrets and memory dedicated to each agent, on its own machine. 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
- Each agent's files and memory are backed up every working day, each archive checked as it is written. Restoring the hub is documented and tested.
Three transport layers, independent.
Between two zones, three layers stack up. Each brings its own guarantee; none depends on the others to work.
Read the details
- 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.
Read the details
- 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.
Read the details
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 agent, on its machine, accessible to that agent only.
Audit trail
Private hub
Decisions, sensitive actions, state transitions, sealed. Append-only, exportable; viewing it from the cockpit 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.
Read the details
The chain proves, the score measures.
The audit chain proves what happened; the trust score measures what is happening.
Read the details
- 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.
- Viewing recorded
- Viewing the log from the cockpit produces a sealed event of its own in the chain.
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.
Read the details
- 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.
- Memory
- Vector search, a graph of relations over time and a cache of recent context, specific to each agent.
- Deployment
- Builds checked by rebuilding from the repository; images published with a version manifest compared against the hub.
How an agent runs.
Delegation, tools, memory, restarts, language: each mechanism is bounded by rules set in the code and leaves a trace in the audit chain.
Read the details
- 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.
Read the details
V1, today
- Three-zone architecture and a dedicated machine per agent
- 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.