Built to be argued with
Security teams do not buy claims, they buy mechanisms. This page describes how separation, access and destructive action actually work, so your own security review has something to bite on.
Separation is enforced below the application
Multi-tenant leaks happen when isolation depends on every query remembering to filter. So it does not depend on that.
Row-level security
databaseTenant-bound reads are scoped by the database itself against the workspace on the request. A query that forgets its filter returns the caller’s own rows, not everyone’s — the safe outcome is the default rather than the thing a reviewer has to catch.
Its own SIEM connection
no fallbackEach workspace holds its own backend credentials and indices. A workspace with no connection configured returns nothing — it never quietly falls back to a shared or default connection, which is the single most dangerous convenience in multi-tenant security tooling.
Bound at sign-in
sessionThe workspace is carried by the session, not by a header a client can set. Administrative routes refuse to run until a workspace has been deliberately selected.
Separation is tested
regressionCross-tenant isolation has automated tests that assert an empty workspace stays empty while a populated one is unchanged. It is checked continuously rather than asserted once in a document.
Access control
Ranked permissions
Analyst, senior analyst and administrator form a hierarchy, with read-only views for executives and customers. Destructive endpoints require a rank, checked on the server on every request rather than by hiding a button.
Multi-factor sign-in
Time-based one-time codes can be required for every account. Repeated failures lock the account rather than inviting a patient attacker to keep going.
Sessions expire
Tokens are time-limited and server-side, so revocation is immediate and there is no such thing as a permanent session.
Actions are recorded
Configuration changes, case closures, approvals and automated actions are written to an audit trail with who, what and when — including the ones nobody was watching.
Containment is deliberately hard to do by accident
Isolating a host is the one action that can turn a false positive into an outage. It is gated accordingly, and the gates are the product.
A person asks
Containment is requested by a senior analyst from the case. There is no automatic path — an automated playbook cannot contain an endpoint on its own, however confident it is.
A different person approves
A second senior analyst must approve, and it cannot be the same person who asked. Approval requests expire after thirty minutes rather than sitting open indefinitely.
Protected assets refuse
Assets marked protected in that workspace cannot be isolated or have processes killed. The veto applies to the request and again to the approval — the conditions are re-checked at the moment of action, not only when the request was raised.
Queued is not done
An accepted instruction means queued, not completed. The action is tracked to its real outcome and reported as successful only when the platform that performed it says it succeeded.
Everything is written down
Who asked, who approved, what was targeted, what came back. Containment without a record is not containment, it is an incident of its own.
Blocking an address or disabling an account are not SIEM actions. They run through connectors to the network edge or the identity provider that actually owns that control, under the same approval model.
Silent failure is treated as a defect
The dangerous failure in a SOC platform is not the one that throws an error. It is the queue that quietly stopped, the sync that has not run since Tuesday, the scheduled job that fails at 3am into nobody’s inbox.
Background work exposes health signals, metrics are collected and dashboarded, logs are aggregated, and alerting rules fire on the platform’s own behaviour. A component that can fail without anyone noticing is required to publish a signal that says so.
- OKAlert ingestion12s ago
- OKTriage queue0 stalled
- WARNLog source quiet4h
- OKIntelligence sync31m ago
Two ways to run it
Identical platform. The question is who operates it and where your security telemetry lives.
SOCPilots Cloud
managed subscription- Operated, patched and monitored by us
- Connects outward to your SIEM — it stays where it is
- One isolated workspace per organisation
- Encrypted in transit and at rest
- Upgrades without a maintenance window
Self-hosted
your infrastructure- Container stack deployed with Docker Compose
- Runs on a single well-specified host to start
- No security telemetry leaves your network
- Your own model keys and intelligence feeds
- Suits regulated, sovereign and air-gapped estates
Send us your security questionnaire
We would rather answer it properly than have you guess from a website.