Security

1. Governance and compliance

A documented information security program governs how we design, build, operate, and review the Services. The program is owned by leadership and reviewed at least annually, with continuous improvement driven by risk assessments, audit findings, and operational learning.

1.1 Frameworks we align with

• ISO/IEC 27001 and ISO/IEC 27017 for information security management and cloud security.
• SOC 2 Trust Services Criteria for security, availability, confidentiality, and privacy.
• The NIST Cybersecurity Framework and NIST SP 800-53 control families for risk-based control selection.
• OWASP Application Security Verification Standard, OWASP API Top 10, and the OWASP LLM Top 10 for software security.
• GDPR, UK GDPR, and CCPA for personal data and privacy controls.

1.2 Compliance status

OmniLink’s upstream cloud providers are independently audited — 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. OmniLink is preparing its own SOC 2 Type II report; in the interim, customers may request a security questionnaire response, a current penetration-test summary, and a list of named subprocessors by writing 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. Customer data is segregated by Postgres row-level security policies enforced at the database layer, so a workspace can only read and write rows that belong to it. Application-layer code authenticates and authorizes every request against those policies; even a compromised application instance cannot bypass tenancy boundaries.

2.2 Authentication

User authentication is handled by Supabase Auth. Customers can sign in with email and password, with optional multi-factor authentication, or with supported third-party identity providers. Session tokens are short-lived JWTs; refresh tokens are stored in httpOnly cookies to prevent extraction via cross-site scripting.

2.3 Authorization

Workspace-level role-based access control governs who can create or revoke Omni Keys, manage billing, modify agents, and view audit logs. The principle of least privilege is applied in both customer-facing roles and 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 access is gated by single sign-on with phishing- resistant multi-factor authentication, just-in-time privileged access requests for sensitive operations, and full session logging.

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

Container images are built from minimal base images, scanned for known vulnerabilities, and rebuilt on every code or dependency change. Runtime environments are configured with read-only file systems where practical, non-root execution, dropped Linux capabilities, and constrained egress.

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

All production changes are delivered through code review and continuous integration. Pipelines run linting, type checking, unit and integration tests, dependency scanning, and static analysis before a change can be deployed. Deployments are reversible and traceable to the corresponding source commit.

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

Token-bucket rate limits are enforced per Omni Key and per endpoint. Costly endpoints, such as speech-to-text and text-to-speech, have lower thresholds. Sustained overuse is met with 429 Too Many Requests and a Retry-After header. Suspected abuse triggers additional verification, 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 Secure development lifecycle

We follow a secure software development lifecycle that includes threat modelling for new features, security review of designs that touch authentication, data isolation, or tooling, mandatory code review, static and dynamic analysis in CI, dependency scanning, and 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.
• Anti-CSRF protections for state-changing browser requests, including SameSite cookie attributes.
• Constant-time comparison and salted hashing for credentials, including a salted hash of every Omni Key.
• Server-side authorization checks on every endpoint, not just at the UI layer.
• Replay-resistant signed URLs for file downloads and short-lived upload tokens.
• 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 and source-attributed retrieval. Customers can further restrict tool surface area at the workspace level.

6. Data protection

6.1 Encryption at rest

All customer data stored in the managed database and file storage is encrypted at rest using AES-256 or equivalent. Encryption keys are managed by the cloud providers, rotated on the provider’s schedule, and never exposed to the application layer.

6.2 What we store and where

6.3 Backups

Production databases are backed up continuously by the managed provider with point-in-time recovery for a defined window. Backups are encrypted, geographically redundant, and subject to the same access controls as production data. Restoration procedures are exercised periodically.

6.4 Deletion

Customers can delete agents, memory entries, knowledge files, and entire workspaces from the Dashboard. Following a delete, content is removed from primary storage promptly and from backups as those backups age out of the retention window.

7. Omni Key and credential management

Omni Keys are the primary authentication credential for the OmniLink API. They are prefixed with omk_, cryptographically random, shown exactly once at creation, and stored only as a salted hash. 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.
• Restrict the scope of each key to the smallest set of workloads that need it.

Revoked keys are invalidated instantly; subsequent requests using them return 401 Unauthorized. The Dashboard provides per-key usage statistics so you can spot unusual activity quickly.

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

OmniLink-distributed packages are signed and published from locked-down release pipelines. Verify package integrity when installing from PyPI or other registries, 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. We send only the prompt material required to run the request — system prompt, user message, tool definitions, relevant memory or knowledge passages, and prior conversation turns — and never your Omni Key, billing data, or unrelated workspace data.

Where a provider supports opting out of training on customer inputs and outputs, we contractually exercise that option. We also rely on each provider’s safety filters and report abusive activity to them where appropriate. 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, metrics, and traces for requests, errors, authentication events, and administrative actions. Sensitive values such as Omni Keys, passwords, and access tokens are redacted before logs are written.

10.2 Detection

We monitor for indicators of compromise, anomalous usage, and policy violations using a combination of provider-native security tooling, custom detections, and human review. Suspicious patterns trigger automated mitigations such as additional rate limiting, challenge prompts, or temporary suspension, and route alerts to the on-call security team.

10.3 Audit logs

Customer-facing audit logs are available in the Dashboard for workspace administrators. They capture authentication events, key creation and revocation, billing changes, and significant configuration changes. Internal administrative actions on customer data are also logged.

11. Vulnerability management

11.1 Continuous scanning

We scan our source code, container images, and runtime dependencies for known vulnerabilities on every commit and on a recurring schedule. Findings are triaged against agreed service-level objectives, with the most severe issues remediated on an expedited timeline.

11.2 Third-party testing

We engage qualified third parties to perform penetration testing of the Services. Findings are tracked to closure; executive summaries are available to customers under mutual non-disclosure on request.

11.3 Patch management

Operating-system and platform patches are applied by our managed providers. Application dependencies are updated continuously, and security-relevant updates are prioritized. We track the public end-of-life dates of major runtimes and plan upgrades accordingly.

12. Personnel security

• Background checks for personnel with access to production systems, where permitted by law.
• Confidentiality and acceptable-use agreements as a condition of employment.
• Mandatory security and privacy training at onboarding and annually thereafter, plus targeted training for roles with elevated access (engineering, support, finance).
• Phishing simulations and incident-response drills.
• Provisioning and prompt deprovisioning of access using a centralized identity provider, role-based access controls, and just-in-time elevation for sensitive operations.
• Mandatory device security baselines: full-disk encryption, screen-lock policies, endpoint protection, and managed patching.

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 is exercised through tabletop and live drills.

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 on managed, regionally redundant infrastructure with automatic failover capabilities. We:

• Use stateless, autoscaling compute so request load can shift quickly between healthy instances.
• Rely on a managed database with point-in-time recovery, replicated storage, and tested restoration procedures.
• Maintain a documented business-continuity plan with recovery time and recovery point objectives appropriate for each component.
• Exercise restoration and failover scenarios periodically and track the results.

The current status of the Services is published on our status page. We notify customers of significant disruptions and post post-incident reports for major outages.

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 and workspaces 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, audit reports, penetration-test summaries, the subprocessor list, the Data Processing Addendum, or other security documentation, contact us:

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 — see the Security chapter in the documentation.