Security Overview

This page explains how Recon handles credentials, data access, and execution isolation when you connect your production systems. It is written for engineers and technical evaluators, not for marketing purposes.

Read-only database access

Recon connects to your database using a dedicated read-only Postgres role. This role is granted pg_read_all_data privileges, which permits SELECT queries on all tables but prohibits INSERT, UPDATE, DELETE, and schema modifications.

During connection setup, Recon provides the exact SQL to create this role on your database. You run it. Your engineering team controls what the role can access and can revoke it at any time.

• No writes, no deletes, no schema changes are possible through Recon.
• The read-only constraint is enforced at the Postgres role level, not just in application code.
• You create the role; Recon never has superuser or admin access to your database.

Sandboxed execution

Every investigation runs inside an isolated E2B sandbox — a Firecracker microVM with hardware-level isolation between tenants. Sandboxes are created at the start of an investigation and destroyed when it ends.

• There is no persistent connection between Recon's infrastructure and your production systems. Each investigation establishes a fresh connection inside the sandbox and tears it down on completion.
• Sandboxes are ephemeral. No data or state persists between sessions.
• Hardware-level isolation (Firecracker) means sandbox processes cannot access other tenants' sandboxes or Recon's host infrastructure.

Credential encryption

Connection credentials — database URLs, GitHub tokens, Linear API keys, Notion tokens — are encrypted at rest using AES-256-GCM before being stored. Each workspace has its own encryption scope.

• Credentials are decrypted in-memory only at the time of use, inside the sandbox session.
• Credentials are never written to logs or exposed in API responses.
• End users (PMs, support, ops) interact with the query interface. They never see the raw credentials, connection strings, or API tokens that admins configured.

Bring Your Own Key (BYOK)

Recon supports BYOK for LLM providers. You can provide your own Anthropic or OpenAI API key in workspace settings. When a key is configured:

• All prompts from your workspace are sent to your chosen provider using your key.
• Your BYOK key is encrypted at rest using the same AES-256-GCM mechanism as connection credentials.
• Recon does not proxy, cache, or log raw prompt content beyond what is needed to stream results to your session.
• You choose the model (Claude, GPT-4o, etc.) and own the API relationship with the provider.

Teams that do not configure a BYOK key use Recon's default model. In that case, prompts are processed using Recon's API key with Anthropic.

What Recon stores

Recon stores the following to support its core function — letting teams reference and build on past investigations:

• Conversation history: the natural language messages you send and the AI responses returned.
• Tool call inputs and outputs: the SQL queries executed, files read, tickets fetched, and the data returned. This is what populates the "show your work" panel in the UI.
• Workspace configuration: connection types, names, and encrypted credentials.
• Usage data: token counts, model used, query timestamps. Used for billing and analytics.

Recon does not store raw database credentials or API tokens in plaintext. It does not log prompt content to external analytics systems. Stored tool outputs contain the data the AI retrieved — for example, the rows returned by a SQL query — which may include data from your connected systems. You should consider this when deciding what data sources to connect.

Workspace admins can delete conversations and all associated tool outputs at any time. Deleting a workspace removes all stored data permanently.

Workspace and tenant isolation

Each workspace is fully isolated at the database level using Postgres Row Level Security (RLS) policies. This applies to all tables: conversations, messages, connections, RAG embeddings, and usage records.

• One workspace cannot read or write another workspace's data.
• For agencies or teams managing multiple client workspaces, each client workspace is isolated — admins cannot cross-query across workspaces accidentally.
• RLS is enforced at the database layer, not only in application logic.

Team access controls

Recon is designed around a principle of least privilege for non-technical users:

• Workspace admins connect data sources and configure credentials. This is a one-time setup step.
• Team members (members, viewers) get access to the query interface. They can ask questions and see results but cannot view, edit, or remove connection credentials.
• Role-based access (admin, member, viewer) controls who can manage connections, invite users, and access workspace settings.
• All investigations are logged in an append-only audit log scoped to the workspace, recording who ran what query and when.

Infrastructure

• Hosting: Vercel (application), Supabase (database and storage).
• Sandbox execution: E2B (Firecracker microVMs).
• Authentication: Clerk (user accounts, sessions, organization management).
• Payments: Stripe. Recon does not store or process payment card data.

Questions

If you have specific security questions, need a security review before connecting production systems, or want to report a vulnerability, email support@askrecon.com.