Skip to content

Data sovereignty#

Lens Agents installs into your own Kubernetes cluster. There is no hosted control plane, so data residency is not a setting you pick from a list — it is wherever you installed the platform.

Where the platform runs#

Component Where it runs
Platform server — API, auth, policy enforcement, audit Your cluster
Sandboxes agents run in Your cluster
PostgreSQL — configuration, policies, credentials, audit trail Your cluster, or a managed database you point it at
Egress proxy — the only route out of a sandbox Your cluster

See Install on Kubernetes for the deployment itself.

What data stays where#

Platform data#

Agent configurations, policies, team structures, audit trail entries, and workspace files are stored in the platform database — the one in your infrastructure.

Agent-to-system traffic#

When agents connect to your Kubernetes clusters, AWS accounts, or any HTTP system, the traffic flows between the sandbox and your systems. The platform does not store the content of these connections. Audit metadata — destination, method, status code, timestamps — is recorded; response payloads are not.

Model traffic#

Requests that go through managed inference route through the platform's proxy, which extracts usage metadata (token counts, cost) for spending limits and audit. Prompt content is forwarded to the model provider you configured and is not persisted by the platform beyond an agent's own conversation history.

Traffic an agent sends straight to a provider domain, where policy permits it, does not pass through the platform at all.

Credential storage#

API credentials are encrypted with AES-256-GCM and stored in the platform database. Tokens are stored as SHA-256 hashes. Both are in your database.

What leaves your cluster#

Four things. You control all four.

Activation, once. A fresh install registers itself with Lens Cloud to receive an OAuth client and a license JWT. It posts an installation record — the activating Lens ID and the install's public URL. See Activation.

Licence refresh, periodically. Partway through a licence's lifetime the install fetches a re-signed one and reports its platform version. The licence itself is verified offline against a public key bundled in the image, so this call is fail-soft: if Lens Cloud is unreachable the install keeps working on the licence it holds.

End-user login, if you keep the default. oidc.issuer and oidc.jwksUri default to the Lens Cloud realm, which is what makes Lens ID sign-in work out of the box. Point both at your own identity provider and authentication never leaves your directory. See SSO.

Product telemetry, unless you turn it off. Released images carry a Lens-operated OTLP endpoint, so a default install sends product telemetry — identifiers, counts, event names, and the names of tools an agent calls, never conversation content, prompts, tool arguments, credentials, or policy contents. Set telemetry.endpoint to route it to a collector you run, or telemetry.enabled=false to send nothing. An empty telemetry.endpoint is not off; it falls through to the image default. See Product telemetry.

GDPR#

GDPR requirement How Lens Agents supports it
Lawful basis Data processing limited to what is necessary for platform operation
Sub-processors None for the platform itself — you run the stack. Your model provider is your own contractual relationship
Right to deletion Agent data can be deleted per agent or per user. Audit trail retained per your regulatory requirements
Data portability Audit data exportable through the API
Data minimization The platform stores configuration and audit metadata; agent-to-system payloads are not persisted
Retention and backup Entirely your policy, on your database

Because the platform runs on your infrastructure, most of the questions a DPA usually answers are answered by your own controls instead.

Regional and air-gapped requirements#

Requirement How to meet it
EU data must stay in the EU Install in an EU region or an EU data centre
No data in US-controlled infrastructure Install on-premises or in a non-US cloud provider
Specific country requirements Install in the required jurisdiction
Air-gapped environment Install with no external connectivity. Activation and Lens ID login both need scoping in advance — talk to us

Model provider data flow#

When agents use a model, prompt data flows to that provider. That is true of any deployment, because the model runs externally.

Managed inference supports four backends:

  • AWS Bedrock — data stays within your AWS account and region, and providers do not retain it, per AWS Bedrock data-protection terms.
  • Microsoft Foundry — data stays within your Azure tenant and region, per Azure's data-handling terms.
  • Bedrock Mantle — Claude and GPT off the same Bedrock key, under the same AWS terms.
  • OpenAI — prompts reach OpenAI's platform, under OpenAI's own data-handling terms. This is the one backend that does not keep prompt data inside your own cloud tenancy. Where that is not acceptable, inference.openai.baseUrl points the backend at any OpenAI-compatible endpoint instead — a gateway or self-hosted server inside your boundary — and data handling then follows whatever you run there.

Additional or self-hosted endpoints are configured to customer requirements. Contact us during onboarding if that is a requirement.

PII masking runs before a prompt leaves the platform, so what reaches the provider can be less than what the agent wrote.