Skip to content

Desktop AI Tools#

The AI tools your engineers already use — Claude Desktop, Claude Code, Cursor, Microsoft Copilot, ChatGPT Desktop — connect to Lens Agents over the Model Context Protocol. Nothing changes about how people use their tools. What changes is that every action is governed, identity-attributed, and auditable.

Supported tools#

Lens Agents supports any AI tool with an MCP client. At launch the following tools are validated:

Tool Vendor
Claude Desktop Anthropic
Claude Code Anthropic
Cursor Cursor
Microsoft Copilot Microsoft
ChatGPT Desktop OpenAI

Any other MCP-compatible desktop or IDE-hosted AI tool can connect through the same mechanism.

Governance model#

Desktop AI tools operate under the user's SSO identity. The user signs in through their organization's OIDC identity provider (Okta, Entra ID, JumpCloud, or another OIDC-compliant provider) the same way they sign in to any other work application.

Once connected:

  • Every tool action is attributed to the user in the audit trail — not to a generic "agent" principal.
  • Access is scoped by the user's team and the policies attached to it. A user on the platform team sees their platform-scoped tools; a user on the support team sees theirs.
  • Personal credentials (kubectl config, AWS keys, GitHub tokens) are never exposed to the AI tool. The platform handles authenticated access through server-side credential injection.

What the tool gets access to#

Once connected through Lens Agents, a desktop AI tool can use any of the following, subject to the user's team policies:

  • Kubernetes — kubectl commands, pod management, log access, port-forwarding, via impersonated identity
  • AWS — CLI commands, EKS management, S3, EC2, and other services via STS AssumeRole
  • GitHub — repositories, pull requests, issues, and file management
  • Any HTTP system — CRM, ticketing, databases, internal APIs, SaaS services — governed through the policy-controlled proxy
  • Shell tools — sandboxed command execution with pre-installed CLI tools (aws, kubectl, gh, jq, yq, ripgrep, git, curl)
  • MCP registry tools — any additional tools from registered MCP servers

What a specific user's tool can reach depends on the team's policies and the connections configured for the organization.

Scope of governance#

Desktop AI tools run in Mode 1 — agent outside the sandbox (see Agent execution modes): the agent runs on the user's machine; tool execution routes through Lens Agents' sandbox.

Every tool call is:

  • Authenticated — against the user's SSO identity
  • Authorized — against the user's team policies
  • Sandboxed — executed inside a governed sandbox with default-deny networking
  • Credential-injected — upstream credentials are attached by the proxy, never visible to the tool
  • Audited — recorded with the user's identity, tool name, parameters, and result

Between tool calls, the AI tool operates locally on the user's machine with the user's local environment. Lens Agents governs tool execution, not the tool's internal reasoning.

For full governance of the agent process itself — including the agent's local filesystem access and network activity — see the local (CLI) execution mode.

  • Agent types — how desktop tools compare to external and managed agents
  • How it works — the full request flow and governance chain
  • Policies — controlling what each team's tools can reach
  • Audit trail — inspecting every action attributed to every user