Skip to content

Local (CLI) Execution#

The lens-agents CLI runs AI agents locally in sandboxed containers — on an engineer's laptop, a CI runner, or a shared workstation. It is the third way, alongside desktop AI tools and managed agents, to operate an agent under Lens Agents governance.

Why local execution#

Teams that want the strongest isolation — or that cannot send workloads to a hosted environment at all — run agents locally under the CLI. Each sandbox is an isolated container with:

  • Default-deny networking — only domains explicitly allowed by the composed policy are reachable.
  • Proxy-mediated egress — all outbound traffic passes through a per-sandbox proxy that enforces policy, injects credentials, and writes audit events.
  • Privilege dropping — the agent process runs as an unprivileged user inside the sandbox; it cannot escalate.
  • Ephemeral workspace — the sandbox workspace is discarded when the container exits.

The isolation model is identical to the one used for managed agents. The difference is where the sandbox runs: locally, on your hardware.

The governance parity#

Local execution is governed by the same concepts as cloud execution:

  • Policies determine which domains, integrations, and credentials the agent can reach.
  • Credential bindings attach credentials to policies; the sandbox proxy injects them on the agent's behalf.
  • The audit trail records every tool call, proxy decision, and credential injection from local sandboxes with the same fidelity as cloud ones.

A compromised agent inside a CLI sandbox has no greater reach than a compromised agent inside a managed-agent sandbox. The platform's trust model is runtime-agnostic.

Policy composition (local)#

Agents running locally use composable policies. Multiple policies can be selected and merged into a single resolved policy at runtime — one for Anthropic API access, another for GitHub, another for a customer's internal API, and so on. Conflicts are surfaced at composition time rather than silently resolved.

When to use local execution#

  • Evaluating the platform — run an agent against a real workload from your machine before committing to cloud deployments.
  • Air-gapped or restricted environments — where agents must not talk to a hosted control plane at all, or where only specific, audited egress is acceptable.
  • Per-engineer agents — where the agent's workload is tied to a specific developer's work context (a repo, a local cluster, an in-progress task).
  • CI and batch jobs — ephemeral agents that run on build infrastructure with policy and credential management handled the same way as everywhere else.