ReasonBlocks

Data & Privacy

Trust page · last updated 2026-05-11

What ReasonBlocks sees, and does not

Your agent talks to your LLM provider directly. Your Anthropic, OpenAI, or other model credentials live in your environment and never reach our infrastructure. We do not proxy, intercept, or store them. Removing ReasonBlocks from your stack stops the analysis without affecting your LLM access.

What our SDK does send us, per agent step, is the small slice of your trajectory we need to analyze it:

  • the agent's thought or reasoning text for that step;
  • the tool name it called and the arguments it passed;
  • the tool's output as the agent received it, capped at a few kilobytes per field;
  • token counts, timing, and the metadata tags you chose to attach.

At session end we may also receive the structured trace of the whole run, in the same shape, when you opt into our pattern-extraction pipeline.

No other data is transmitted. We do not receive the customer-facing requests your agent answered, the system prompts you wrote, your application database, or any code your agent did not read during the run. A file's contents reach our infrastructure only when your agent reads it through a tool call.

What crosses the boundary

YOUR INFRASTRUCTUREREASONBLOCKSYour agent loopReasonBlocks SDKmiddlewarerb-apitrajectory sliceinterventionAnthropic / OpenAI /your key, your full requestPostgres(Supabase)Qdrant(vectors)

In the trajectory slice

  • agent thought (text)
  • tool name + arguments
  • tool output (truncated per field)
  • token counts, timing
  • tags you chose

Never crosses the boundary

  • your LLM provider API key
  • system prompts you wrote
  • application code your agent did not read
  • end-user PII not in a tool call

How we keep customers separate

Every per-customer API key is bound to a single organization at creation time. That binding is stored on our server and determines which data a request can read and how new data is stamped. The SDK cannot override it; values supplied in the request body are not trusted for tenancy decisions.

Every row we store about your run carries your organization's identifier. Every read filter and every write check enforces that identifier at the storage layer, not only at the route layer. A request from one customer that attempts to read or modify another customer's data — whether by guessing an identifier, replaying a URL, or any other path — receives the same "not found" response as a request for data that does not exist. Our error responses do not distinguish between "forbidden" and "missing," so existence cannot be probed.

Patterns we mine from your trajectories are tagged with your organization at extraction time and filtered with the same tenancy rule on every retrieval. One customer's patterns are returned only to that customer. There is no automatic promotion path that would move them into a shared pool.

rb-apiOrg Arb_live_…a1b2…Org Brb_live_…f3e4…Org Crb_live_…9c8d…every write inherits org_id from the authenticated keyOrg A's datarunspatternsfindingsOrg B's datarunspatternsfindingsOrg C's datarunspatternsfindings

How ReasonBlocks processes your trajectories

Three operations run on the trajectory slice the SDK sends us. Together they form a per-tenant feedback loop: every run your agents complete produces signal that makes future runs of yours better, scoped to your organization.

1. Monitoring. At each agent step, the trajectory up to that step is scored against a fixed set of trajectory-quality detectors — loops, low-novelty plateaus, premature commit, topic drift, and similar failure shapes. When a detector crosses its threshold, we return an intervention text that the SDK splices into the agent's system message before the next call. The detectors are deterministic; they do not require any training on your data to function.

2. Retrieval. Also at each step, we semantic-search a pattern store for prior lessons relevant to the current state, and return any matches. Three tiers exist:

  • E1 — patterns derived from your own past runs. Tenant-private; only returned to the organization that produced them.
  • E2 — a "commons" pool of transferable failure-shape patterns, seeded by us. Cross-customer by design; customer data is not promoted into E2 automatically.
  • E3 — a small set of universal trajectory rules that ship with the product. Hand-authored; identical for every customer.

Only E1 carries any artifacts derived from your data. E2 and E3 are platform content.

3. Distillation. At session end, when a run hit interesting failure modes that the agent eventually recovered from, we extract the lesson — what went wrong and what worked to recover — and store it as a short E1 pattern under your organization. The next run starts with that lesson available for retrieval. Distillation is the one step in the pipeline that delegates to an external model: producing the human-readable summary from the raw trajectory requires an inference call, which we route to Anthropic under their standard API data policy. No other part of the pipeline calls an external model.

The motivation for distillation is straightforward: agents repeat their own mistakes. Without a memory layer, every run starts cold and re-learns the same lessons. Distillation captures the lesson once, scopes it to the tenant that produced it, and serves it back at the start of future runs. Distillation is enabled by default and can be disabled in the SDK configuration via enable_distillation=False.

Where data lives

We store run telemetry in a managed Postgres instance (Supabase). We store retrieved patterns and per-codebase findings in a managed vector database (Qdrant Cloud). Both providers are SOC 2 compliant and encrypt data at rest. All communication with our service runs over TLS 1.2 or higher.

When we extract a pattern from one of your traces, we send a three-call window from that trace to Anthropic to produce the human-readable summary. Anthropic processes that call under its standard API data policy — they do not train on API inputs. Your data is therefore in transit through Anthropic for the duration of one inference call per pattern.

Sub-processors

  • Supabase · Postgres + auth · runs, steps, profiles, keys
  • Qdrant Cloud · vector store · retrieved patterns, per-codebase findings
  • Anthropic · one inference call per distilled pattern · not retained on Anthropic's side under their API data policy
  • Render · rb-api compute and logs

Adding a sub-processor is a notice event, not a silent change.

What we use your data for

The trajectory data you send us is used to compute monitor scores and surface interventions for your agent, to populate your dashboard, to derive patterns scoped to your organization, and to meter your usage for billing. No other use is made of it.

We do not train machine-learning models on customer data. Your data is not used to produce any artifact another customer would receive.

We do not share customer data with other customers, with any party other than the sub-processors listed above, or with any party for marketing or analytics purposes.

Your controls

You can delete individual patterns, individual findings, and individual custom monitor profiles via the dashboard or the API. Deletion is immediate at the storage layer. A run-level delete and a single-call account purge are not yet shipped; account-wide deletion is available on request to the address in the Reporting section below.

You can read every artifact stored with us through the same API endpoints the dashboard uses. Run metadata, step bodies, patterns, and findings are available as JSON; no separate export tier is required.

Every step record on your account carries the API key that wrote it; per-key activity is visible in your dashboard. When a key is revoked, propagation across our caches takes up to sixty seconds, after which any session using the revoked key ceases to function.

What rb-api does not do

  • We do not train models on customer data.
  • We do not share customer-derived patterns across customers.
  • We do not see, log, or proxy your LLM API key.
  • We do not call your LLM provider on your behalf — no proxy mode.
  • One customer's agent cannot inject patterns into another customer's retrieval. Every pattern's organization is server-stamped from the authenticated principal and the tenancy filter is mandatory on read.

Reporting

To report a suspected security issue, contact rohan@reasonblocks.com. We aim to acknowledge receipt within one business day and to communicate the scope of any incident before public disclosure.

For non-urgent data-handling questions — sub-processor changes, retention, export assistance — rohan@reasonblocks.com is the right address.