Integration Controls#
Integration controls determine which infrastructure connections each agent can use. They are configured per team as part of policies and apply to every agent in that team.
What integration controls do#
When an organization connects Kubernetes clusters, AWS accounts, GitHub repositories, or MCP servers to Lens Agents, those connections are available to the platform. Integration controls decide which of those connections each team's agents can actually reach.
Without integration controls, connecting a production cluster to the platform would make it available to every agent. Integration controls prevent that: you connect once, then selectively enable per team.
Connection types#
| Connection type | What you control | Example |
|---|---|---|
| Kubernetes clusters | Which clusters an agent can access via kubectl and the K8s API | Enable staging-us-east-1 but not prod-us-east-1 |
| AWS accounts | Which AWS connections are available for STS AssumeRole | Allow the SRE agent to use the production account; restrict the dev agent to sandbox |
| GitHub connections | Which GitHub integrations the agent can use | Enable the CI agent's access to myorg/infrastructure but not myorg/secrets |
| MCP servers | Which registered MCP servers the agent can call tools from | Allow access to the Jira MCP server but not the HR system server |
Configuration#
Integration controls are set per team. Each connection type (Kubernetes clusters, AWS accounts, GitHub connections, registered MCP servers) can be individually enabled or disabled for the team. Changes apply immediately to every agent in the team.
What happens at runtime#
When an agent requests access to a connection, the policy engine checks:
- Is this connection enabled for the agent's team?
- Does the agent's project grant access to this resource?
- Are there additional domain rules or credential bindings that apply?
If any check fails, the request is denied. Agents only see connections that pass all checks.
Integration controls and agent types#
Integration controls apply identically to all agent types:
- Desktop AI tools (Claude Desktop, Cursor, Copilot) connecting via MCP are governed by the team policy associated with the user's identity.
- External agents (LangChain, CrewAI, custom frameworks) are governed by the team policy associated with their agent token.
- Managed agents inherit their team's integration controls at creation.
The governance is the same regardless of where the agent runs.
Best practices#
Least privilege by default. Start with no connections enabled. Add the specific clusters, accounts, and repositories each team needs.
Separate production from development. Create distinct teams for production and development workloads. Enable production connections only on the production team.
Use projects for fine-grained scoping. Integration controls operate at the team level. For more granular access within a team, use projects to scope which infrastructure a subset of agents can reach.
Combine with domain rules. Integration controls govern which connections are available. Domain rules govern what the agent can do over those connections (HTTP methods, URL paths). Use both together for defense in depth.
Related#
- Policies — domain rules and HTTP restrictions that govern what can happen on enabled connections
- Orgs, teams, and projects — the hierarchy integration controls attach to
- Connections — the integration types themselves