Security

1. Governance and compliance

Read this section before the rest of the page. It sets the honest ceiling on everything that follows: OmniLink holds no security certification of its own, and no independent party has audited or tested this platform.

1.1 Frameworks we use as a checklist

We design against published control sets rather than inventing our own — principally the OWASP Application Security Verification Standard, the OWASP API Top 10, and the OWASP LLM Top 10 for software security, and GDPR, UK GDPR, and CCPA for personal data. We use them as a reference for what to build, not as a claim of conformance: nobody has assessed us against them.

1.2 Compliance status

OmniLink itself is not certified against any security standard. There is no SOC 2 report, no ISO 27001 certificate, and no third-party penetration test — so there is nothing of that kind for us to send you, and we would rather say that here than in week one of your review. What is independently audited is the infrastructure underneath us: Google Cloud Run holds SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, and PCI DSS attestations, and Supabase’s underlying AWS infrastructure carries comparable certifications. We are happy to answer a security questionnaire directly, and to name every subprocessor we use — write to security@omnilinktechnology.com.

1.3 Use of the Services for regulated data

OmniLink is not currently HIPAA-compliant and the Services must not be used to process protected health information. OmniLink does not store cardholder data; all payment processing is handled by Stripe, which is PCI DSS Level 1 certified. Customers in regulated industries should perform their own assessment and contact us if a specific compliance posture is required.

2. Tenant isolation and identity

2.1 Logical multi-tenancy

OmniLink is a logically multi-tenant SaaS platform. Every record is owned by a user id, and isolation is enforced in two places. Requests the browser makes directly to Postgres run under the signed-in user’s own session and are policed by Postgres row-level security policies, so the database itself refuses to return another account’s rows. The API service is different, and worth being precise about: it holds a service credential and therefore can read across accounts — it has to, to run your agent while you are offline. On that path isolation is enforced by the API resolving your Omni Key to exactly one user id and scoping every query to it. So a compromise of the API service is a tenancy-boundary compromise; row-level security is the second line, not a guarantee that survives it.

2.2 Authentication

User authentication is handled by Supabase Auth. Customers can sign in with email and password, or with Google as a third-party identity provider. Session tokens are short-lived JWTs managed by the Supabase client library and held in browser storage. Multi-factor authentication for customer accounts is not offered today.

2.3 Authorization

OmniLink accounts are single-user today: the account owner holds all rights over their own Omni Keys, billing, and agents, and PostgreSQL row-level security isolates every record by user. Team workspaces and role-based access control are roadmap items and are not available yet. The principle of least privilege is applied to OmniLink’s internal access model.

2.4 Internal access

OmniLink personnel access production systems only when required to operate, support, or secure the Services. Production secrets live in Google Secret Manager and are injected into the running service rather than held by individuals, deploys run through a Google Cloud workload identity federation rather than a long-lived key, and cloud provider access is protected by multi-factor authentication. We do not operate a centralized identity provider, just-in-time privilege elevation, or session recording for administrative access; those are things a larger operation would have and we do not.

3. Infrastructure security

3.1 Hosting

The OmniLink API and static frontend run on Google Cloud Run in hardened container images. Cloud Run provides automatic scaling, isolated per-request execution, and managed network and DDoS protections. The managed Postgres database, file storage, and authentication services run on Supabase, which is hosted on AWS infrastructure with the corresponding cloud provider certifications.

3.2 Hardening

The container image is built from a minimal Alpine base, installs dependencies with package install scripts disabled, runs as a non-root user, and is rebuilt from scratch on every deploy. Process and network isolation are provided by Cloud Run’s second-generation execution environment. We do not run our own image-vulnerability scanner over it.

3.3 Secrets management

Production secrets (database credentials, third-party API keys, signing keys) are stored in a managed secrets store, rotated regularly, and injected at runtime. Secrets never appear in source code, in client bundles, or in logs.

3.4 Change management

Every production change is a commit on main, which builds a container image and deploys it to Cloud Run. Each deployed revision is immutable and traceable to the commit that produced it, and rolling back means pointing traffic at the previous revision. Be clear about what this is not: the deploy pipeline does not currently gate on the test suite, linting, type checking, or a dependency scan. Those run against the codebase during development, but a change that fails them is not automatically blocked from shipping.

4. Network security

4.1 Encryption in transit

All public traffic to the Services is encrypted in transit using TLS 1.2 or later with modern cipher suites. HTTP connections are redirected to HTTPS. Internal traffic between managed services uses provider-encrypted networks. We publish HTTP Strict Transport Security (HSTS) headers, and we recommend certificate pinning for mobile applications.

4.2 Network boundary

The API is exposed only through Cloud Run’s managed ingress with provider-level DDoS protection. Database access is restricted to managed networks and authorized service accounts. Administrative interfaces are not exposed to the public internet.

4.3 Rate limiting and abuse prevention

Sliding-window rate limits are enforced server-side per account and per endpoint: a per-plan request rate at the chat front door, a durable per-account window computed in the database, and tighter per-endpoint ceilings on costly routes such as speech-to-text and text-to-speech. Sustained overuse is met with 429 Too Many Requests and a Retry-After header. Suspected abuse can be met with throttling or suspension.

4.4 CORS

Cross-Origin Resource Sharing rules are configured to support legitimate browser, mobile, and local-development clients while preventing token exfiltration. Customers are expected to call the API from server-side proxies in production rather than directly from browsers.

5. Application security

5.1 How changes get reviewed

Changes that touch authentication, tenant isolation, credential handling, or the tool surface get a deliberate security read before they ship, and the code carries that reasoning inline so the next person changing it inherits it. That is a review practice, not an automated one: there is no static-analysis or dependency-scanning stage wired into the deploy pipeline (see § 3.4), and no external pre-release verification.

5.2 Defences we implement by default

• Input validation and structured parsing for all API-accepted payloads.
• Output encoding and Content Security Policy headers to mitigate cross-site scripting.
• A strict cross-origin allow-list, so the API answers browser requests only from our own origins and localhost — not from an arbitrary page that has stolen a credential.
• Authenticated writes carry a bearer Omni Key rather than an ambient cookie, so a cross-site request cannot ride the user’s browser session.
• AES-256-GCM encryption at rest for every model-provider credential you give us, with the encryption key held in Google Secret Manager and never in the database (§ 7.2). Omni Keys themselves are not hashed — see § 7.1 for exactly what that means.
• Server-side authorization checks on every endpoint, not just at the UI layer, backed by PostgreSQL row-level security underneath.
• Strict deserialization, schema validation, and size limits on payloads that can reach AI providers or tools.

5.3 LLM-specific controls

Because OmniLink agents accept untrusted text and invoke tools, we treat prompts as a security boundary. We use structured tool definitions with explicit argument schemas, allow-listed actions per agent, output filters where appropriate, and prompt-injection mitigations such as delimited system messages. Customers can further restrict tool surface area per agent, and the local runtime is where the real boundary sits — a tool the runtime does not expose is one no prompt can reach (§ 8).

6. Data protection

6.1 Encryption at rest

All customer data stored in the managed database and file storage is encrypted at rest by the provider using AES-256 or equivalent, with keys the provider manages, rotates, and never exposes to us. That is volume-level protection: it defends the disk, not a query. Exactly one class of data gets a second, application-level layer on top — your model-provider credentials, encrypted with a key of our own before the row is written, so that reading the database is not enough to read them (§ 7.2). Everything else is protected by access control, not by a second cipher.

6.2 What we store and where

6.3 Backups

The production database is backed up by Supabase, our managed Postgres provider, under their backup and point-in-time recovery schedule. Backups are encrypted and subject to the same access controls as production data. We have not run a restoration drill, so treat recovery time as untested rather than measured.

6.4 Deletion and retention

From the Dashboard you can delete an agent profile, delete a conversation and every message in it, clear an agent’s short-term memory, delete a stored model-provider credential, and revoke an Omni Key. Deletion removes the row from primary storage immediately; it ages out of database backups as those backups roll over.

There is no self-serve “delete my account” button and no self-serve data export today. To have an account and everything in it deleted, or to get an export of your data, email privacy@omnilinktechnology.com from the address on the account; we handle those by hand.

Each plan also names a retention window for conversation history and run history (30 days on Free through to unlimited on Agent Lord). A scheduled sweep implements those windows, but it is currently running in report-only mode: nothing is being deleted by it yet, and we will announce a date before enforcement begins. Until then, assume history is retained.

7. Omni Key and credential management

Two different secrets are involved and they are protected differently. Read both.

7.1 Omni Keys — stored as the key value, not hashed

Omni Keys are the authentication credential for the OmniLink API. They are prefixed with olink_ and cryptographically random (24 random bytes). They are stored in our database as the key value itself — not as a hash. That is a real limitation and we would rather you learn it here than from a breach notice: anyone who could read the database could read your Omni Keys, and unlike a hashed credential we cannot rule that out for you by construction. In practical terms it also means the Dashboard can show you a key again later, which is why there is a “copy full key” button rather than a one-time-reveal. Moving to hashed storage is on our list; it is not done.

What is true of Omni Keys today: they travel only over TLS, they are scoped to a single account and can act only on that account’s data, they are redacted from logs, they are rate-limited per key, and they can be revoked at any time from the Dashboard. Revoked keys are invalidated instantly and subsequent requests using them are rejected. The Dashboard shows per-key usage so unusual activity is visible. Customers are expected to:

• Keep Omni Keys server-side — never embed them in browser bundles, mobile apps, or public repositories.
• Use environment variables or a secret manager for production deployments.
• Rotate keys regularly and immediately if compromise is suspected; the rotation flow supports zero-downtime transitions.
• Hold no more keys than you are using — each account is capped at ten active keys.

7.2 Model-provider credentials — encrypted at rest

OmniLink is bring-your-own-key: to run inference you give us an API key for the model provider you chose (Google, OpenAI, Anthropic, xAI, or OpenRouter), or a Google service-account JSON where the provider requires one — and that JSON contains a private key. We store these server-side, because the platform has to be able to call the provider on your behalf when your agent wakes up and you are not there.

They are encrypted at the application layer with AES-256-GCM before they are written, using a key that lives in Google Secret Manager and is injected into the running service — so the ciphertext in the database is not decryptable with database access alone. If that encryption key is not configured the platform refuses to store the credential rather than falling back to plaintext. A stored credential is used only to call the provider you attached it to, is never returned to the browser or included in an API response (the Dashboard shows only that one exists), is never written to logs, and is never sent to any other provider. You can delete it from the Dashboard at any time, and you can revoke it at the provider without involving us at all.

8. Local-runtime security

The OmniLink Python library and HTTP bridge execute on customer-owned hardware. They are designed to bind to 127.0.0.1 by default, accept bearer-token authentication when exposed, and isolate tool execution from credentials needed only by the cloud.

8.1 Recommended deployment patterns

• Keep the HTTP bridge bound to localhost unless you have a specific need to expose it; require authentication and TLS otherwise.
• Place the bridge behind a reverse proxy with TLS and IP allow-lists for multi-device deployments.
• Run the runtime under a dedicated user account with the minimum permissions needed to perform its tools.
• Sandbox dangerous tools (shell execution, file I/O, network calls) and validate every argument the agent supplies.

8.2 Supply chain

Be precise about this one, because it is the kind of claim that gets overstated: the omnilink Python package is built and uploaded to PyPI by a maintainer running a release script locally, authenticated with a PyPI API token. It is not cryptographically signed, and it is not published from a hardened CI pipeline. Pin versions, check the version you install is the one you meant to install, and keep dependencies up to date. Report any suspected supply-chain anomalies to security@omnilinktechnology.com.

9. AI provider integration

Inference requests are forwarded to the AI provider you select for each agent over authenticated, encrypted channels, authenticated with your provider key. We send only the prompt material required to run the request — system prompt, user message, tool definitions, recent conversation turns — and never your Omni Key, billing data, or another account’s data.

Because the call is made on your key, the relationship that governs that content is between you and the provider: their terms, their retention, their training policy, and their decisions about your account apply to it, and you can see and control it from your own provider console. We do not hold a separate enterprise agreement with these providers that overrides their default API terms on your behalf. Most providers exclude API inputs and outputs from model training by default; check the policy of the provider you pick rather than taking our word for it. We rely on each provider’s safety filters, and customers remain responsible for ensuring that the content they submit complies with the chosen provider’s usage policies.

10. Logging, monitoring, and detection

10.1 Telemetry

The Services emit structured logs for requests, errors, authentication events, and administrative actions, and a per-request usage record for each API call. Secret values — Omni Keys, passwords, provider credentials, access tokens — are never passed to a log statement in the first place; a key appears in an audit line only as a reference to the row that holds it, never as the value.

10.2 Detection

Abuse controls that run automatically: per-key and per-endpoint rate limiting, per-account ceilings on keys, credentials and agent profiles, and a failure counter that puts a repeatedly-failing provider credential into cooldown. Beyond those, monitoring is Google Cloud’s and Supabase’s own tooling plus human review of logs. We do not run a SIEM, a managed detection service, or a 24/7 security on-call rota, and you should not assume an out-of-hours alert reaches someone within minutes.

10.3 Audit logs

OmniLink does not currently provide a general customer-facing audit log. Omni Key usage — per-engine call counts and cost — is visible in the Dashboard, and internal administrative actions on customer data are logged server-side. A fuller customer-facing audit trail is a roadmap item.

11. Vulnerability management

11.1 Scanning

We do not currently run automated vulnerability scanning — there is no scheduled dependency scanner, no static analysis service, and no image scanner wired into the build. What we do have is a small dependency footprint that is reviewed by hand when it changes, and a container rebuilt from a current base image on every deploy. Automating this is a known gap, and it is the next thing on this page we intend to be able to rewrite.

11.2 Third-party testing

No third party has penetration-tested the Services. There is no report, no executive summary, and nothing to share under NDA. If an independent test is a requirement for you, tell us — that is useful signal and we would rather hear it than have you assume one exists.

11.3 Patch management

Operating-system and platform patches are applied by our managed providers: Cloud Run patches the host and sandbox, Supabase patches Postgres. Our own base image and application dependencies are updated when we deploy, and security-relevant updates are prioritized.

12. Personnel security

OmniLink is operated by a very small team, and the honest version of this section is short. Access to production is limited to the people who run the platform, and is protected by multi-factor authentication at the cloud provider. Confidentiality obligations apply to anyone working on it.

What we do not have, and will not claim: background screening, a formal onboarding and annual security-training curriculum, phishing simulations, incident-response drills, a centralized identity provider with role-based provisioning and just-in-time elevation, or a managed device fleet with enforced endpoint baselines. Those are controls a larger organization runs, and an enterprise buyer should price the gap in rather than discover it during diligence.

13. Vendor and subprocessor risk

Vendors with access to customer data, including the subprocessors listed in the Privacy Policy, are reviewed before onboarding and on a recurring schedule. The review covers their security posture, certifications, data-handling practices, sub-processing relationships, and contractual safeguards. We maintain a subprocessor list and notify customers of material additions before they take effect, where required.

14. Incident response

14.1 Process

A documented incident-response plan governs how we detect, triage, contain, eradicate, and recover from security incidents. The plan defines severity tiers, escalation paths, communication responsibilities, evidence handling, and post-incident review. It has not yet been exercised through a tabletop or live drill.

14.2 Notification

If a security incident affects your data, we will notify you without undue delay and in line with applicable breach-notification laws. Notifications include what we know about the incident, the categories of data affected, the steps we have taken, and recommendations for action on your side.

14.3 Reporting an incident

If you suspect a security incident on your side that may affect OmniLink, contact security@omnilinktechnology.com immediately and, where appropriate, rotate any potentially exposed Omni Keys.

15. Business continuity and disaster recovery

OmniLink runs as a single Cloud Run service in one region (europe-west1) against a single managed Supabase project. There is no multi-region deployment and no automatic cross-region failover: a regional outage at either provider is an outage for us. What resilience there is comes from the managed platforms themselves:

• Compute is stateless and autoscaling, so load shifts freely between healthy instances and a failed instance is replaced rather than repaired.
• The database is managed by Supabase, with their backup and point-in-time recovery schedule behind it.
• Deploys are immutable revisions, so recovering from a bad release means routing traffic back to the previous one.

We have not published recovery time or recovery point objectives, and we have not exercised a restoration or failover scenario — so we are not going to quote you a number for either. We notify customers of significant disruptions. A public status page is a roadmap item and is not live yet.

16. Shared-responsibility model

Security is a partnership. We secure the OmniLink platform. You secure how you use it. The table below outlines who is responsible for each layer.

17. Responsible disclosure

We welcome security research on the Services. If you believe you have found a vulnerability, please report it to security@omnilinktechnology.com with enough detail for us to reproduce and triage it. While investigating you agree to:

• Test only against accounts you own or have explicit permission to test.
• Avoid privacy violations, destruction of data, and disruption of the Services.
• Refrain from social engineering, denial-of-service testing against shared infrastructure, or physical attacks against OmniLink or its providers.
• Give us a reasonable period to investigate and remediate before any public disclosure.

In return we will acknowledge your report promptly, keep you informed of progress, and, at our discretion, recognize meaningful reports through our hall of fame or other rewards. We will not pursue legal action against good-faith security research conducted in line with this policy.

18. Contact and documentation requests

For security questionnaires, the named subprocessor list, the Data Processing Addendum, account deletion or data export, or any question this page did not answer, contact us. There are no audit reports or penetration-test summaries to request — see § 1.2 and § 11.2.

Security inquiries and incident reports

security@omnilinktechnology.com

Privacy and data subject requests

privacy@omnilinktechnology.com

Legal and contracting

legal@omnilinktechnology.com

For implementation-level guidance on securing agents you build with OmniLink — key storage, HTTPS, CORS, deployment checklists — the practical material lives with the open-source simulator and its guides at OmniSim.