Security Overview

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, create, and limited update

Recon can read and search your Linear issues, Jira tickets, and Notion pages. With your explicit approval, it can also create new Linear issues, Jira tickets, and Notion pages (e.g. "file a bug for this" or "create a launch announcement in Notion"), update the status or fields of an existing Linear issue or Jira ticket, and post comments on existing Linear issues or Jira tickets. Every one of these actions goes through the human-in-the-loop approval flow described below before anything mutates.

• Recon does not delete Linear issues, Jira tickets, Notion pages, or comments.
• Recon does not modify Notion pages it did not create (Notion writes are limited to creating new pages).
• Updates and comments on Linear issues and Jira tickets go through the same approval flow as creates. Nothing mutates without an explicit click from a workspace member.

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, Zendesk: read with limited approval-gated writes

Recon connects to these services via OAuth or API keys. It can search and retrieve data (conversations, contacts, deals, tickets) and, with your explicit approval, can add internal notes to Intercom or Zendesk conversations, create new Intercom tickets, and update HubSpot contacts, deals, or companies. As with Linear and Jira, every write action surfaces an approval card; nothing executes until a workspace member clicks Approve.

Sentry, Stripe: read-only

Recon connects to Sentry and Stripe with read-only scopes. It can search and retrieve errors, customers, subscriptions, and payments but cannot create, modify, or delete any records in either system.

Slack: deliver where the work was started

Recon posts back to the Slack thread or channel that triggered the work: replies in the same thread for investigations started from Slack, the configured channel for scheduled agents, and the configured channel for inbox-action cards. This routine delivery is part of how the integration works and does not require per-message approval.

The only Slack approval flow is for the write actions described above (creating a Linear issue, adding an Intercom note, etc.). When a write action is queued during an investigation that was started from Slack, the same approval card we show in the web UI is delivered to that Slack thread so a workspace member can review and approve from where they are already working. The approval gate itself is identical; only the surface where the card appears changes.

Sandboxed execution

Every investigation runs inside an isolated E2B sandbox: a Firecracker microVM with hardware-level isolation between tenants. A sandbox is created the first time a workspace runs an investigation and paused on completion. The same paused sandbox can be resumed by the next investigation in that same workspace, up to a 12-hour total lifetime. After 12 hours of inactivity it is fully torn down and the next run gets a fresh one.

• Sandboxes are scoped to a single workspace. A sandbox created for workspace A is never resumed for workspace B; the pool match key includes both the workspace ID and the exact set of connections, so a workspace switching its connections also gets a fresh sandbox.
• Per-conversation scratch directories prevent concurrent investigations in the same workspace from seeing each other's notes or artifacts.
• While paused, the sandbox cannot be accessed without an explicit resume call from our orchestrator. Pausing is functionally similar to teardown for access purposes.
• Hardware-level isolation (Firecracker) means sandbox processes cannot access other tenants' sandboxes or Recon's host infrastructure.

Credential encryption

Connection credentials (database URLs, GitHub OAuth tokens or PATs, Linear/Notion/Jira/Slack/Atlassian OAuth tokens, Stripe restricted keys, etc.) are encrypted at rest using AES-256-GCM with a random 12-byte IV per record before being written to Postgres. The 32-byte encryption key lives only in our Vercel environment and is never in the repo, in logs, or surfaced in any API response.

• Credentials are decrypted server-side only at the moment a tool call needs them, then passed into the sandbox as environment variables on that single command invocation. They are not written to the sandbox filesystem.
• Credentials are never logged. Sentry has PII disabled and a scrubber strips anything matching token, key, secret, password, cookie, or auth.
• 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 requires BYOK for LLM access. Every customer supplies their own OpenAI, Anthropic, or Google API key in workspace settings; Recon does not run prompts through a shared LLM account on your behalf. New customers get their first month free of any plan, and a BYOK key is part of onboarding.

• All prompts from your workspace are sent to your chosen provider using your key. The API relationship is between you and the provider.
• Your BYOK key is encrypted at rest using the same AES-256-GCM mechanism as connection credentials and decrypted only when assembling the request.
• You pick the model (GPT-5.4, Claude Sonnet 4.5, Gemini 3 Pro, etc.) and your provider's data-handling terms apply (none of OpenAI, Anthropic, or Google trains on API traffic by default).
• Conversation transcripts are stored in your workspace's database so you can revisit past investigations (see "What Recon stores" below). They are not forwarded to any external analytics.

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 (see Credential encryption above). 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. Keep this in mind 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 individual conversations and all associated tool outputs from the dashboard at any time. Full workspace deletion is currently handled manually on request to support@askrecon.com (within 5 business days, with confirmation). Self-serve workspace deletion is on the roadmap with no committed date yet.

Agents, inbox, and knowledge base

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

Recurring agents

Agents run on a schedule (daily, weekly, or custom) inside the same sandboxed environment as one-off investigations. Each run uses the workspace's pooled sandbox (resumed if active, freshly created if the prior one has been torn down) and pauses it on completion under the same 12-hour TTL described above. Agent schedules and run history are stored per workspace.

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.

Inbox

The inbox holds actionable suggestions Recon creates when it finds something worth acting on. All inbox actions (creating tickets, starting investigations) require explicit user approval before execution. No inbox action runs automatically. Pending inbox items 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 agent runs to find cross-cutting patterns. Reflection runs with a restricted tool set: the connected-system tools (Postgres, GitHub, Linear, and so on) are not loaded, so the agent cannot directly query customer systems. Reflection cannot modify customer data; the only thing it can produce is an inbox item, which is itself approval-gated before any action runs.

Workspace and tenant isolation

Each workspace is isolated at multiple layers. At the application layer, every workspace-scoped API route enforces both org membership and a workspace-member row before any database access. At the database layer, Postgres Row Level Security policies are enabled on every multi-tenant table (conversations, messages, connections, audit log, usage) and will become the primary enforcement boundary as we migrate routes to user-scoped tokens in Q2 2026.

• One workspace cannot read or write another workspace's data through any supported path.
• For agencies or teams managing multiple client workspaces, each client workspace is isolated. Admins cannot cross-query across workspaces accidentally.
• Non-members requesting a workspace they do not belong to receive a 404 (we do not reveal whether the workspace exists).

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.
• Members get access to the query interface. They can ask questions and see results but cannot view, edit, or remove connection credentials, manage other members, or change billing.
• All investigations and inbox actions are written to an append-only audit log scoped to the workspace, recording who ran what and when.

Application security

Beyond data isolation and credential handling, the application surface itself ships with the following controls:

• Browser security headers: the standard set sent on every response, including HSTS to force HTTPS for two years, X-Frame-Options DENY to prevent clickjacking, X-Content-Type-Options nosniff, a strict Referrer-Policy, a Permissions-Policy that turns off camera/mic/geolocation, and Cross-Origin-Opener-Policy same-origin.
• SSRF protections: connection-test endpoints (Postgres, Jira) validate hostnames and refuse RFC1918, loopback, link-local, and cloud metadata IPs before any outbound request.
• Webhook signatures: Stripe, Clerk, Slack, and QStash webhook handlers verify provider signatures before processing.
• Rate limits: the public endpoints (contact form, demo lead, free tools) are rate-limited per IP.
• Error monitoring: Sentry runs with PII disabled and a beforeSend scrubber that strips anything matching token, key, secret, password, cookie, or auth from headers and query strings.
• CI security gates: every pull request and push to main runs npm audit (custom severity gate), gitleaks for secret scanning, TypeScript typecheck, ESLint, and a focused suite of unit tests for auth, rate limiting, SSRF, and the approval gate. Any failure blocks merge.

Known limitations

We aim to be honest about what is not yet in place. The biggest items today:

• Third-party penetration test: nothing scheduled today. Open to engaging a reputable firm when the company is funded for it.
• SSO / SAML: not supported as a Recon plan feature today.
• Self-serve workspace deletion: handled manually today on request. A self-serve flow is on the roadmap, no committed date yet.
• Centralized audit-log forwarding: the audit log is append-only in our database and queryable from the dashboard, but we do not yet forward events to an external log-aggregation service for long-term retention or alerting.
• Customer-managed encryption keys, VPC deployment, EU data residency: not available today. Open to scoping on a case-by-case basis for design partners with the requirement.

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.

Reporting a vulnerability

We take security seriously. If you believe you have found a vulnerability in Recon, please report it to us privately at security@askrecon.com so we can investigate and fix it before any public disclosure. If that mailbox is unreachable, fall back to pratik@askrecon.com.

Please include a clear description of the issue, steps to reproduce (a minimal proof of concept is ideal), the affected endpoint or page, and your name or alias if you would like recognition.

Response SLA

• Acknowledge your report within 1 business day.
• Initial triage with a severity assessment within 3 business days.
• Remediation scoped to severity: Critical within 48 hours of confirmation, High within 7 days, Medium within 30 days, Low addressed in the next planned dependency or security refresh.
• We keep you updated as the fix progresses and notify you when a patch ships.

Scope

In scope:

• The Recon web application at https://askrecon.com and any subdomain.
• The Recon API endpoints at https://askrecon.com/api/*.
• The Recon Slack bot.
• Authentication, authorization, multi-tenant isolation, secrets handling, the write-action approval flow, sandbox isolation, and any code path that touches customer data.

Out of scope:

• Denial of service or volumetric attacks.
• Findings that require physical access to a victim's device.
• Vulnerabilities in third-party services we use (Clerk, Supabase, Vercel, E2B, Anthropic, OpenAI, Google, Stripe, Upstash, Sentry). Please report those directly to the vendor; we will help coordinate.
• Social engineering of Recon employees or customers.
• Missing best-practice security headers without a concrete exploit.
• Self-XSS that requires the victim to paste attacker-controlled content into their browser console.
• Issues only reproducible on outdated browsers or out-of-date OS versions.

Safe harbor

We will not pursue or support legal action against security researchers who make a good-faith effort to comply with this policy, avoid privacy violations and degradation of service, do not access or exfiltrate data beyond what is necessary to demonstrate the vulnerability, and do not publicly disclose details until we have had a reasonable chance to remediate. If you are uncertain whether your testing falls within scope, email us first.

Recognition

We do not currently run a paid bug bounty program (we are an early-stage company, working with our first design partners). We do offer public acknowledgment in our security advisory with your permission, coordinated disclosure timelines that respect your work, and a written reference if useful for your own profile. If we ever launch a paid program, prior reporters will be invited first.

General security questions

For non-vulnerability questions, security reviews before connecting production systems, or DPA requests, email support@askrecon.com.