# OmniGuard — technical evaluation brief

Website version 3.0.0 · 18 September 2026 · Product in development

## What this public preview provides

This website and its local, hand-authored demonstrations, together with a separately hosted synthetic SOC console linked from the demo page. They illustrate an investigation workflow, permission decisions, human approval and incident receipts. They are not running a detection model or monitoring infrastructure. The website request API is separate from the proposed security platform.

## Intended platform flow

Customer-authorised sources → source verification and minimisation → tenant-scoped event storage → relationship/correlation analysis → evidence-backed incident → policy evaluation → human approval or a specifically pre-authorised action → supported connector → observed result and audit record.

## Visibility and authority

- Audit ingestion alone supplies evidence. It does not create a prevention point.
- Identity operations need specifically delegated response permissions.
- Endpoint response needs supported device capability and customer authority.
- AI/tool enforcement requires requests to traverse an authenticated gateway. A bypass credential invalidates that assumption.
- Sources can be delayed, stale, partial or disconnected. Those states must be visible.

## Agent boundaries

Agents need unique identity, owner, declared task, scoped credentials, allowed tools/resources, data limits, destination restrictions and policy expiry. Approval must bind to exact parameters, not an open-ended intent. The model cannot grant itself extra authority. Content classifiers supplement controls; they are not a guarantee against prompt injection.

## Evidence and investigation

Distinguish raw observation, interpretation and missing evidence. Preserve event and collection times, confidence in entity matching, source references and relevant policy versions. Unusual behaviour may have an approved business explanation. Lack of a recorded transfer is not proof of no data loss.

## Response design

Before any action: scope, target, effect on the business, relevant evidence, authority, expiry and recovery path. Some actions are irreversible. A session cannot be recreated simply because it was terminated accidentally; a new authenticated session is a different object. Data already disclosed cannot be recalled by disabling a share.

After action: verify outcome, preserve evidence and record approver, exact instruction, policy version, resulting state and residual uncertainty. No hack-back or unauthorised third-party operations.

## Data handling questions before a pilot

Specify each data category, purpose, retention, processing region and subprocessor. Decide whether model analysis is disabled, customer-hosted or provider-hosted. Redact before processing where appropriate; never assume redaction is complete. Evaluate tenant isolation, support access, secrets custody, deletion/backups and disaster recovery separately.

## Operating responsibilities

No current promise of 24/7 managed investigation, detection accuracy, response latency or recovery time. A pilot needs an agreed owner, support schedule, containment authority, escalation route, change control and exit procedure.

## Commercial definitions

Prices are proposals. Protected people are monitored human identities, not administrator dashboard seats. Endpoints are supported enrolled devices/servers. AI agents are registered production agent identities, not token counts or model requests. Ephemeral infrastructure, test identities and service accounts need explicit treatment. Telemetry volume, AI usage, hot retention, archive retrieval, support and overages remain to be agreed before sale.

## Due-diligence checklist

Confirm production connector availability; exact read/write scopes; policy bypass routes; identity and tenant boundaries; signed update chain; detection evaluations/false-positive evidence; input provenance; fail-open/fail-closed decisions; approval binding; rate limits; audit integrity; retention tests; backup restoration tests; independent security assessment; actual contract and operator.

## Website limitations

The demo can be explored without an account. It is entirely local and makes no model requests. There are no fake customer endorsements, product benchmarks or certification claims. The request form remains disabled when operator, privacy, D1 storage or notification configuration is incomplete. Submission stores a website enquiry only; it never activates protection.

## V3 website release

The scorpion identity, interactive evidence story, governor concept, console screenshots and responsive design are website presentation features. They do not change platform capability status. OmniFlow, endpoint coverage and response integration require separate engineering validation.