OMNIX Book a consultation

trust · governance · operational safety

Built for secureoperational intelligence.

Omnix is designed with enterprise security, governance, access control, and operational safeguards for teams connecting critical engineering systems.

Book a consultation with your Omnix product specialist Explore the platform

01 · principles

Security principles for connected engineering systems.

Omnix connects sensitive operational signals across delivery, infrastructure, security, and automation. The platform is designed around four operational principles, applied consistently across surfaces.

  • Data protection

    Operational data is handled with encryption in transit and at rest, scoped storage, and controlled access across the platform.

  • Access control

    Scoped permissions, role-based access, and least-privilege boundaries govern who can see and act on operational context.

  • Operational governance

    Approvals, ownership, action history, and policy boundaries stay visible across workflows, integrations, and operational change.

  • AI oversight

    AI-assisted reasoning and automation are designed to operate inside approval, ownership, and policy boundaries set by your organisation.

02 · data protection

Protect operational context across connected systems.

Omnix connects sensitive engineering signals from delivery, operations, infrastructure, security, and automation systems. Data handling is designed to be controlled, scoped, and transparent.

  • Encryption in transit

    Traffic between Omnix and connected systems is protected with modern TLS, terminated at the platform edge.

  • Encryption at rest

    Operational signals and platform state are stored with at-rest encryption on managed infrastructure.

  • Tenant isolation

    Each customer organisation is isolated at the data layer so operational context cannot cross tenant boundaries.

  • Scoped ingestion

    Integrations are designed to read only what they are authorised for, with narrower scopes preferred where the upstream tool supports them.

  • Data minimisation

    Where operational meaning can be derived without persisting raw payloads, the platform is designed to keep only what is needed.

  • Regional defaults

    EU infrastructure by default. Region selection and customer-specific deployment are part of enterprise conversations.

03 · identity & access

Control who can see and act.

Operational intelligence becomes more powerful when access is governed by role, scope, and responsibility. Omnix is designed around least-privilege as the default, not the upgrade.

  • Role-based access

    Roles map to operational responsibility so engineers, security, and platform owners see and act on the surfaces that match their work.

  • Scoped product and team access

    Access can be scoped to products, services, and teams, so visibility and action follow organisational boundaries.

  • Least privilege by default

    Access starts narrow. Broader privileges are granted intentionally, not inherited as a side effect of being on the platform.

  • Administrative controls

    Workspace administrators manage membership, role assignment, and access scope from a single operational surface.

  • Enterprise identity

    Enterprise identity such as SSO, SAML, and OIDC is supported as part of enterprise deployment, with directory mapping discussed during rollout.

  • Permission boundaries

    Sensitive surfaces, actions, and integrations sit behind explicit permission boundaries that survive role changes and reorgs.

04 · secure integrations

Secure connections to the tools your teams already use.

Omnix integrates with engineering, observability, incident, security, cloud, and delivery systems. Integrations are designed to be scoped, auditable, and permission-aware, not all-or-nothing.

  • Scoped tokens

    Where the upstream tool supports it, Omnix is designed to request the narrowest scope that satisfies the integration.

  • Least-privilege access

    Integration credentials are configured for the minimum surface area required, not the convenience of broad permissions.

  • Secure credential handling

    Integration secrets are stored encrypted, accessed only by the components that need them, and rotated on customer request.

  • Read-only by default

    Most integrations begin as read-only ingestion. Action-capable connections are an explicit, separately governed decision.

  • Integration audit visibility

    Connection history, scope, and activity are visible to administrators so the integration surface stays legible over time.

  • Reversible by design

    Integrations can be revoked at any time. Disconnection is a first-class operation, not a hidden support ticket.

05 · operational governance

Govern operational action.

Operational intelligence does not stop at visibility. When workflows, runbooks, automation, and agent teams act across systems, governance matters as much as the action itself.

  • Approval workflows

    Sensitive operational actions can require explicit human approval before they execute, with approval state attached to the action record.

  • Action history

    Every action initiated through Omnix produces a durable record of what ran, who authorised it, and which systems it touched.

  • Policy boundaries

    Workflows, automation, and agent teams operate inside organisational policy. The platform is designed so policy is enforceable, not advisory.

  • Escalation paths

    When automated handling reaches the limit of its authority, the next responsible owner is part of the operational picture, not a search exercise.

  • Human-in-the-loop

    Higher-impact operational change is designed to keep an accountable human on the loop, with context, options, and the audit trail in one place.

  • Controlled automation

    Automation runs against the systems it is permitted to touch. Scope, ownership, and approval state govern execution, not convenience.

06 · AI governance

AI systems need operational boundaries.

Omnix AI is designed to operate with context, controls, and oversight. AI-assisted recommendations and workflows are designed to respect ownership, approvals, permissions, and operational policies, the same way the rest of the platform does.

  • Human oversight

    AI-assisted recommendations and actions are designed to surface for review, not to act unilaterally on sensitive operational change.

  • Governed execution

    When AI does take action, it operates inside the same approval, ownership, and policy boundaries that govern human-initiated work.

  • Approval-aware workflows

    AI suggestions follow the approval graph for the operation, not a parallel one. Sensitive steps wait for the people accountable for them.

  • Restricted action scopes

    AI capabilities are bounded by the same scoped tokens, permissions, and integration surfaces that bound the rest of the platform.

  • Auditable reasoning

    AI-initiated actions, recommendations, and the operational context behind them are recorded so review is possible after the fact.

  • Operational transparency

    Where AI participated in an operational decision, the participation is visible, attributable, and queryable, not hidden inside the result.

07 · auditability

Trace decisions, actions, and operational changes.

Operational platforms need clear visibility into who changed what, what was recommended, what was approved, and what action occurred. Audit is designed in, not bolted on.

  • Audit logs

    Platform events, configuration changes, and operational actions are recorded with actor, timestamp, and context.

  • Action history

    Workflow runs, automation steps, and agent executions produce a durable trail that survives restarts and ownership changes.

  • Approval records

    Approvals, denials, and escalations are part of the action record so accountability stays attached to the decision.

  • Integration activity

    Inbound ingestion and outbound actions across integrations are observable so the integration surface remains legible.

  • Workflow execution traces

    Each step of a workflow or runbook is recorded with inputs, outcome, and the operational context that drove it.

  • Operational accountability

    The audit picture is designed to answer the operational questions reviewers actually ask, not to produce volume.

09 · the line

What we do, what we don't.

Plain language, no security theatre. Where something is in flight, we say so.

What we do

  • Encrypt operational data in transit (TLS) and at rest
  • Use scoped, permission-aware integrations and prefer narrower scopes where they exist
  • Run on EU infrastructure by default, with regional options on enterprise
  • Publish every sub-processor we use, with purpose and region
  • Respond to security disclosures within 48 hours
  • Honour data deletion and access requests on enterprise terms

What we don't

  • Train models on your data, ever, in any way
  • Sell, share, or rent operational data to third parties
  • Claim certifications we have not earned
  • Use dark-pattern consent flows or hidden trackers
  • Run sensitive AI inference outside agreed regions on enterprise plans
  • Request broader integration permissions than the integration needs

sub-processors

Who sees what, where.

Every third party that touches your data, listed with purpose and region. Updated when the list changes.

Sub-processor Purpose Region
Vercel Application hosting and CDN EU
Resend Transactional and audience email EU
Upstash Rate-limit storage (hashed IPs only) EU
PostHog Product analytics (opt-in, EU instance) EU

found something?

Tell us. We'll act fast.

Responsible disclosure to security@getomnix.app. We aim to acknowledge within 48 hours and fix or mitigate within 7 days for serious issues.

08 · enterprise readiness

Designed for enterprise security review.

Omnix is built to support the security, privacy, and governance expectations of modern engineering organisations. Compliance posture and formal certification efforts are part of enterprise conversations.

  • Security review support

    We engage with enterprise security review processes, including questionnaires, architecture review, and integration scope review.

  • Data processing questions

    Data handling, regions, retention, and processing scope are documented for legal and privacy review during evaluation.

  • Deployment architecture review

    Tenant isolation, infrastructure region, and integration topology are reviewable so security teams can evaluate the operational surface.

  • Integration permission review

    Each integration scope, what it reads, and what it can act on, is reviewable so enterprise teams can evaluate the connected surface.

  • Enterprise access controls

    Identity, scoped access, and administrative controls are configured during enterprise rollout to match organisational structure.

  • Compliance conversations

    Compliance readiness and formal certification efforts are discussed openly during enterprise evaluation. We do not claim certifications we do not hold.

talk to us about security

Security and governance for operational intelligence.

Omnix helps engineering organisations connect systems, understand operations, and coordinate action with the control and visibility enterprise teams expect. Tell us your team and we will send the documents and a personal answer to anything specific.
  • Read-only access. We never push, comment, or merge.
  • SOC 2 Type II in progress. Audit period H2 2026.
  • Code stays in your VCS. We read metadata, not your repo contents.