IER-0
EnterprisePricing
PricingSign in
OverviewSignalsWhy this is a support-context featurePick one secure connection pathUse strict lookup contractsEnable the right surfacesRollout checklistOperationsProofReferencesNext
OverviewSignalsWhy this is a support-context featurePick one secure connection pathUse strict lookup contractsEnable the right surfacesRollout checklistOperationsProofReferencesNext
Home
Resource

Read-only customer data lookup

How to connect project data stores safely so drafts can include current account context for support, while keeping execution bounded by policy and approvals.

Start pilot View pricing
Scope
Project

Connections and tools are configured per project.

Input
Email bound

Queries should key from a bounded customer identifier.

Safety
Policy-gated

Lookups are used in governed draft surfaces only.

1.0

Why this is a support-context feature

This feature adds live account facts to AI drafting (for example plan, seats, or billing state) without making your entire database a knowledge base. Use it when your support team needs current state, not static docs.

  • Supports current-state answers
  • Prevents stale knowledge snapshots
  • Operates inside project-level policy
2.0

Pick one secure connection path

Open `/projects/[projectId]/data` and choose the integration mode that matches your infrastructure policy.

  • Postgres URL: direct encrypted read-only connection through an approved DB role.
  • Signed HTTPS relay: use when your database is private, behind ACLs, or requires brokered access.
  • Both paths support the same project approval workflow and audit visibility.
Operations

What this means in production.

These pages describe the product contract behind the UI, not a decorative brochure. Each surface should connect back to the same governed support loop.

Control boundary

Live account data is fetched at query time instead of being silently embedded.

Operator workflow

Support moves through secure ingest, AI preparation, human approval, outbound execution, and audit evidence.

Configuration impact

Provider setup, project policies, knowledge trust, retention, and billing limits decide how this behaves for a real workspace.

Proof points

Designed for governed support, not hidden autonomy.

Live account data is fetched at query time instead of being silently embedded.
All lookups remain bound to project and tool permissions.
Draft context stays within the governed workflow with approval-first execution.
References

Official stack and legal references.

These external links point to provider documentation, privacy notices, data-processing terms, or platform terms that shape production operation.

PostgreSQL prepared statementsexternalParameter-binding and prepared-query behavior for safer lookup tooling.PostgreSQL security modelexternalReference for row-level controls and least-privilege database hardening.Neon Postgres docsexternalConnection and pooling behavior for managed Postgres with support workloads.
Next

Keep exploring the operating model.

ProjectsSecurity checklistProvider setupPricingSign in
3.0

Use strict lookup contracts

Every lookup must be a constrained, deterministic query. This is intentional so support tooling stays reviewable and safe.

  • Use a read-only role; no writes, no schema changes, no maintenance commands.
  • Queries must be one statement and start with SELECT or WITH.
  • Always bind customer email as $1 in SQL (no string concatenation).
  • Return explicit columns; avoid SELECT *.
  • Restrict schemas, tables, views, and blocked columns to support-safe paths.
4.0

Enable the right surfaces

A lookup tool can be active only where its intended safety boundary allows it.

  • Enable for Agent drafting when operator review workflows should include account context.
  • Enable for widget only after identity verification rules are required and passed.
  • Disable a tool quickly if it returns noisy or sensitive lookups.
5.0

Rollout checklist

Before production use, run this flow once from a test account.

  • Create a read-only database role and a narrow support-safe view.
  • Connect the role or relay credentials in the connector.
  • Create a test lookup using `... WHERE email = $1` and run a safe sample.
  • Link the lookup to Agent and widget surfaces according to policy.
  • Verify one draft now includes expected context and no sensitive fields.
Supabase Postgres guides
external
Neat patterns for building read-only support-safe database structures.
Signed HTTPS relay patternexternalGeneral API gateway posture for private backend relay integrations.