Raw events in.
Closed incidents out.
SecureOps AI takes in security events, tests them against the detection rules you enable, and carries whatever survives through triage, investigation and containment — scoped to one tenant, and recorded at every step.
- Isolation
- Every read scoped to one tenant
- Realtime
- Authorized private channels
- Analysis
- Assistive, and you configure it
- file.csv_json
- webhook.signed
- file.syslog
- file.csv_json
- webhook.signed
- file.syslog
- file.csv_json
- webhook.signed
- 1041High
Security group opened publicly
Defense Evasion - 1040Medium
Console sign-in without MFA
Initial Access - 1039Low
Repeated authentication failure
Credential Access
5 of the 8 events shown matched no rule and raised nothing. Sources, severities and numbering follow the platform’s own model; no rate or volume is claimed.
What happens to one event.
An event does not become an alert because it looks suspicious. It becomes an alert because a rule you enabled matched it. Follow one through the seven stages it passes.
Ingest
ReceivedThe event is stored exactly as it arrived, before anything interprets it.
- Arrives by signed webhook push or by file upload.
- Stored verbatim — the original payload survives normalization.
- Belongs to one tenant from the moment it is stored.
Normalize
ParsedA normalizer maps the payload onto common fields.
- JSON, CSV rows and syslog lines (RFC 3164 / 5424) are mapped the same way.
- Produces the common shape every later stage reads.
- Unparseable events are kept, not silently dropped.
Match
EvaluatedDetection rules are evaluated against the normalized event.
- Each rule carries its own severity, logic and ATT&CK mapping.
- Rules are tenant-scoped or platform-wide, and individually enabled.
- No match means no alert — most events end here.
Deduplicate
CollapsedA fingerprint of the tenant, the rule and the event collapses repeats.
- A repeat raises the occurrence count and moves the last-seen time.
- The first sighting is preserved, so the original is never lost.
- One recurring condition stays one alert.
Raise
Alert openedAn alert is opened, numbered in its own tenant’s sequence.
- Severity is inherited from the rule that matched.
- The original event, the rule and the parsed data all stay linked.
- Downstream work — enrichment, indexing, delivery — is triggered.
Enrich
EnrichedKnown indicators are matched against the event and recorded.
- A match is recorded against the alert as enrichment.
- Severity is raised to the highest of the alert and its matches.
Broadcast
DeliveredThe finished alert is pushed to that tenant’s private channel.
- Carries an identifier, a title, a severity and a status — nothing more.
- Addressed to one tenant’s own channel and to no other.
- Delivery is covered in section 04.
Status is a machine, not a text field.
Alerts and incidents each move through a defined set of states. The transitions are enforced on the server, so a status cannot be set to something the workflow does not allow — and every move is stamped.
- Open
- Triaging
- Investigating
An alert is worked in place. It does not change identity as it moves, so the rule that raised it and the event underneath it stay attached the whole way through.
- Resolved
- False positive
- Suppressed
Suppressed and false positive are outcomes, not deletions. The alert and everything behind it stays readable.
From Open an incident may move to Investigating or Closed — nothing else. Skipping ahead is not a move the workflow offers.
- Priority
- Set independently of severity, as p1 · p2 · p3 · p4. How bad it is and how soon it must be handled are separate questions.
- Linked alerts
- Alerts are attached to an incident and keep their own identity, severity and status while they are attached.
- Timeline
- Every entry records whether it was automated or attributed to a person, and when it occurred.
One tenant’s data is not reachable from another.
Multi-tenancy is where a security platform either holds or does not. Enforcement happens on every request, and it fails closed: if the tenant cannot be established, the request is refused rather than answered broadly.
- alerts
- incidents
- assets
- risk scores
- evidence
- reports
- audit log
- alerts
- incidents
- assets
- risk scores
- evidence
- reports
- audit log
Refused at the boundary
GET /alerts Authorization: Bearer <Tenant A> X-Tenant-ID: Tenant B
The authenticated identity is resolved first and is authoritative. A tenant named by the caller is checked against that answer: it may agree with it, or be refused. It can never widen it.
Request validation- 01
The credential decides
Tenant context is resolved from the authenticated principal first, and that answer is authoritative. A request that carries a credential is scoped to that credential’s tenant and nothing else.
Identity resolution - 02
A claimed tenant may only agree
If the caller also names a tenant — in a header, or by the address they arrive on — that name is checked against the resolved identity. It may agree with it, or be refused. It can never widen it.
Request validation - 03
Every query carries the filter
A tenant filter is appended to every query on every tenant-owned record, and stamped on everything created. Leaving that scope is not something a request can do — it takes a deliberate, auditable exception in code.
Query scope - 04
Unresolvable means refused
If the tenant cannot be established, the request is refused rather than served. An unscoped read would return everyone’s rows, so the failure mode is an error — never a wider view.
Fail closed - 05
The socket is authorized too
Joining a tenant’s private channel runs a server-side check that the subscriber belongs to that tenant. Realtime is not a gap in the boundary.
Channel authorization
Scope of this claimWhat is described above is enforced by the application on every request. Isolation properties that depend on how a particular deployment is configured are not asserted here.
Updates arrive on a feed you were let into.
When something changes, the console is told rather than left to ask. The subscription is authorized on the server first, the feed is private to one tenant, and each event does one specific thing on arrival.
Change committed
committedA change is broadcast the moment the state it describes is durably written — not on a timer.
Subscription authorized
authorizeBefore any channel is joined, the client asks permission, presenting the credential it already holds.
Membership checked
subject tenant = channel tenantThe server compares the subscriber’s own tenant against the one whose channel they asked for.
Private channel joined
private · one tenantOnly a subscriber that passed that check receives anything at all on this channel.
Console updates
re-readThe affected views re-read through the authenticated API. The socket carries the news, not the record.
- waiting for an authorized event
An event carries an identifier and enough context to refresh the right view — not the record itself. The console re-reads through the authenticated API, so what a subscriber can see over the feed is bounded by what they could already read without it.
The model advises.
A person decides.
AI is a step in this workflow, not the workflow. It produces a record — an assessment, a category, recommended steps, a completeness score — and that record is read by an analyst who then makes the call the system will act on.
- System
Signal
An alert exists, with its rule, its normalized event and its enrichment attached.
- AssistOptional
Assistance
An analysis is requested, and it runs only if an AI provider is configured and the tenant is within its AI budget. Identifiers are masked before the prompt leaves.
- Analyst
Analyst review
The output arrives as a record, not an action — an assessment, a category, recommended steps, a false-positive likelihood and a completeness score. It sits next to the alert, waiting to be read.
- Analyst
Decision
A person chooses. The status still moves through the defined workflow, and still requires the permission for that step.
- System
Recorded action
The change is written to the incident’s timeline, marked automated or attributed to a person, and captured in the audit record.
Without a configured AI provider the assist step simply does not run — and the rest of the workflow is unaffected, because nothing downstream depends on it.
Analyses run on Anthropic Claude, within an optional monthly token budget per tenant.
Identifiers are masked before a prompt is sent, by a guardrail that sits between the platform and the provider.
An analysis is stored, not just displayed. Each one keeps what produced it, so a conclusion reached months ago can still be attributed and questioned.
- Provider
- which service answered
- Model
- which model answered
- Input
- tokens sent
- Output
- tokens returned
- Latency
- how long it took
- Completeness
- how much of the answer came back — advisory
The completeness score says how much of the expected answer came back — an explanation, a root-cause hypothesis, recommended actions and ATT&CK techniques. It is not the model’s confidence, and it is advisory: it does not move a status and it does not unlock a step. Nothing on this page claims a measured accuracy, because that is not something the platform establishes.
The record is
the deliverable.
Operational work produces evidence whether or not anyone collects it. This platform collects it as it happens — who changed what, when, on whose authority — so a report is a query over that record rather than an exercise in reconstruction.
- 01
Activity
Alerts triaged, incidents moved, controls assessed, tasks completed.
- 02
Record
Written as it happens — the request audit, the incident timeline, the analysis rows.
- 03
Report
Generated over a chosen window, as one of three kinds.
- 04
Delivery
Retrieved through the authenticated API, never a public link.
- Executive
- Posture and movement, written for a reader who does not work in the console.
- Technical
- The detail behind the summary — alerts, incidents and their findings.
- Trend
- Direction over a chosen window rather than a single moment.
last_7_days · last_30_days · last_90_days · this_month
- pending
- processing
- completedfile available
- failederror retained
A completed report is fetched by the authenticated client, with the same permission check and tenant scope as any other read. It is not a public link that happens to be hard to guess.
- ISO 27001ISO/IEC 27001:2022
- NIST CSFNIST Cybersecurity Framework 2.0
- SOC 2SOC 2 Type II — Trust Services Criteria
- CIS v8CIS Controls v8
- GDPRGeneral Data Protection Regulation
These are the control sets you can assess yourself against inside the platform: map controls, attach evidence, track gaps and remediation. They describe what the software models. They are not audits SecureOps AI has passed, and no certification is claimed on this page or implied by their presence here.
7 roles, named permissions.
Permissions are named for the thing they permit and checked where the work happens, not inferred from a job title. A role is a bundle of them, and an auditor’s bundle is deliberately narrow.
- super_admin
- tenant_admin
- soc_analyst
- security_engineer
- compliance_officer
- auditor
- read_only
Control plane
The surfaces an evaluator asks about, and what each one actually is.
Identity
- Multi-factor
- TOTP enrolment and verification, enforced per tenant policy
- Single sign-on
- SAML and OIDC providers, with just-in-time provisioning
- Directory sync
- SCIM tokens for provisioning from an external directory
- Machine access
- Per-tenant API keys, never stored in a recoverable form
Authorization
- Roles
- 7 built-in roles, from super_admin to read_only
- Permissions
- Named permissions checked at the endpoint
- Tenant scope
- A tenant filter on every read of every tenant-owned record
- Channel scope
- Server-side authorization on every private subscription
Accountability
- Request audit
- The API surface is recorded as it is exercised
- Incident timeline
- Every entry marked automated or attributed to a person
- Analysis record
- Provider, model, size and latency recorded for every call
- Report delivery
- Generated files retrieved through the authenticated API
Deployment
- Runtime
- A versioned REST API and a separate web console, containerised
- Realtime
- WebSocket delivery over private, per-tenant channels only
- Queue
- Background workers for ingestion, analysis and reporting
- Model hosting
- Anthropic Claude, called over its API with identifiers masked
See it against
your own events.
The most useful next step is a conversation about the sources you would connect and the rules you would want matched. We will walk through the platform against them.