Security

Everything Bot is built with a defense-in-depth security model. Every layer of the platform—from how your messages are handled to how API keys are stored—is designed to minimize risk. This page explains what we do to keep your data safe.

Our approach is inspired by NVIDIA NemoClaw, which sandboxes autonomous AI agents using layered Linux security primitives. We apply the same principles: minimize trust, restrict network access, isolate credentials, and enforce limits at every layer.

How your data is protected

Security isn’t a single feature—it’s layers working together. If one layer is compromised, the others still protect you.

• Container isolation— Each service runs in a locked-down container with no root access and a read-only filesystem.
• Network restrictions— The gateway service that provides agents can only connect to a specific list of approved services. Everything else is blocked by default.
• Credential isolation— API keys stay on the server. They are never sent to your browser or embedded in any client-side code.
• Least-privilege database access— Production traffic uses a restricted runtime database role, while major schema operations are handled with a separate admin role.
• Sensitive field encryption— High-risk secrets (for example OAuth tokens) are encrypted by the app before being stored in the database.
• Message verification— Incoming messages from Telegram, WhatsApp, and other platforms are cryptographically verified before processing.
• Rate limiting— Automatic limits prevent abuse and runaway message loops from exhausting AI resources.
• Session isolation— Every agent, channel, and user gets a unique session. Conversations cannot leak between agents or users.

Encryption

In transit

All connections to Everything Bot are encrypted with TLS. We enforce HTTPS across the entire application with HTTP Strict Transport Security (HSTS) preloading, and Cloudflare provides TLS termination at the edge with Full (strict) mode enabled between the CDN and origin. Database connections to Neon Postgres also require TLS—plaintext connections are not accepted.

At rest

All data stored in the database is encrypted at rest by Neon’s infrastructure. On top of that, high-sensitivity fields—such as channel credentials, OAuth tokens, and integration secrets—are encrypted at the application layer using AES-256-GCM with unique initialization vectors before being written to the database. This means that even with direct database access, these values cannot be read without the application’s encryption key.

Tenant isolation

Everything Bot is a multi-user platform, and strict data isolation between users is enforced at the database layer using PostgreSQL Row Level Security (RLS). Every database query runs within a transaction that binds the authenticated user’s identity, and RLS policies ensure that each user can only access their own agents, channels, messages, and settings—regardless of what the application layer requests. This provides a database-enforced guarantee that one user’s data can never be returned in another user’s queries.

Database hardening

We use Neon Postgres with a production role split designed to reduce blast radius:

• Runtime role— Used by normal app requests and limited to application reads/writes.
• Admin role— Used only for migrations and schema maintenance.
• Controlled schema changes— Runtime migrations are disabled in production. Schema changes are applied through explicit migration runs.

Container hardening

Both the web application and the AI gateway run inside Docker containers with strict security controls. These aren’t defaults—they’re explicitly configured to limit what each service can do.

No root access

Services run as dedicated non-root users (nextjs for the web app, gateway for the AI gateway). Even if an attacker gained code execution, they would have minimal privileges.

Read-only filesystem

The entire container filesystem is mounted read-only. Only small, dedicated temporary directories are writable, and those are configured to prevent binary execution. This means malicious code cannot modify system files or persist between restarts.

Dropped privileges

All Linux capabilities are dropped at startup, and privilege escalation is blocked. Even if a vulnerability is discovered in a dependency, the process cannot grant itself additional permissions.

Isolated networking

In our containerized deployment, the web app and AI gateway communicate over a private internal network. The gateway port is not exposed publicly; external traffic flows through the web application.

Network egress controls

The AI gateway operates on a deny-by-default network policy. It can only make outbound connections to services on an explicit allowlist. Any connection attempt to a host not on the list is blocked and logged.

Approved destinations

The gateway is only allowed to contact the following services:

• AI providers— Google Gemini, OpenAI, Anthropic, and NVIDIA inference endpoints (POST only, specific API paths).
• Messaging platforms— Telegram, WhatsApp (Meta Graph API), Slack, and Discord (limited to their official API endpoints).

Each rule specifies the exact hostname, port, allowed HTTP methods, and URL path patterns. For example, the Gemini rule only allows POST requests to generativelanguage.googleapis.com on port 443 at /v1beta/models/*. Connections to other paths on the same host are blocked.

Credential isolation

Your API keys, bot tokens, and secrets never leave the server. They follow a strict isolation pattern:

• LLM API keys (Google, OpenAI, Anthropic) are set as environment variables on the gateway container and never appear in any client-facing code.
• Channel credentials (Telegram bot tokens, WhatsApp access tokens) are stored in the database (encrypted at rest by Neon Postgres). High-risk fields are additionally encrypted by the app before storage.
• Gateway authentication uses a shared token between the web app and the AI gateway. This token is only sent over the internal Docker network, never over the public internet.
• Integration bridge authentication uses a dedicated shared hook token for app-to-gateway tool calls.
• Browser sessions are protected by a signed cookie secret. No API keys, tokens, or credentials are ever sent to your browser.

Message verification

When Telegram, WhatsApp, and payment webhook providers send events to Everything Bot, we verify they’re genuine before processing them. Forged messages are rejected immediately.

• Telegram— Each webhook request includes a secret token header. We compare it against the expected value using a constant-time algorithm that prevents timing attacks.
• WhatsApp— Meta signs each webhook payload with HMAC-SHA256. We recompute the signature and verify it matches before processing.
• Payments (Polar)— Webhook signatures are verified using the webhook secret, ensuring payment events can’t be spoofed.

All agent identifiers in webhook URLs are validated against a strict format before any database lookup, preventing injection and enumeration attacks.

Rate limiting

Agent messaging webhooks are protected by a sliding-window rate limiter. This prevents abuse from forged callbacks and protects AI resources from runaway message loops.

• Telegram and WhatsApp webhooks are limited to 120 requests per minute per agent.
• When the limit is exceeded, requests receive a 429 Too Many Requests response with a Retry-After header.

The gateway’s security policy also defines rate limits for chat and webhook traffic, providing an additional layer of protection.

Session isolation

Every conversation is scoped to a unique combination of agent, channel, and user. The session key follows a structured format:

agent:{agentId}:{channel}:dm:{userId}

This ensures:

• Different agents cannot read each other’s conversations.
• Users on different channels (e.g. your Telegram chat vs. your web chat) have separate sessions.
• Two different users talking to the same agent cannot see each other’s messages.

AI safety limits

The AI gateway enforces limits on how models are used, preventing excessive resource consumption and limiting the blast radius of any misuse:

• Model allowlist— Only approved models can be used. Requests for unlisted models are rejected.
• Output limits— Each AI response is capped with configured token limits (up to 4,096 tokens in gateway policy), preventing unbounded generation.
• Input limits— Inbound messages are capped at 4,000 characters.

Error handling

When something goes wrong, error messages are sanitized before logging. API keys, Bearer tokens, and other sensitive strings are automatically redacted so they never appear in logs, error reports, or user-facing messages.

Data retention

Chat messages are retained for a configurable period (default 90 days in production) and automatically pruned after expiry. OAuth state records used during integration setup are short-lived and automatically deleted after they expire. We do not retain data longer than necessary to provide the service.

Dependency security

All dependencies are installed from a locked manifest to ensure reproducible builds. GitHub Dependabot monitors for security updates to both application packages and Docker base images on a weekly schedule, and we pin known-vulnerable transitive dependencies to safe versions.

Open source & transparency

Our security approach is inspired by NVIDIA NemoClaw, an open-source framework for sandboxing AI agents. While NemoClaw uses Linux kernel primitives (Landlock, seccomp, network namespaces) for enforcement, Everything Bot achieves comparable isolation using Docker’s security features, which are backed by the same kernel mechanisms.

If you discover a security vulnerability, please report it to [email protected].