Skip to content

Privacy & 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 — iptables 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 across a broad catalogue: emails, phone numbers, addresses, IPs, URLs, dates of birth, tax IDs, national IDs, account numbers, 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.

Configuration is per policy — each policy can enable masking, declare which PII types to mask, and choose whether to unmask responses. Masking is fail-closed by default: if masking cannot be applied, the request is blocked. Masking statistics (counts of each PII type masked) are recorded in the audit trail. PII values themselves are never persisted to disk; they live only in memory for the duration of the request.

Availability: PII detection and masking is available to select customers. Ask during evaluation for enablement details.

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 → LLM Proxy → Model Provider
                    ↑                        ↑
                    Credential injection     PII detection
                    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 Lens Agents LLM proxy, which applies PII detection and masking per policy
  6. The masked request is forwarded to the model provider

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 (available to select customers)
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

Reducing exposure further#

For organizations with strict privacy requirements:

  • Use AWS Bedrock where data stays within your AWS account and model providers do not retain your data
  • 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.