Skip to content

Security Model#

Lens Agents assumes agents can be compromised and designs the platform so they can still do real work safely. This page covers the threat model, trust boundaries, and what the platform is honest about.

For the full technical detail, see the security whitepaper.

Threat model#

Threat How Lens Agents addresses it
Agent accesses unauthorized systems Default-deny networking. Domain allowlisting with HTTP method/path restrictions. Only explicitly approved systems are reachable.
Agent exfiltrates credentials Server-side credential injection via proxy. Credentials never exist in the agent's environment. Even a compromised agent cannot extract them.
Agent exfiltrates sensitive data PII detection and masking on the LLM proxy filters sensitive data (emails, phone numbers, credit cards, tax IDs, secrets, named entities) before it reaches the model provider. Per-policy configuration, fail-closed by default. Available to select customers.
Compromised agent escapes sandbox Sandbox isolation with privilege dropping, kernel-level network restrictions, and proxy-mediated egress.
Credential theft from storage Agent tokens stored as SHA-256 hashes. API credentials encrypted with AES-256-GCM.
Cross-tenant data leakage Org-scoped data with authorization checks on every request. Per-agent workspace isolation.
Runaway AI costs Spending limits at org, team, and agent level. Active enforcement — agents stopped when limits reached.
Unattributed agent actions Every action audited with actor identity (user or agent), action, resource, timestamp, and result.
Shadow AI / ungoverned agents Centralized tool registry — IT controls which tools and systems agents can access. Audit trail shows all governed agent activity.
Agent escalates its own autonomy Autonomy levels are behavioral controls. Hard security boundaries (sandbox, policy, credentials) enforce access limits regardless of autonomy level.
Subagent escapes parent boundaries Flat hierarchy (no recursive delegation). Each subagent has its own token, workspace, and policy scope. Independently auditable.
Agent modifies its own safety rules Agent Guide (operating manual with safety rules) is editable only by users — agents cannot modify it.

Trust boundaries#

Agent execution modes#

Where the agent process runs relative to the sandbox determines what Lens Agents can govern.

Mode 1 (agent outside the sandbox) — used by desktop AI tools and external agents. Lens Agents governs what happens when the agent reaches into enterprise systems through tool calls, but not what the agent does in its own environment between those calls.

Mode 2 (agent inside the sandbox) — used by managed agents, the local CLI tool, and platform-hosted sandboxes for external agents. The entire agent is contained — even if compromised, it cannot escape the sandbox boundaries.

See Agent execution modes for the full governance comparison. Both modes share the same sandbox technology, policy engine, credential isolation, and audit trail for governed actions.

Defense-in-depth chain#

Each layer adds protection independently:

  1. Authentication — validates identity on every request
  2. Visibility filtering — agents only see approved tools
  3. Authorization — checks team and project access
  4. Sandbox isolation — kernel-enforced isolation of agent processes
  5. Credential injection — server-side, never in agent environment
  6. Proxy enforcement — policy-governed outbound traffic
  7. Audit — every action recorded

What we are honest about#

Limitation Detail Mitigation
Default runtime is containers The sandbox uses Linux kernel primitives and is runtime-agnostic. The default deployment uses containers, which share the host kernel. Deploy the sandbox inside a MicroVM for VM-level isolation. The sandbox binary works identically regardless of runtime.
No seccomp profile Sandbox does not apply syscall filtering. Relies on privilege dropping + kernel-level network isolation. Agents run as unprivileged users with supplemental groups dropped. Network isolation prevents outbound bypass.
Asynchronous audit writes Audit entries may be delayed during database outages. Monitor audit trail completeness. Configure database high availability. Audit writes never block agent operations (availability over consistency).
Token revocation doesn't kill active sessions Revoking an agent token prevents new authentications. Existing connections continue until natural timeout. Sandbox idle timeout (30 minutes default) limits the window. For immediate termination, stop the sandbox directly.
Application-level tenant isolation Multi-tenant isolation uses org-scoped foreign keys and application-level authorization, not database row-level security. Every request is authorized against the authenticated identity's org and team membership. Data is org-scoped by foreign key constraints as a second layer.
Autonomy enforcement is prompt-layer Autonomy levels (1–5) are enforced via LLM system prompt instructions. Prompt injection can bypass autonomy constraints. The hard security boundary is the policy engine, sandbox isolation, and credential scope — enforced at the platform level regardless of what the LLM decides to do. Autonomy levels are a behavioral safety layer, not the security perimeter.

Multi-tenant isolation#

All organizations share the same database. Isolation is enforced at two layers:

Schema-level constraints: every org-scoped table has an org_id column with a foreign key. This constraint exists at the database level — it cannot be bypassed by application code.

Application-level authorization: every API call and tool execution checks the authenticated identity's org membership, team membership, and project access. There is no API endpoint that returns data across organizations.

Per-agent isolation: each agent workspace is scoped to its creator. Memory entries are scoped to the agent. Conversation threads are scoped to agent + user. Cross-agent data sharing is explicitly prevented.

Certifications#

Mirantis holds SOC 2 Type 1 compliance for Lens (K8S IDE) and ISO 27001 certification at the corporate level. Lens Agents is built and operated under the same control framework. A SOC 2 Type 2 audit covering Lens is under way. Lens Agents-specific attestation scope and timing are shared under NDA during evaluation.

Third-party penetration testing (annual), vulnerability bounty program (HackerOne), dependency scanning on every build, two-person code review. See Compliance for the full picture.