Back to AGENTHEORY
Security Architecture
Notice — Operational Overview: This page outlines our technical security controls, cryptographic practices, and vulnerability reporting process.

Security Architecture & Defense-in-Depth

Last updated: November 2026

1. Cryptographic Key Protection

  • Algorithm: All third-party credentials (OpenAI, Gemini, Groq, OpenRouter, xAI, Tavily, and SMTP/IMAP credentials) are encrypted with authenticated AES-256-GCM.
  • Key Format: The master ENCRYPTION_KEY must decode to exactly 32 bytes (either 44-character Base64 generated via openssl rand -base64 32 or 64-character Hex generated via openssl rand -hex 32). Server boot executes strict byte-length validation without printing or logging secret values.
  • Initialization Vectors: A cryptographically secure 12-byte IV is generated independently for each encryption operation.
  • Versioned Ciphertext: All ciphertexts include an explicit format version prefix (e.g. v1:) allowing zero-downtime key rotation while retaining seamless backward compatibility with legacy payloads.
  • No Client Exposure: Secret keys never leave server memory; the user interface only displays unrevealing hints (e.g., last 4 characters).

2. Channel Owner Binding & Access Governance

  • Single-Use Pairing Codes: To prevent stranger IDOR takeover on Telegram and Discord, bot owners must generate a short-lived (10-minute) single-use pairing code in the web console and send /pair <code> to the bot. The platform user ID is verified and bound as the sole verified owner.
  • Personal Data Isolation: Personal tools (calendar mutations, inbox management, private memories, and schedule configurations) execute strictly for the verified owner.
  • Access Policy Settings: Each bot can be set to Owner only (strangers are completely blocked from using the bot or spending API quota) or Anyone (limited public mode where strangers can chat and search the web, but personal data tools remain strictly locked).
  • External Rate Limiting: External Telegram and Discord callers are rate limited per platform user ID to safeguard the owner's API key quota.

3. Approval Workflows for Destructive Actions

  • Safe Defaults: Outbound emails, calendar event deletions, and automated scheduled task creations require explicit human confirmation by default (auto-approve is OFF).
  • Automated Task Quarantining: When an agent configures a new scheduled recurring task, it is saved in a paused state until explicitly reviewed and activated in the Schedules panel.
  • Explicit Override: Owners can optionally toggle auto-approval in Agent Settings, triggering a visible warning in the dashboard.

4. Inbound Email Isolation & Loop Suppression

  • Zero-Tool Inbound Pipeline: The email sync and webhook ingest engine passes zero tool definitions to the LLM when summarizing or drafting replies, mathematically guaranteeing that incoming emails cannot trigger calendar writes, scheduled tasks, memory edits, or unauthorized transmissions.
  • Adversarial Prompt Enclosures: Inbound message bodies are wrapped inside <<<UNTRUSTED_INBOUND_EMAIL>>> isolation blocks accompanied by explicit anti-injection directives.
  • Loop & Auto-Responder Suppression: Inbound emails are evaluated against automated mail headers (Auto-Submitted, Precedence: bulk/list/junk/auto_reply, X-Autorespond, List-Id, List-Unsubscribe), automated subject patterns (out of office, delivery failure notifications), and no-reply address regexes before auto-replying.
  • Strict Recipient Binding: Auto-replies can only be dispatched to the verified original sender address, never to secondary or arbitrary addresses.
  • Outbound Quotas: Strict rate limits of 50 emails/day and 20 emails/hour apply to all sent messages and auto-replies to protect mailbox reputation.

5. Browser Security & CSP Violation Reporting

  • Security Headers: HSTS (max-age=63072000; includeSubDomains; preload), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and restrictive Permissions-Policy.
  • Content Security Policy: Deployed via Content-Security-Policy-Report-Only with reporting wired to /api/csp-report and modern Reporting-Endpoints. Violation reports are rate-limited, query parameters are stripped, and logs are truncated without recording sensitive tokens.
  • Safe Markdown Rendering: Rendered Markdown links in chat and documentation are sanitized to only permit http:, https:, and mailto: protocols, disallowing javascript: and data: URIs.

3. SSRF & Network Protections

  • DNS Validation: The server-side webpage reader and public API tools validate resolved IP addresses, strictly blocking localhost (127.0.0.1, ::1), private subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and cloud metadata endpoints (169.254.169.254).
  • Port Restriction: Outbound requests are limited to standard HTTP (80) and HTTPS (443) ports.

4. Tenant Isolation & Row Level Security (RLS)

Every table in the PostgreSQL database is protected by Row Level Security (RLS). Cross-tenant access is verified via automated test suites ensuring that authenticated users and anonymous clients can never read, modify, or delete another user's agents, sessions, memories, schedules, or emails.

5. Vulnerability Disclosure

We welcome responsible security research. If you discover a security vulnerability or potential flaw, please notify us confidentially at security@agentheory.space.