Data scoping
Policy mode answers whether a call may run; scope answers what it may see when it does. In Lunen, scope is decided by three mechanisms: whose credential the call runs on, what conditions the policy attaches to the tool, and which server the organization pointed the agent at in the first place.
Credential scope: organization or user
Every MCP server connection is either organization-scoped — one credential shared by the whole workspace — or user-scoped, where each member connects their own account under Connected Services and tools authenticate as that member.
User scope is the default posture for most catalog servers, and it is the stronger boundary: an agent acting for a member can only reach what that member’s own account can reach. A Slack search tool run by two different members returns two different result sets, because the credential — not Lunen — is what the upstream service authorizes.
Organization scope fits genuinely shared credentials — service accounts, org-wide installs like a GitHub App, or public data sources. What each server offers is fixed by its catalog entry; servers that support both show both options in the MCP Registry.
Policy conditions
Some tools accept conditions that narrow their reach beyond allow/approve.
The built-in web fetch tool, for example, takes an allowed domains list —
a policy can allow web_fetch unattended but only against the domains you
name. Conditions are part of the policy document, so they are versioned,
auditable, and apply to every agent the policy governs.
Separate environments are separate servers
An organization has exactly one enablement per catalog server — there is no “sandbox flag” on a connection. When you need production and staging kept apart, add them as two custom servers with distinct URLs and names. Two servers means two tool sets, two policy rows, and two credential sets — nothing is shared by accident, and the audit log shows which environment every call hit.
Two narrower forms of multi-connection do exist: a GitHub server can hold several organization-level App installations side by side, and an AWS connection records the specific account and role each member selected — with an admin-set allow-list of assumable roles.
What the agent inherits
An agent never holds a credential of its own. At each tool call, the runtime resolves the credential for that server at the appropriate scope — the calling member’s connection, or the organization’s — and the call is authorized, logged, and attributed to the person it acted for. Remove the credential and the access is gone; there is no copy inside the agent to revoke separately.