Security

Omni Key Security

Every request to the OmniLink API is authenticated with an Omni Key — a secret token prefixed with omk_. The key is passed as a Bearer token in the Authorization header.

Key Generation

Generate your Omni Key with one click:

Get your Omni Key →

Each key is a cryptographically random string that is shown exactly once at creation time. OmniLink stores only a salted hash of the key, so it cannot be recovered if lost.

Storage Best Practices

• Never hardcode keys in source files, commits, or client-side code.
• Use environment variables for all deployments:

# Set the environment variable
export OMNI_KEY="omk_your_key_here"

# Access in Python
import os
key = os.environ["OMNI_KEY"]

# Access in Node.js
const key = process.env.OMNI_KEY;

• For containerized deployments, use secrets managers such as Docker Secrets, Kubernetes Secrets, AWS Secrets Manager, or Vault.
• Add .env to your .gitignore to prevent accidental commits.

Key Rotation

Rotate your Omni Key periodically or immediately if you suspect it has been compromised. The rotation process:

1. Generate a new key in the Dashboard.
2. Update your environment variables and secrets managers.
3. Deploy the updated configuration.
4. Revoke the old key in the Dashboard.

Both keys remain active during the transition window, so there is no downtime.

Key Revocation

Revoke a key instantly from the Dashboard. Once revoked, all requests using that key return 401 Unauthorized. Revocation is immediate and irreversible.

Client-Side Security

Never expose your Omni Key in client-side code. Browser JavaScript, mobile app bundles, and public repositories are all considered client-side. Anyone who obtains your key can make API calls on your behalf.

Recommended Architecture

Use a backend proxy to keep the key server-side:

// ❌ WRONG: Key exposed in browser code
await fetch("https://www.omnilink-agents.com/api/chat", {
  method: "POST",
  headers: { Authorization: "Bearer omk_abc123" }, // Anyone can see this
  body: JSON.stringify({ message: userInput }),
});

// ✅ CORRECT: Proxy through your backend
// Frontend calls your API
const response = await fetch("/api/my-proxy/chat", {
  method: "POST",
  body: JSON.stringify({ message: userInput }),
});

// Backend (server-side) holds the key and forwards to OmniLink
await fetch("https://www.omnilink-agents.com/api/chat", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.OMNI_KEY}` },
  body: JSON.stringify({ message: userInput }),
});

HTTPS Enforcement

All communication with the OmniLink API is conducted over HTTPS. The platform enforces TLS 1.2 or later. HTTP requests are rejected with a 301 redirect to the HTTPS equivalent.

• API base URL: https://www.omnilink-agents.com
• All tokens, payloads, and responses are encrypted in transit.
• Certificate pinning is recommended for mobile applications.

CORS Policies

The OmniLink API applies the following Cross-Origin Resource Sharing (CORS) rules:

If you encounter CORS errors, verify that your request includes the correct Origin header and that you are using HTTPS in production. See the FAQ for detailed troubleshooting.

Authentication

Supabase Authentication

The OmniLink Dashboard uses Supabase for user authentication. Two authentication methods are supported:

• Email and password — Standard credential-based login with email verification.
• Session tokens — JWT-based session management with automatic refresh.

Session tokens are short-lived (1 hour) and automatically refreshed by the client SDK. Refresh tokens are stored in httpOnly cookies to prevent XSS extraction.

Row-Level Security

All data in OmniLink is isolated per user using Supabase row-level security (RLS) policies. This means:

• User A cannot read or write User B’s agent profiles.
• Memory entries are scoped to the owning user and agent.
• Knowledge base files are isolated per account.
• Usage records are visible only to the account that generated them.

RLS policies are enforced at the database level, not the application level, so even a compromised API server cannot bypass data isolation.

HTTP REST API Security

The HTTP REST API is designed for local and edge deployments. Follow these guidelines to secure API communication:

Authentication

# Set an API key for the agent HTTP server
export OMNI_API_KEY="your-secret-api-key"

# Clients must include the key in every request
curl -H "Authorization: Bearer your-secret-api-key" \
  http://localhost:8080/command

HTTPS for Production

For any deployment beyond localhost, enable HTTPS using a reverse proxy or the built-in TLS option:

# Option 1: Built-in TLS
export OMNI_TLS_CERT="/etc/omnilink/certs/server.crt"
export OMNI_TLS_KEY="/etc/omnilink/certs/server.key"

# Option 2: Nginx reverse proxy (recommended)
# See your Nginx docs for ssl_certificate configuration

• Use HTTPS (port 443) instead of plain HTTP for all production traffic.
• Include an Authorization header (Bearer token or Basic auth) with every request.
• Restrict endpoint access with role-based permissions so each agent can only access its own resources.

Bridge Security

The HTTP bridge accepts a bind address. The default is localhost, which limits access to the local machine.

Localhost vs. 0.0.0.0

If you bind to 0.0.0.0, you must implement additional access controls:

• Place the bridge behind a reverse proxy (e.g., Nginx) with TLS.
• Use firewall rules to restrict which IPs can connect.
• Add authentication middleware to the HTTP bridge.

# Binding to all interfaces (use with caution)
bridge = OmniLinkHTTPBridge(engine, host="0.0.0.0", port=8080)

# Safer: bind to localhost only (default)
bridge = OmniLinkHTTPBridge(engine, port=8080)

Rate Limiting and Abuse Prevention

OmniLink enforces rate limits at multiple levels to protect the platform and individual accounts:

• Per-key rate limits — Each Omni Key has a maximum requests-per-minute (RPM) limit based on the subscription plan.
• Per-endpoint limits — Expensive endpoints such as /api/stt and /api/tts have lower RPM thresholds than lightweight endpoints like /api/chat.
• Burst protection — Short bursts above the sustained limit are tolerated (token bucket algorithm), but sustained overuse triggers 429 Too Many Requests.

When rate limited, the response includes a Retry-After header indicating how many seconds to wait before retrying.

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests. Please retry after 12 seconds.",
  "retry_after": 12
}

Data Handling

Understanding what OmniLink stores is critical for compliance and privacy assessments.

What OmniLink Stores

What OmniLink Does Not Store

• Raw audio files from STT or TTS — these are streamed and discarded.
• Your Omni Key in plaintext — only a salted hash is stored.
• ToolRunner local state — all execution data stays on your device.

Infrastructure

OmniLink’s cloud infrastructure is built on two managed platforms:

• Google Cloud Run — Containerized Node.js server with automatic scaling and DDoS protection. Each instance serves the static frontend and API routes from a single process with per-request concurrency limits.
• Supabase — Managed PostgreSQL database with built-in authentication, row-level security, real-time subscriptions, and encrypted storage. Hosted on AWS infrastructure.

Both platforms provide SOC 2 compliance, automated backups, and infrastructure-level encryption.

Compliance Considerations

OmniLink processes data through multiple third-party AI providers (Google, OpenAI, xAI, Anthropic). When evaluating compliance:

• Data residency — AI inference may occur in any region served by the selected engine provider. If you have strict data residency requirements, consult the provider’s documentation.
• GDPR — OmniLink supports data deletion requests. Users can delete all stored data (memory, knowledge, profiles) from the Dashboard.
• HIPAA — OmniLink is not currently HIPAA compliant. Do not process protected health information (PHI) through the platform.
• PCI DSS — Payment processing is handled entirely by Stripe. OmniLink never stores, processes, or transmits cardholder data.

Production Security Checklist

Use this checklist before deploying an OmniLink-powered application to production:

Key Management

• Omni Key is stored in an environment variable or secrets manager.
• Key is not present in source code, commit history, or client-side bundles.
• .env files are listed in .gitignore.
• Key rotation process is documented and tested.

Network

• All API calls use HTTPS.
• HTTP bridges are bound to localhost unless a reverse proxy is configured.
• HTTP bridge uses HTTPS if accessible beyond localhost.
• Firewall rules restrict bridge access to trusted IPs.

Application

• Backend proxy sits between the client and OmniLink API.
• System instructions do not leak sensitive internal details.
• Input validation is applied before passing user input to command handlers.
• Error messages do not expose stack traces or internal state.

Data

• Sensitive data is not stored in agent memory or knowledge base.
• Data retention policies are defined and enforced.
• Deletion workflows are tested (memory, knowledge, profiles).

Monitoring

• Usage dashboard is reviewed regularly for anomalies.
• Rate limit responses (429) are handled gracefully with retry logic.
• Alerts are configured for unusual usage spikes.