Manager stays interactive

An account that can actually use the interactive manager UI is refused on the remote channels: its token does not work on the control API or the MCP connector. A leaked or mis-issued token on a live manager account is the classic accidental-grant vector - this rule closes it, so remote automation always runs as a deliberately created agent account with only the capabilities it needs.

How the gate decides

"Can use the UI" means both of:

• the account holds the manager ui capability through a group, and
• interactive login is enabled on the account.

If both are true, any token request to the control API or MCP is refused with an explanation, and the refusal is audited. An account with interactive login disabled is a deliberate agent account: its token honours its own api/mcp capabilities regardless of which groups it also sits in.

Introspection is exempt - whoami and describe-capabilities answer for any authenticated token, so a refused client can always learn what it is and why.

Groups keep the two worlds apart

A single group may not combine manager UI access (ui) with a remote channel (api/mcp); the Groups page and the users CLI refuse the combination and tell you to keep interactive and remote access in separate groups. The transport gate above remains the hard enforcement for unions across groups.

Setting up remote automation

Create a separate account for the agent: put it in a group granting api or mcp plus the action capabilities it needs, and leave interactive login disabled. The manager's Users page and lazysite-users.pl both build such accounts directly.