Skip to content

Lens Agents#

Run AI agents on your own infrastructure, with governance built in. Any agent, any model, your rules.

Lens Agents platform dashboard showing the Audit Trail view — event statistics, activity timeline, and detailed event log for an organization.

You install Lens Agents into your Kubernetes cluster with Helm. The control plane, the sandboxes agents run in, the database, and the audit trail all stay there.

helm install lens-agents oci://ghcr.io/lensapp/lens-agents \
  --set encryption.key="$(openssl rand -hex 32)" \
  --set config.publicUrl="https://agents.example.com" \
  --set sandboxIngress.host="sandboxes.example.com"

Then run an agent — from a terminal, from a script, or by asking one:

curl -fsS -X POST \
  -H "Authorization: Bearer $LENS_AGENTS_TOKEN" \
  -H "Content-Type: application/json" \
  https://agents.example.com/v1/projects/$PROJECT_ID/sandboxes \
  -d '{
    "image": "ghcr.io/acme/agent:1.2",
    "command": "python agent.py",
    "cpu": "500m",
    "memory": "2Gi",
    "policy": {
      "name": "nightly-refactor",
      "networkDefaultVerdict": "deny",
      "allowedDomains": [
        { "pattern": "api.github.com", "verdict": "allow", "transport": "upstream" }
      ]
    }
  }'
Create a sandbox in the production project from the image
ghcr.io/acme/agent:1.2. Run "python agent.py" with 500m CPU and
2Gi memory. Deny the network by default and allow only
api.github.com, through the platform proxy. Name the policy
nightly-refactor.
sandbox.yaml
image: ghcr.io/acme/agent:1.2
command: python agent.py
cpu: 500m
memory: 2Gi

policy:
  name: nightly-refactor
  networkDefaultVerdict: deny
  allowedDomains:
    - pattern: api.github.com
      verdict: allow
      transport: upstream
nexusctl sandbox create --project production -f sandbox.yaml

That agent can reach api.github.com and nothing else. Kernel-level nftables rules force every connection through the sandbox's egress proxy, and the proxy applies the domain rule. Neither layer asks the agent to cooperate, and every call it makes — allowed or denied — lands in the audit trail.

The policy above is embedded: private to this sandbox, created in the same call, deleted with it. For rules a whole fleet shares, write a policy once and attach it by name instead.


Start here#

  • Try it locally


    Stand up the full platform on a single-node cluster on your own machine and launch a first agent. Nothing to provision.

  • Install on Kubernetes


    The real thing: Helm values, activation, ingress, database, inference providers, and sandbox hardening.

  • Core concepts


    The architecture, the sandbox isolation model, and the identity model — in about ten minutes.

  • Sandboxes


    Create, run, exec into, and expose agents. Spec files, volumes, health checks, revisions, and rollback.


Three ways to drive the platform#

Everything below is available from all three, enforcing the same identity, RBAC, policies, and audit.

Surface Use it for
REST API CI, automation, and your own tooling. OpenAPI document served by every install, reachable with nothing but curl.
MCP endpoint Administering the platform through a coding agent, in natural language.
nexusctl Terminal work and scripting. Organised like kubectl. The binary ships with your deployment.

Plus the admin UI, for the things people would rather see than query.


What it does#

  • Connections


    Kubernetes clusters, AWS accounts, MCP servers, and HTTP APIs — reachable by agents, with credentials injected at the network boundary.

  • MCP


    Connect Claude Code, Cursor, or your own agent. Governed tools in, connector tools out, everything audited.

  • Administration


    Org policy ceilings, bindings, teams, API tokens, SSO, spending limits, and the audit trail.

  • Security


    Threat model, sandbox isolation, PII masking, EU AI Act, and compliance posture — the stack for a security review.


What makes it different#

Agents are principals, not sessions. A sandbox has its own identity, its own permissions, and its own audit attribution. It does not inherit the reach of whoever launched it. See Identity.

Credentials never enter the sandbox. The agent holds placeholders; real secrets are substituted at the network boundary. An agent that leaks everything it can read leaks placeholders. See Credentials.

Org policy is a ceiling, not a default. Write one org policy naming what the company permits at all, and no project can exceed it — however it is configured, by whoever configures it. See Policies.

Enforcement is in the kernel, not in the prompt. nftables gives an agent exactly one reachable destination: a proxy it does not control. There is no switch to turn it off. See Sandbox isolation.

Every call is recorded, denials included. "Why can my agent not reach this" and "has anything tried to reach something it should not" are both queries. See Audit trail.


Who it is for#

  • Platform and security teams rolling out AI agents across an organization, who need policy, audit, and identity for every agent action.
  • Engineers, SREs, and support teams whose AI tools need to reach real systems without bespoke integrations.
  • Teams building custom agents who need enterprise governance without rebuilding it.

Questions about a production deployment, air-gapped install, or hardened runtime class? Talk to us.