Skip to content

External Agents#

Custom agents built with any agent framework — Claude Agent SDK, LangChain, CrewAI, AutoGen, or an in-house framework — can connect to Lens Agents and inherit the same governance as desktop tools and managed agents: identity, policies, credential isolation, spending controls, and audit.

How external agents connect#

External agents connect to Lens Agents over the Model Context Protocol. A compatible MCP client — built into most modern agent frameworks, or available as a standalone library — points at a per-organization endpoint and authenticates with a scoped agent token. The agent then discovers and calls tools through standard MCP requests.

Every tool call passes through the full governance chain: authentication, authorization, sandboxed execution, credential injection, and audit recording. The governance model is identical to the one applied to desktop tools and managed agents.

Supported frameworks#

Lens Agents supports any framework that has an MCP client. At launch the following are validated:

Framework Language MCP integration
Claude Agent SDK Python MCP servers configuration
LangChain Python / TypeScript MCP toolkit integration
CrewAI Python MCP tools integration
AutoGen Python MCP tool wrapper
Any MCP-compatible framework any Standard MCP client

MCP client libraries exist for Python, TypeScript, Go, Rust, and other languages. The connection is the same regardless of framework.

Identity#

Each external agent gets a dedicated agent token. The token is the agent's identity:

  • Scoped to a single organization, assigned to a specific team with project-level access grants.
  • Every action is attributed to the agent's token in the audit trail — separate from any human user, separate from any other agent.
  • Tokens are revocable. Revocation takes effect immediately; in-flight calls complete, no new calls authorize.

External agents are first-class principals in the platform's identity model, not anonymous traffic attributed to a human.

Execution modes#

External agents can run under either of two governance postures:

  • Mode 1 — agent outside the sandbox (default) — the agent runs on your infrastructure; tool execution routes through a Lens Agents sandbox. Tool calls, proxy egress, credential injection, and audit are governed. The agent's internal logic — its reasoning, its local filesystem, its local network if any — runs outside the sandbox.
  • Mode 2 — agent inside the sandbox — the entire agent process runs inside a Lens Agents sandbox (either the platform-hosted sandbox used for managed agents, or a local sandbox via the CLI). Network isolation, credential injection, and audit apply to every outbound request the agent makes, not just its tool calls.

Pick the mode that matches your threat model and operational constraints. See Agent execution modes for the full governance comparison.

What external agents can reach#

Once connected, an external agent has access to the same catalog of tools and connections any other agent does, subject to its team's policies:

  • Kubernetes, AWS, GitHub — native integrations with specialized credential handling
  • Any HTTP system — through the policy-controlled proxy
  • Shell tools — sandboxed command execution with pre-installed CLI tools
  • Registered MCP tools — additional tools from upstream MCP servers registered by administrators
  • Cost and audit queries — the agent can inspect its own spending and action history

Tool availability depends on the connections and policies configured for the team the agent belongs to.

  • Agent types — how external agents compare to desktop tools and managed agents
  • Agent tokens — identity model for external and managed agents
  • Policies — what controls access
  • Audit trail — inspecting every action by every agent
  • MCP — the protocol agents use to connect