Skip to content

Privacy and PII controls#

Lens Agents provides layered controls over sensitive data flowing between agents, enterprise systems, and model providers — credential isolation, domain controls, and PII detection and masking.

Control layers#

Credential isolation#

Credentials never exist in the agent's environment. They are injected server-side by the proxy at request time.

How it works:

  1. Admin binds a credential to a policy for a specific domain
  2. Agent makes an outbound HTTPS request to that domain
  3. The sandbox proxy intercepts the request via TLS interception
  4. Proxy generates an ephemeral TLS certificate and terminates the agent's TLS connection
  5. Proxy injects the credential as an HTTP header (Bearer token, API key, or custom format)
  6. Proxy establishes a new TLS connection to the destination and forwards the request
  7. Agent receives the response but never sees the credential

The ephemeral CA is ECDSA P-256, generated on sandbox startup, exists only in process memory, and is destroyed when the sandbox stops. It is never written to disk.

Even a fully compromised agent cannot extract credentials because they are not in the agent's process, memory, or environment variables.

Domain and HTTP controls#

Policies define which external systems an agent can reach:

  • Domain allowlisting — only explicitly approved domains are reachable (default-deny)
  • HTTP method restrictions — limit an agent to GET-only on a given domain
  • URL path restrictions — allow /v1/tickets/* but deny /v1/admin/*
  • Kernel-level enforcement — nftables rules block all traffic except to the local proxy, which enforces the policy

These controls limit what data an agent can access in the first place, reducing the surface area for data exposure.

PII detection and masking#

The LLM proxy detects and masks sensitive data in outbound traffic before it reaches the model provider. Detection combines two complementary mechanisms:

  • Pattern-based detection — fast regex matching: emails, phone numbers, URLs, IP addresses, dates, credit cards, IBAN, BIC/SWIFT, case IDs, customer IDs, API keys, private keys, JWTs, connection strings, AWS credentials, environment-variable secrets, and configuration secrets.
  • Named-entity recognition — an optional ML model detects PERSON, ORG, and LOCATION entities beyond what regex alone can catch.

Matching PII is replaced with structured placeholders (<PII_EMAIL_001>, <PII_PERSON_003>, etc.) before the request leaves the proxy. Responses can be rehydrated — the original values are restored in the agent's view — so workflows that depend on real data still work end-to-end, while data going to the model provider is never exposed.

Masking operates on linguistic content only — message content, text blocks, tool-result content, tool-call arguments, and system prompts. Structural metadata is never rewritten: identifiers, names, roles, block types, images, and signed thinking blocks pass through verbatim, in both the outbound request and the rehydrated response. The masker works from an allowlist of content fields rather than a denylist of sensitive ones, so an unrecognized field defaults to an auditable pass-through rather than a masking-induced failure of the request.

PII masking applies uniformly across all managed inference providers — the same detection and masking logic runs regardless of whether the backend is AWS Bedrock, Microsoft Foundry, Bedrock Mantle, or OpenAI. Masking covers both Anthropic and OpenAI wire formats, including the OpenAI Responses API input content. Embedding requests are deliberately exempt from masking — masking would corrupt vector representations. Embedding traffic is metered but not masked.

Configuration is per policy. A policy that carries a piiMasking block has masking on; setting the block to null turns it off. The block declares which PII types to mask and whether to unmask responses. Masking is fail-closed by default: if the masking stage cannot run, the request is blocked. There are two exceptions, both recorded in the audit trail as piiMaskingSkipped. A multipart request body — an audio, file, or image upload — cannot be parsed for masking and is forwarded unmasked; a body labelled with any other content type stays on the fail-closed path. An OpenAI realtime session is also served unmasked, with every audit record for that session flagged, so a policy that both selects openai and requires masking does not extend that requirement to voice. Masking statistics (counts of each PII type masked) are recorded in the audit trail as well. PII values themselves are never persisted to disk; they live only in memory for the duration of the request.

Data flow to model providers#

When agents retrieve data from enterprise systems and use it as context for LLM requests, that data flows to the model provider. Understanding and controlling this flow is critical for privacy.

What happens#

Enterprise System → Sandbox Proxy → Agent → Managed Inference Endpoint → Model Provider
                    ↑                        ↑
                    Credential injection     PII detection, metering,
                    Domain controls          and masking
  1. Agent requests data from an enterprise system (e.g., Kubernetes API, AWS, Jira)
  2. The sandbox proxy governs the request (policy check, credential injection)
  3. Data returns to the agent inside the sandbox
  4. Agent includes this data in its next LLM request as context
  5. For managed agents, the LLM request routes through the platform's managed inference endpoint, which applies PII detection and masking per policy
  6. The masked request is forwarded to the model provider

Usage metering, budget enforcement, and PII masking are properties of traffic routed through the managed inference endpoint. Managed sandboxes are provisioned to use this endpoint by default. Operators guarantee full coverage by denying direct access to provider hosts in policy — ensuring no LLM traffic bypasses governance.

Controls at a glance#

Control What it addresses
Domain allowlisting Limits which systems agents can access — reduces data surface
HTTP method/path restrictions Limits what agents can do on allowed systems
Credential isolation Prevents agents from exfiltrating authentication secrets
PII detection and masking Filters sensitive data out of LLM requests across all managed providers
Provider host deny in policy Guarantees all LLM traffic routes through governance (metering, PII masking, budgets)
Self-hosted models Keeps all data on your infrastructure — no external model provider
AWS Bedrock Data stays in your AWS account; providers do not retain
Microsoft Foundry Data stays in your Azure tenant; per Azure data-handling terms

Reducing exposure further#

For organizations with strict privacy requirements:

  • Use AWS Bedrock or Microsoft Foundry where data stays within your cloud tenant and model providers do not retain your data
  • Deny direct provider access in policy to guarantee all LLM traffic routes through the managed inference endpoint's governance controls
  • Tighten domain rules to limit which systems agents can query
  • Use HTTP path restrictions to limit agents to specific API endpoints (e.g., read-only access to non-sensitive resources)
  • Deploy self-hosted to keep all platform data on your infrastructure

Self-hosted model integration (vLLM, Ollama, any OpenAI-compatible endpoint) is configured per evaluation engagement — tell us during onboarding if your deployment requires it.

Audit and visibility#

The audit trail records what data agents access:

  • Forward proxy events — destination domain, HTTP method, path, status code, bytes transferred
  • LLM proxy events — model, token counts (input/output/cache), cost, prompt metadata, PII masking statistics
  • MCP tool calls — tool name, parameters, result
  • Shell commands — command text, exit code

This provides full visibility into what data flows where, enabling investigation and compliance reporting.