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.

Data access model

Recon operates on a principle of read data, never modify it. The one exception is explicit creation of tickets and documents when you ask for it.

Database and code: read-only

Recon connects to your database using a dedicated read-only Postgres role granted pg_read_all_data privileges. This 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 against your database through Recon.
• The read-only constraint is enforced at the Postgres role level, not just in application code.
• GitHub access is read-only (file reads, search, git history). Recon never pushes commits or opens PRs.
• You create the role; Recon never has superuser or admin access to your database.

Linear, Jira, Notion: read and create

Recon can read and search your tickets, issues, and docs. It can also create new Linear issues, Jira tickets, and Notion pages, but only when you explicitly ask it to (e.g. "file a bug for this" or "create a launch announcement in Notion"). Recon never modifies or deletes existing tickets, pages, or comments.

• Recon never edits, updates, or deletes existing Linear issues, Jira tickets, or Notion pages.

Human-in-the-loop approval

All write actions (creating tickets, docs, or posting to Slack) go through an explicit approval step. Recon shows you exactly what it wants to create, you review the content, and approve or cancel. No write action executes without your confirmation.

• You see a preview of the exact content before anything is created.
• You can edit the content before approving.
• Cancelling a write action is always available. Nothing is created until you click approve.

Intercom, HubSpot, Sentry, Stripe: read-only

Recon connects to these services via OAuth or API keys with read-only scopes. It can search and retrieve data (conversations, contacts, deals, errors, payments) but cannot create, modify, or delete any records.

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.
• Knowledge base: structured insights about accounts, patterns, and product behavior, curated by the AI agent. Stored as markdown files per workspace.
• Mission schedules and run history: what to monitor, how often, and the findings from each run.
• Advisories: suggested actions with their status (pending, approved, rejected, executed, expired).

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 may include data from your connected systems. You should consider this when deciding what data sources to connect.

Recon does not use your data to train or fine-tune any models. Your queries, results, and connected data are used solely to serve your investigations.

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

Missions, advisories, and knowledge base

Recon includes features that run autonomously on a schedule: recurring missions, a compounding knowledge base, and actionable advisories. Here is how each one works within the security model.

Recurring missions

Missions run on a schedule (daily, weekly, or custom) inside the same sandboxed environment as one-off investigations. Each run creates a fresh sandbox, executes the investigation, and destroys the sandbox on completion. Mission schedules and run history are stored per workspace with the same RLS isolation as all other data.

Knowledge base

Recon maintains a per-workspace knowledge base of structured insights (account profiles, recurring patterns, product notes). This contains curated markdown, not raw database records or credentials. Knowledge files are workspace-scoped and protected by the same RLS policies. Deleting a workspace removes all associated knowledge.

Advisories

Advisories are actionable suggestions Recon creates when it finds something worth acting on. All advisory actions (creating tickets, starting investigations) require explicit user approval before execution. No advisory action runs automatically. Pending advisories expire after 7 days if not acted upon.

Daily reflection

Once per day, Recon runs a reflection process that reads across the knowledge base and recent mission runs to find cross-cutting patterns. Reflection runs in a sandboxed environment with a restricted tool set (read-only file access and advisory creation). It cannot query external systems or modify data.

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.