Multiplayer Tool Calling for Secure Operations: Who Approves, Who Sees, Who Runs the Tool
A six-person Cyber Protection Team is sixty minutes into an active defensive response on a partner network. The lead analyst is in ~ir-active with the rest of the team. The mission network has no internet connection: local LLM, on-premises Mattermost, and an MCP server fronting an internal threat-indicator database. Tool calls touch real systems during a real operation.
The lead @mentions the team’s IR agent: “Analyze these source indicators and assess threat-actor TTP alignment.” The agent proposes calling indicator_lookup against the indicator database. An approval card appears on the lead’s screen with the indicators it wants to query.
The lead reviews the scope, accepts, and the call returns raw IOC data, including source-sensitive detail that should not be exposed to everyone in the channel or preserved in channel scrollback. After the tool returns, the lead sees one more decision: Share or Keep Private. They click Keep Private. That keeps the tool result out of the shared thread context. The team can see that the tool ran, but the returned data does not become context that other participants, or the agent’s channel-visible follow-up, can read.
That is the point of multiplayer tool calling in Mattermost Agents V2. The team works in one channel, the analyst who started the work stays accountable for the tool call, and sensitive output only becomes shared thread context when that analyst chooses to share it.
Approve, then decide
Secure operations need two different decisions that often get treated as one. First: should the tool run? Second: should the result be allowed into the shared thread context?
In the CPT scene, the lead analyst is the initiator. They asked the agent to do the work, so they are the only person who receives the Accept or Reject controls for the proposed indicator_lookup call. Other channel members can follow the status of the work, but they are observers until the initiator chooses what, if anything, to share.
Once the call finishes, the lead can share the result if it belongs in the operational record, or keep it private when the returned data includes information other people in the channel are not allowed to know or see. Kept-private tool content is excluded from the shared thread context, which means it is not available to other participants and is not fed into a channel-visible agent response.
DMs naturally collapse this flow. One human asks, one human receives the result, so there is no separate channel disclosure step. The multiplayer model exists for the harder case: shared awareness and containment in the same conversation.
Visibility without borrowed authority
The same pattern fits a fusion cell. An all-source analyst runs AI-assisted research in ~collection-active while a section chief watches the thread. The chief needs to know what was queried, what tools ran, and what was shared with the cell. They do not need the analyst’s execution permissions.
Mattermost Agents V2 draws that boundary narrowly:
- The initiator owns the action. Approval, credential identity, and disclosure start with and stay with the human who called the tool.
- Observers keep situational awareness. Channel members can see tool status and coordinate next steps without inheriting execute authority.
- Sensitive parameters stay scoped. Pending and kept-private calls do not expose raw arguments to observers.
- The channel follow-up is deliberate. Shared results can become part of the thread context and channel record; kept-private results stay out of shared context.
That gives the section chief a clean way to direct the work. They can post, “widen the date range; there is a reporting gap from period X; re-run.” The analyst takes the guidance, invokes the agent again, and remains the accountable actor. Mission-command-level visibility does not have to become borrowed execute authority.
Credentials follow the accountable actor
The approval model matters because credentials matter. Per-user OAuth tools run against the initiator’s connected account. The embedded Mattermost MCP server tools, including search_posts and search_users, run under the initiator’s own Mattermost session and are scoped to what that person can already see. Two analysts in the same channel can get different search results if their channel access differs.
External MCP servers without per-user auth run as the agent’s configured credentials, bounded by that upstream account’s permissions. That is a different trust model, and operators should treat it as one. The important property is that the identity path is explicit and auditable: the tool call maps back to the human who started it, or to the agent credential an administrator deliberately configured.
Policy that fits the mission
Admins still decide which tools deserve which posture. The three policies are simple enough to explain to an operator without turning the channel into a configuration guide:
ask: Require the initiator to approve each call. Use this for tools with side effects, sensitive data, or unproven operational scope.auto_run_in_dm: Let the tool run automatically in DMs, but require approval in channels. This is a conservative default for read-only tools that are useful one-on-one but still deserve a human checkpoint in shared spaces.auto_run_everywhere: Let the tool run automatically anywhere. This also skips the Share/Keep Private step, so results post directly. Reserve it for tools whose output is always safe to share.
For a CPT, a fusion cell, or a tiered SOC, that last sentence is the operational rule. Low-risk utilities can become invisible plumbing. Anything that can expose mission data, touch a production system, or confuse attribution should stay visible and approved.
Automation still fails closed
Not every agent turn starts with a person typing in the channel. A workflow might route a finding into a thread an agent is watching, or a bot might post an event that triggers an agent response.
In that case, Mattermost does not walk backward through the automation chain looking for a human to approve the call. The bot is the conversation owner. To avoid pending approval cards that no person can resolve, bot-triggered channel flows only receive MCP tools configured auto_run_everywhere; built-in tools are filtered out of those flows entirely.
That is intentionally restrictive. If a tool should run from automation in a shared channel, an administrator has to make the explicit decision that its output is safe to run and safe to post without a human in the loop.
Back in ~ir-active
The lead’s indicator_lookup returned raw IOC data. The lead chose Keep Private because some of that data should not be visible to everyone in ~ir-active. The rest of the CPT saw that the call happened, but the tool result stayed out of shared context. If the team needs a broader briefing, the lead can share only the information that is appropriate for that audience or rerun a narrower request whose output is safe to put in the thread.
When the after-action review comes later, the conversation record shows one human who initiated the call, approved the call, and made the disclosure decision. That is the property secure teams need from a multi-user agent surface: not just collaboration, and not just control, but collaboration with control still attached to the person doing the work.
If you are evaluating Mattermost Agents V2 for defensive cyber, intelligence, or critical-infrastructure operations, start with that boundary:
- Can the team see enough to coordinate?
- Can sensitive output stay contained?
- Can authority be traced to the person who started the work?
Multiplayer tool calling is designed to make the answer yes in the channel where the mission is already happening.
