Skip to main content
Clark accesses runtime data during development to build and debug apps — the same way a human developer would. Clark only operates in the Edit environment; it never runs against Preview or Production environments.

​
Why Clark needs data access

Like any developer, Clark needs to see runtime data to build correctly. During development, Clark can do things such as:
  • Execute APIs and read responses
  • Run one-off queries to sample data
  • Inspect individual API step output
  • Read browser console logs
  • Screenshot the app
  • Run automated tests
This is consistent with how AI coding tools work broadly — agents like browser-based copilots, MCP-connected assistants, and cloud-hosted AI editors all access runtime data during development. Unlike generic AI coding agents, Superblocks gives Administrators explicit control over which data environments Clark can access during development.

​
AI inference and data handling

Clark is powered by frontier LLMs hosted securely in the Superblocks Cloud or customer cloud. Here’s how your data is handled:
  • No model training: Data sent to the LLM for inference is never used to train or fine-tune any model, regardless of your deployment model.
  • Where inference runs: The location of AI inference depends on your deployment model. For Cloud and Hybrid deployments, inference runs in the Superblocks Cloud. For Cloud-Prem deployments, inference runs entirely within your cloud environment.
  • What Superblocks retains: Superblocks stores model requests and responses to power the conversational chat experience. For Cloud and Hybrid deployments, this data is stored in the Superblocks Cloud. For Cloud-Prem deployments, it remains in your cloud environment. This is required for the product to function — it’s what allows you to see and continue your chat history with Clark.
All data processed and stored in the Superblocks Cloud follows security best practices and a SOC 2-aligned program. HIPAA can apply for PHI where a BAA is in place. See the Security guide for attestations, subprocessors, and how we protect data.

​
Developing against lower environments

Superblocks lets you connect multiple data environments — for example, a production database and a staging database — and switch between them using data tags. In the Edit environment, Clark runs against whichever data tag is active. Developing against lower environments provides two benefits:
  1. Avoid corrupting production data: When building applications that perform writes, using a non-production environment prevents Clark from accidentally modifying real data. This applies to all customers regardless of deployment model. If you are building read-only applications, developing against production data in the Edit environment does not carry this risk.
  2. Keep sensitive data in your VPC (Only relevant for Hybrid customer): For customers using the Hybrid deployment, the data plane runs inside your VPC, but Clark and AI inference run in Superblocks Cloud. Data accessed in the Edit environment is sent to the Superblocks Cloud so Clark can use it during development. Using non-production data ensures that production data never leaves your network.
Admins can restrict what data Clark has access to by configuring data tags used in the Edit environment — see Manage environments & data tags.

​
Developing against production data

For many use cases, developing against production data is a practical and common approach. This is especially true for read-only applications built on data warehouses, SaaS services, or other data sources where there is no risk of corrupting operational data. Building against production avoids the need to duplicate data into lower environments and gives Clark access to real-world data for more accurate development and testing. As mentioned above, Hybrid customers should consider that data accessed in the Edit environment is sent to the Superblocks Cloud during development when determining whether to allow development on production data.