Architecture
Architecture.
Warpbeam is the warp beam that holds your identities; around it, like a loom, it has fixed parts and a fixed order. Here you see both: what Warpbeam is made of, and how it is meant to run for you.
StatusThe pictures show the target state. Every building block states its status, measured on 23 September 2026.
Design
Every part a building block.
The warp beam is Warpbeam itself. We use the other parts of the loom as a map: each stands for a building block, from the back rest for the lifecycle to the cloth beam where the evidence builds up. Pick a part to see what it does and how far along it is.
- Usable today The core flow runs in our test environment.
- In progress Parts run, the core flow not yet completely.
- Target state Decided and specified, not built yet.
Where we measure, the maturity level is shown: 0 missing, 1 foundation, 2 usable, 3 extensive, 4 complete. Coverage means the share of planned functions that is built; partly built counts half. Measured on 23 September 2026; today no capability is above maturity 2.
Pick a part of the loom. The explanation appears below the picture; a second click or the Escape key closes it.
No part selected yet.
-
Warp beam: Warpbeam itself
Usable today
The warp beam is Warpbeam itself: it holds every thread in one place, ordered and under tension. At its heart is the identity core: every identity with its access rights and relationships, such as who is accountable for a service account.
Today Warpbeam brings together identities from your existing directory, connected optionally, and from other sources. Relationships as a service of their own are in progress. A directory of its own, so Warpbeam can run without anyone else's directory, is the target state.
- Identity repository Maturity 2 of 4 (usable) · coverage 17 %
- Relationships Maturity 1 of 4 (foundation) · coverage 16 %
-
Warp threads: Identities
In progress
Every warp thread is an identity: employees, contractors and partners, service accounts and applications, devices and AI agents. They all sit on the same warp beam and follow the same rules.
Today Warpbeam manages your organisation's own people and service accounts. Contractors and application identities are in progress. AI agents as identities with an accountable human are the target state, and so are devices.
-
Back rest: Lifecycle
In progress
The back rest keeps the tension while the threads feed through. In Warpbeam these are the sources and the lifecycle: joiners, movers and leavers come from the HR system or a list and are meant to take effect everywhere.
Parts of this run in our test environment; end to end, from source to the last system, it does not yet. Checking that a new identity is who it claims to be is being built.
- Lifecycle Maturity 1 of 4 (foundation) · coverage 15 %
- Onboarding and proofing Maturity 1 of 4 (foundation) · coverage 3 %
-
Lease rods: Order
In progress
Lease rods keep the threads apart so nothing tangles. In Warpbeam, tiers separate the administrators of the most critical systems from everyone else, and tenants separate organisations from each other.
Tiers for administrators and temporary elevation of rights run in parts. We are extending them into one continuous flow. Sessions on servers (RDP, SSH) are to run through a session engine of our own, with recording.
- Privilege elevation Maturity 1 of 4 (foundation) · coverage 25 %
-
Shafts: Access
Usable today
The shafts lift exactly the threads that should be on top right now. In Warpbeam, roles and policies decide who may do what. Privileged rights exist only for a limited time and with approval.
Roles, policies and time-bound rights are usable today. Policies that decide afresh at the moment of each request are being extended.
- Roles and policies Maturity 2 of 4 (usable) · coverage 15 %
- Dynamic authorization Maturity 2 of 4 (usable) · coverage 19 %
- Just-in-time access Maturity 2 of 4 (usable) · coverage 18 %
-
Reed: Sign-in
Usable today
The reed beats every weft thread firmly into place. In Warpbeam that is sign-in: multiple factors, a sign-in guard that stops suspicious attempts, and control over running sessions.
The sign-in guard and factors are usable today. A sign-in service of our own that signs users into applications via OIDC, OAuth and SAML is decided, with a protocol core of its own; it is not built yet. It is the prerequisite for running without anyone else's sign-in service.
- Adaptive authentication Maturity 2 of 4 (usable) · coverage 29 %
- Strong and passwordless sign-in Maturity 2 of 4 (usable) · coverage 13 %
- Sessions Maturity 1 of 4 (foundation) · coverage 13 %
- Federation Maturity 1 of 4 (foundation) · coverage 5 %
-
Shuttle: AI control centre
Target state
The shuttle carries the weft across the warp. In Warpbeam that is the AI control centre: it explains, recommends and acts, but only at the level you allow for each task, from 0 (off) to 5 (fully autonomous). The default is level 2, recommend.
Every AI action passes one checkpoint; the log and the emergency stop can never be switched off. The language model is to run inside Warpbeam itself, delivered as a signed data package. The rules are decided; no AI function is built yet. Today Warpbeam works entirely without a language model.
-
Weft: Applications
In progress
The weft runs across all the warp threads. In Warpbeam these are your applications and systems: connectors bring them in, so accounts, access and sign-in follow the same rules everywhere.
Today Warpbeam creates accounts in your existing directory and via SCIM. A framework that connects applications step by step through open standards such as SCIM, LDAP, REST, SQL, CSV, OIDC and SAML is in progress.
- Provisioning Maturity 2 of 4 (usable) · coverage 17 %
- Identity API Maturity 2 of 4 (usable) · coverage 16 %
-
Breast beam: Control
Usable today
At the breast beam the cloth is seen first and checked. In Warpbeam that is control: having access confirmed regularly, finding risky rights and detecting attacks on identities.
Access reviews, access analytics and attack detection are usable today. Containing detected attacks and checking conflicts within one application are being extended. This includes a backup of your existing directory of our own, from which anything from a single attribute to the whole directory can be restored.
- Access governance Maturity 2 of 4 (usable) · coverage 12 %
- Access analytics Maturity 2 of 4 (usable) · coverage 30 %
- Identity threat detection and response Maturity 2 of 4 (usable) · coverage 19 %
- Behaviour analytics Maturity 2 of 4 (usable) · coverage 21 %
- Application risk Maturity 1 of 4 (foundation) · coverage 9 %
-
Cloth beam: Evidence
In progress
The finished cloth is wound onto the cloth beam. In Warpbeam that is evidence: who allowed what and when, human or AI, stays provable. Auditors should be able to ask, not search.
Today Warpbeam logs changes with time and author. Tamper-proof evidence and audit packs for common frameworks are in progress.
Operation
Three forms, one package.
The Warpbeam server is meant to run on Linux, in containers. Small on one machine, highly available as a cluster, or as a service from Germany: every form is meant to use the same signed container images. Windows then only remains as an agent on your side. In our test environment Warpbeam already runs as a Linux container, on-prem and as a multi-tenant service. It is not yet available.
All three forms are decided and specified; the small one is built first.
Pick a building block. The explanation appears below the picture; a second click or the Escape key closes it.
No building block selected yet.
-
Small: Ubuntu + Docker
In progress
The standard form: one virtual machine with Ubuntu LTS, Docker inside, and Warpbeam as containers. It comes as a ready-made VM or as a script for your own Ubuntu. One command installs, one updates, one rolls back.
Hardening, an encrypted data disk and signature checks of the images are set up out of the box. In our test environment Warpbeam already runs as a Linux container, on-prem and as a multi-tenant service, checked automatically with every change. We are building the ready-made VM and the install script.
-
High availability: Kubernetes
Target state
Three such machines form a cluster with Kubernetes (k3s) and a replicated database (PostgreSQL with CloudNativePG). If one machine fails, the others take over.
The images are the same as in the small form. If you already run Kubernetes, you use the same package there. For running without anyone else's directory this form is mandatory, because Warpbeam then carries every sign-in.
-
SaaS: hosted in Germany
Target state
As a service, Warpbeam is the same solution, only we run it: with a hosting provider in Germany, region DE. Customers are tenants on shared instances.
Every tenant reaches Warpbeam at an address of its own and never sees another tenant's data. The database itself separates tenants (row-level security), every tenant has its own keys, and an automated separation test runs with every change. We access your data only with your approval, time-limited and recorded.
The migration tool is available only as a service: it moves identities, access rights, mailboxes and files between directories, mail systems and file stores, including into a sovereign environment. If you run Warpbeam yourself, you get a time-limited tenant for this.
-
Windows agent: on your servers
Usable today
Windows only remains on your side: as a small agent on the servers of your existing directory and on other Windows servers. It reads what Warpbeam needs to know and carries out approved changes.
The agent opens the connection itself: mTLS, outbound only, with its own certificate per agent. You open no inbound port for it. The agent runs in our test environment today.
-
Linux agent: on Linux servers
Target state
Linux servers are to get an agent of their own, with the same connection: mTLS, outbound only. It is meant to handle sign-in, local accounts and policies like the agent on Windows.
Rotating passwords of privileged accounts on Linux servers over SSH is built, but not yet proven against real Linux servers. The agent is the target state.
-
Applications: open standards
Target state
Applications sign their users in with Warpbeam via OIDC or SAML; older applications ask via LDAPS or RADIUS. Accounts and access arrive through connectors such as SCIM.
The sign-in service for OIDC and SAML is decided but not built yet. LDAP and RADIUS from Warpbeam's own directory are the target state.
- Federation Maturity 1 of 4 (foundation) · coverage 5 %
-
Your own model: optional
Target state
The language model runs inside Warpbeam itself (see roles). If you already run a model of your own, in your data centre or with a provider of your choice, you can connect it instead.
Only redacted data goes there as well: Warpbeam replaces names, identifiers and secrets first. Without a model Warpbeam keeps working in full. The connection is the target state.
-
Keys: HSM optional
In progress
The most important keys belong in a hardware security module. Warpbeam uses the open standard PKCS#11 for this and is tied to no particular device.
Not everyone has such a module: a built-in software key store is always included and is shown as a lower protection level. Today Warpbeam encrypts secrets with built-in means; connecting via PKCS#11 is the target state.
- Secrets Maturity 2 of 4 (usable) · coverage 14 %
The connections in the picture
- Agent → Warpbeam
- mTLS, outbound only from the agent. Every agent has its own certificate.
- Applications → Warpbeam
- OIDC, OAuth and SAML; LDAPS and RADIUS for older applications.
- Warpbeam → your own model
- optional, redacted data only, and only if you switch it on.
- Warpbeam → keys
- PKCS#11 to the hardware security module, or the built-in software store.
- Your team → Warpbeam
- HTTPS in the browser.
Roles
One package, engines of its own.
Warpbeam is meant to deliver every capability with an engine of its own: sign-in service, sessions on servers, web application firewall, web gateway, protocol service and AI. Third-party products are never meant to be a prerequisite; today, some sessions on servers still run through a third-party component. Only basic building blocks come from outside, such as the operating system, database, libraries and open standards.
All engines are meant to ship in the same container image. The core with the database always runs; you switch on the other roles when you need them. When you run Warpbeam yourself, no module is meant to be technically locked.
Pick a role. The explanation appears below the picture; a second click or the Escape key closes it.
No role selected yet.
-
Core: roles web and worker
Usable today
The core is the browser interface, the API and the background workflows, plus the bundled database. Engines without a role of their own run here too: collecting, assessing and answering security events (SIEM and SOAR), metrics as time series, and reports as PDF.
Interface, API and workflows run in our test environment today, and so does a first analysis of security events. Time series and PDF reports are being built.
- Orchestration Maturity 2 of 4 (usable) · coverage 9 %
- Security events Maturity 2 of 4 (usable) · coverage 14 %
-
Sign-in service: role idp
Target state
The sign-in service signs users in to applications over OIDC, OAuth and SAML, with a protocol core of its own. Signing keys sit in the security module or the built-in key store.
It is decided and specified but not built yet; it is the prerequisite for running without anyone else's sign-in service. No language model has a say there.
- Federation Maturity 1 of 4 (foundation) · coverage 5 %
-
Session gateway: role gateway
Target state
Admin sessions on servers run through a session engine of our own for RDP and SSH, in the browser and with recording. The gateway itself has no access to the database; in separated networks, each zone gets a gateway of its own.
Today Warpbeam brokers sessions in part, SSH still through a third-party component that this engine will replace. Recordings can be viewed and retained, but none are produced yet. Our own engine for RDP and SSH is decided but not built yet.
- Sessions Maturity 1 of 4 (foundation) · coverage 13 %
-
Web proxy with WAF: role wam
Target state
The web proxy sits in front of web applications that have no sign-in of their own. It signs users in and checks every request with a web application firewall of its own: rule sets, rate limits and protection against automated attacks.
The same firewall also protects Warpbeam's own endpoints. It is the target state.
- Web access management Maturity 1 of 4 (foundation) · coverage 1 %
-
Web gateway: role swg
Target state
Access on the road and to the internet runs through gateways of our own, in two stages. First, access to applications based on identity and device, without a VPN. Then a web gateway that filters addresses by category and inspects encrypted traffic only if you switch it on.
The first stage has a foundation; the web gateway is the target state.
- Secure service edge Maturity 1 of 4 (foundation) · coverage 6 %
-
Protocol service: role protokoll
Target state
Older applications and network devices query Warpbeam over LDAP and RADIUS; security events arrive via syslog. The service holds only a read-only copy; the core checks passwords.
In sovereign operation it is mandatory, at least twice per site. It is the target state.
-
AI runtime: role ki
Target state
The language model runs inside Warpbeam itself: an open model, delivered as a signed data package with checked origin and licence. The role has no access to the database and no connection to the internet. A graphics card makes it faster; none is required.
Per tenant you choose the built-in runtime, a model of your own or no AI. Either way, only redacted data reaches the model, and your data never trains a model. The AI runtime is the target state.