PhalanxIsolation
A leaked row never reaches another client.
Every table carries a per client access policy enforced by the database itself, and the client context is bound to the token rather than to a request parameter. A wrong query returns nothing.
The platform
One console for the team that defends and the team that has to prove it.
This is not a reskinned SIEM. It is the operational layer that sits on top of your event sources and turns raw alerts into a service you can bill for, with the evidence collected on the way.
For security providers
A whole client book, from one screen.
Your team works across every client with the same login. Each client sees only their own data. That boundary is not a convention in the code, it is a policy the database engine enforces, and the application connects as a role that cannot bypass it.
Onboarding
A new client is running in minutes.
Create the client, send the invitation, the user sets their own password. Isolation applies from the first second, with no extra configuration.
Triage
You see a count, not a wall of alerts.
Events are filtered to the rules that matter for that client active frameworks, and duplicates from the same rule on the same agent are merged.
White label
The client sees their mark. You see yours.
Name, colour and logo per client, in their console and on the cover of exported documents. Your own console is untouched.
For companies that have to prove compliance
A management system that is alive, not filed away.
Documents, registers and evidence live in the same place as the incidents that justify them. When the auditor arrives, you reconstruct nothing.
Documents
Edit policies in the platform, with history and approval.
Versions are kept as text snapshots, an approval records who and when, and a later edit clears the stamp. Export as a document, in Romanian or English.
Guided interview
No documentation at all? Then you answer questions.
The platform runs a structured interview per control and writes the policy from your answers. The session is stored for traceability. A human approves before the policy goes live.
Registers
Risk, vulnerabilities, continuity, change, legal requirements.
The registers an audit asks for, kept in the platform and linked to the controls and cases that feed them. An accepted risk records who accepted it and why.
Audit log
Who changed what, and when. With no way to rewrite it.
Document creation, editing and approval land in an append only log, per client.
What a day looks like
From the first coffee to the evidence attached to the report.
- 01
Morning, the dashboard
How many critical and high alerts, how many open cases, what is waiting for approval. A reading, not an investigation.
- 02
Alerts, already filtered
Only the rules that matter for that client active frameworks. Duplicates are grouped rather than repeated.
- 03
Escalate in one click
A critical alert becomes a case. The title fills itself, and the link back to the originating alert stays.
- 04
The investigation stays written down
Comments, status changes, assignment. The full timeline is preserved in order, for the review afterwards.
- 05
The closed case goes into the report
It attaches to the audit report as structured evidence and seeds the draft of the post incident report.
Direction
What we are working on
Deeper coverage on infrastructure and internal application scanning, and the option to run the AI component on local models for clients who cannot send text outside their network. We do not publish dates, because a published date becomes a promise before it is a plan. If you need something specific, ask and we will tell you where it stands.
Request a quote