Architecture and implementation, for engineers.
This part is for engineers, technical presenters, and anyone who has to answer a question from a customer's security team. Parts 1 to 4 are the book. This is the appendix behind it.
It exists because a technical evaluator will not accept the summary. They will ask where data lives, how one customer is kept from another, what runs on their machines, and who can reach what. A vague answer at that moment costs more than a wrong one, because it reads as evasion.
It assumes you understand ordinary web architecture, identity, and basic security concepts. It does not assume you have worked on the product.
What this part is not:
Two rules apply when using this material with a customer.
Explain the property, not the plumbing. A customer asking about isolation wants to know their data is separate and why that holds. They do not need the component inventory.
Never state current deployment status from memory. Section 5.8 carries that with a date, and it ages faster than anything else here.
This part exists so you can answer a hard question accurately, not so you can recite an architecture.
The product has four layers. Each has one job, and the boundaries between them are the security design rather than an accident of implementation.
| Layer | What it does |
|---|---|
| Customer portal | What customers and their providers see. Read-only against their estate |
| Control plane | The system of record. Owns identity, authorization, entitlements, and governed data |
| Broker tier | Narrow, private services that talk to the collection layer on the control plane's behalf |
| Collection layer | Per-customer infrastructure that gathers security telemetry from endpoints |
Requests move in one direction.
Nothing skips a layer. The browser never reaches the control plane directly, and the portal never reaches the collection layer. Each hop re-authorizes rather than trusting the caller.
Two properties follow from that shape and are worth stating to a technical audience.
The browser is never trusted with authority. It cannot select a tenant, a role, or a permission. Those are derived server-side on every request from the authenticated identity.
No credential for the collection layer ever leaves the private boundary. The portal has none, and the browser has none.
There is also an internal operator application, used by SAGEN staff rather than customers. It is a separate surface with its own authentication and cannot be reached from the customer portal.
Two terms belong to this layer and not to a customer conversation. Wazuh is the collection technology. The brokers are internal services. Neither is a product name.
Four layers, one direction, and authorization re-established at every hop.
Collection is the path from a customer's machine to a finding in their workspace. It runs in one direction and is read-only with respect to the customer's environment.
An agent runs on each enrolled endpoint and reports security telemetry to that customer's collection stack. The control plane never queries the endpoint directly, and the endpoint never talks to the portal.
The most interesting design decision is the two-broker split. Two separate services sit between the control plane and the collection layer, with separate credentials and separate processes.
| Broker | What it does | What it cannot do |
|---|---|---|
| Enrollment | Creates one collector identity per device, returns the key only to the calling control plane request | Read alerts or vulnerabilities |
| Observation | Returns bounded, normalized security summaries | Mutate anything, or return raw documents |
The reason is containment. If the read path were ever compromised, it yields summaries rather than the ability to enroll agents or obtain collector keys. And the enrollment surface never becomes a general-purpose security search API.
Both are private and loopback-only. Neither is internet-facing, and both require authenticated, signed requests from the control plane.
What crosses into the governed record is normalized and bounded. Raw telemetry stays in the collection layer, and the portal cannot inspect raw events at all.
This is a genuinely good answer to a security team asking what SAGEN can reach. The honest version is that the read path is deliberately narrow and cannot write anything.
Collection is one-way, read-only, and split so that neither half can do the other's job.
A tenant is one customer's boundary. Isolation is how the platform keeps one customer's data out of every other customer's view, and it is the question a security team asks first.
Isolation holds at three levels.
Collection is per-customer. Each customer's telemetry is gathered into their own collection stack rather than a shared pool. Separation begins before the data reaches the platform.
Authorization resolves to a single tenant. Every request is re-authorized by the control plane, which maps the authenticated identity to exactly one tenant and refuses anything that would cross the boundary. A request naming another tenant does not fail with an access error. It resolves to nothing.
The browser cannot influence scope. Tenant, client, role, and capability are derived server-side. A browser supplying its own values is ignored rather than trusted.
One detail is worth offering unprompted, because it demonstrates the design rather than asserting it. An unauthorized customer identifier returns the same not-found response whether or not that customer exists. Nobody can enumerate the customer base by probing identifiers.
Be precise about the mechanism. Isolation is enforced by the application and the platform on every request, rather than by database-level row security. That is a real and defensible design, and overstating it to a security engineer who then finds otherwise is worse than describing it accurately.
Access is also revocable in effect immediately. Removing a membership blocks the next request rather than waiting for a session to expire.
Separate collection, single-tenant resolution on every request, and a browser that cannot choose its own scope.
Access is decided server-side on every request and denies by default. A person sees what their memberships and grants allow, and nothing about the browser can change that.
Sign-in to the customer portal uses an email one-time-code flow. Before a code is sent, a user is created, or any data is returned, the email is checked against the membership registry. Two consequences follow. Removing or suspending a membership blocks the very next request rather than waiting for a session to lapse. And the response does not reveal whether an address is known.
Authorization has two shapes.
Direct access requires an active membership for that customer.
Provider access requires three things at once: an active provider membership, an active assignment to that customer, and an explicit, unexpired capability grant. A business relationship on its own grants nothing.
Capabilities are specific rather than general. Reading endpoints, reading findings, reading systems, creating invitations, and managing members are separate grants, and holding one does not imply another.
Sessions are cookie-based, marked secure and same-site in production, and re-checked on every protected request.
SAGEN staff who need to see a customer's view use support view, which is audited delegation rather than impersonation. An authorized operator selects a compatible read-only role and supplies a reason. The session is created by a one-time exchange, is read-only with mutations failing closed, expires within thirty minutes, and displays a persistent banner naming the actual staff member.
That last point is worth saying to a customer unprompted. Support access is visible, time-limited, reasoned, and recorded.
Deny by default, re-authorized every request, and staff access that is visible and recorded.
Enrollment is how a customer's machine becomes a reporting device. It is designed so that nothing reusable is ever handed to an endpoint or to the person installing it.
The activation code is single-use, short-lived, and scoped to one campaign. There is no shared password to circulate. The control plane stores only a hash of the code, so the code itself is not retrievable from the platform.
The device generates its own key pair during installation and keeps the private key locally. What the platform learns is the public half. Identity is therefore something the device proves rather than something it is given, and replay of a registration is rejected.
Once registered, the device receives a collector identity unique to itself. It never receives a shared collector password, a tenant identifier, or credentials belonging to any other device.
Capacity is enforced at the platform. A campaign cannot issue more activations than the customer's entitlement allows, and the reservation is atomic so concurrent requests cannot oversubscribe.
The installer talks only to the platform's enrollment endpoint over HTTPS on the standard port. It is not given a route to the collection layer.
This is the answer when a customer's security team asks what happens if an activation code leaks. The code is short-lived, single-use, grants no platform access, and cannot be replayed. The realistic worst case is one unwanted device registration against a bounded entitlement.
The endpoint proves its identity rather than being handed one.
Environments are fully separate. Preview and production use different application instances, different databases, different domains, and different credentials. Nothing is shared, and credentials never move between them.
That separation is enforced rather than agreed. A production build resolves the production configuration and fails if a preview origin, a preview database, or a development binding appears anywhere in the artifact.
The same reviewed release moves forward. Production is promoted from an exact reviewed commit rather than built independently, so what runs in production is the artifact that passed the gates.
A production deployment revalidates configuration, runs the full check suite, builds and validates the artifact, records the previous version, deploys, and then runs live smoke checks. If the smoke checks fail, it rolls back automatically to the recorded previous version.
Every material change requires a tracked issue, a branch, tests, review, documentation, and an explicit authorization step before deployment. A commit does not authorize a release, and merging does not deploy.
Database migrations are additive and are not automatically reversed. That is a deliberate constraint: a rollback restores the application, and data changes are handled forward rather than undone.
For a customer conversation, the useful summary is short. Customer data lives only in production, the same reviewed release is promoted rather than rebuilt, and a failed deployment reverts itself. The internal process detail is ours.
Separate environments, one promoted artifact, automatic rollback on failure.
Last reviewed: 2026-09-08. Recheck before every distribution of this book.
This chapter ages faster than anything else here. Everything in it is a snapshot of engineering state, and quoting it from memory months later is how someone says something wrong.
Availability is settled and is not what this chapter is about. All SAGEN services and the product are available to close a deal today. What follows is engineering state for people who need it, not a qualification on selling.
The distinction that matters internally is between what is built, what is enabled in a given environment, and what is offered commercially. Those are three different things, and this chapter concerns the first two.
Two current states are worth knowing.
The weighted-domain grading model is in calibration. It exists in the product and is pinned to a non-authoritative mode. The live customer-facing measure is the endpoint posture score with its separate evidence confidence. Section 3.7 is written accordingly.
Endpoint platform coverage differs by maturity. Windows, macOS, and Linux are all addressed, and the release and signing work behind them is at different stages. Confirm current coverage with engineering before committing to a specific platform in a deployment plan.
Two rules follow.
Do not quote engineering state to a customer. Answer availability, and refer scheduling and platform specifics to delivery.
Do not treat a design document or a mockup as evidence of a feature. The repositories contain specifications for work that has not shipped, and a page describing a capability is scope rather than delivery.
This chapter is a dated snapshot. If the date above is old, ask rather than quote.