What policy means today#
Policy in LumenFlow is a fixed set of controls that you turn on and tune. There is no policy language you write yourself. You cannot write a rule such as "auto-approve this kind of email when it is cheap and inside working hours", and nothing evaluates conditions you write, such as time of day, day of week, recipient or token count. There are no schedules, exceptions or rule priorities. If you need that, it is not available today.
What is enforced today is below. The approval, admission and refusal controls apply at the moment Sidekick calls a tool, before the call runs. The one exception is the check on MCP results, which applies when a result comes back.
Trust level and approval-required tools#
A workspace has one autonomy policy, changed in Settings → Rules by a workspace owner or admin. It has two parts: fail-closed mode, and a list of tools that need approval before they run. The trust levels are presets over those two parts.
| Level | Fail-closed | Tools that need approval |
|---|---|---|
| Supervised | On | Every built-in Sidekick tool, reads as well as writes |
| Balanced | On | A fixed set of high-impact tools, including sending email, cancelling tasks and initiatives, deleting channels and routines, forgetting memory, changing the workspace model, disconnecting an integration, issuing service tokens, inviting members and changing the policy itself |
| Autonomous | Off | None |
| Custom | Either | Any other combination, such as a list you edit tool by tool |
With fail-closed on, risky actions on connected apps, such as sending, forwarding or deleting email and cancelling calendar events, also need approval, whichever tools are on your list. A workspace with no saved policy starts fail-closed, and Sidekick falls back to fail-closed if the policy cannot be read. A change is picked up on the next request.
Approvals#
When a call needs approval, Sidekick stops and an entry appears in the Approvals inbox. The call does not run until a workspace owner or admin approves it. A rejected request means the call is refused, and a request that is still pending keeps the call held.
MCP server admission#
An MCP server you register cannot be used until it is admitted.
- A workspace owner or admin registers the server.
- LumenFlow reads the tools the server offers and holds them as a candidate. Nothing on the server can be called yet.
- An owner or admin admits the candidate. For each tool they set a risk class (read, write or destructive), an approval policy (none, per invocation or always operator), a data classification and limits on results: allowed content types and size. They also record a retention period. It is stored with the decision but is not applied to the results of these servers. The decision is recorded with who made it and why.
- Only admitted tools can be called. A tool the server offers that was not admitted is refused.
Admission is done through the admission API
(POST /api/v1/sidekick/mcp-servers/{id}/admission). The dashboard has
no admission controls, and the Enabled switch in Settings →
Connections cannot admit a server.
A tool admitted with an approval policy other than none needs approval on every call, whatever the trust level. A tool admitted with none is not held by admission itself, though the trust level and the checks below still apply to it. After a call returns, its result is checked against the admitted content types, size limits and output schema. A result that does not conform is refused and is not passed to Sidekick, but the call has already run on the server.
If a server's tools change after admission, LumenFlow quarantines and disables the server the next time it reads them, and it stays off until an owner or admin readmits it. Owners and admins can also quarantine or revoke a server. See MCP servers for registration.
Checks that do not depend on trust level#
These apply on every trust level, including Autonomous:
- Known tools only. A tool name Sidekick does not recognise is refused outright. It is not sent for approval.
- MCP approval policy. A tool admitted with an approval policy other than none needs approval on every call.
- Untrusted content. While Sidekick retains an untrusted-content marker from a connected app or an MCP server, it requires approval before calling a built-in tool classified as write or high-impact, any MCP tool not recorded read-only in its admitted manifest, or any connected-app tool not declared read-only. An MCP tool counts as read-only only when the vendor's annotations pinned at admission say so (read-only true, destructive not true) and the operator did not classify it as write or destructive; a change to those annotations quarantines the server until it is re-admitted. A connected-app action nobody has classified counts as consequential.
How checks combine#
A call has to clear every check that applies to it. A refusal, or an approval that is still pending, at any check stops the call, and nothing set elsewhere can override it. A permissive trust level does not undo an MCP tool's approval policy, and an approval does not let through a call that another check has already refused. There is no rule priority, because there are no user-written rules to rank.
Organization fleet configuration#
An organization admin can stage and publish a fleet configuration from the Bridge or the API. It has two parts: requirements, a floor that lower levels cannot loosen, and defaults, a baseline that lower levels may change. It can set five things: sandbox mode, approval policy, an allowlist of MCP servers, permitted network domains and permitted commands.
The floor only tightens. Layers resolve in order: cloud, then device management, then the local system. A lower layer can add restrictions or remove entries from an allowlist, but it cannot relax a locked value or add back an entry that a higher layer left out. A configuration that fails validation is rejected when it is staged.
Runtimes fetch the active configuration with a workspace API key; LumenFlow does not push it. Publishing records a receipt for each workspace, and a workspace can acknowledge it, so you can see which workspaces are current and which are stale.
Publishing a fleet configuration does not change what hosted Sidekick asks approval for or which MCP servers it can use. Hosted approvals follow the workspace autonomy policy above, and hosted MCP use follows MCP server admission.
Previewing a trust level#
On the Trust page of the dashboard, an operator can pick a trust level and a time window to replay recent tool calls against it and see how many it would allow, pause or block. Replay is read-only and changes nothing. The live policy changes only in Settings → Rules.
Not available yet#
- Rules you write yourself, with conditions, schedules, exceptions or priorities, as described at the top of this page.
- Blocking a tool. Settings → Rules shows a Block control for each tool, but a block is not saved or enforced yet. Work on this is in progress. Until it lands, do not use Block to hold a tool back: it can also clear that tool's approval requirement.
- Approval and block toggles for some connected-app actions. For some connected-app actions, the name that Settings → Rules saves does not match the action the connector runs, so a toggle on that row can have no effect. Work on this is in progress. Until it lands, do not rely on a Rules toggle to hold a connected-app action back.