Consider an analyst who asks an AI agent to summarize a week of channel traffic. The analyst is cleared for three of those channels. The agent, running under a shared service account, can read many more.
The summary comes back fast and accurate. It is also a data spillage event, and nothing in the audit log will call it one.
Agents have earned their place in the workflow
Nobody puts an agent in that position for sport. They do it because agents work.
Mattermost’s own engineering team delegates tickets to an autonomous coding agent called Matty Code. It handled three tickets in March and now averages more than 40 a month, under engineer oversight. In four months, it has become a top-three contributor to the main Mattermost repository. (Read more about Matty Code.)
Operations show the same pattern. Consider a regional water-treatment plant at shift change. The outgoing supervisor has alarms in various states of acknowledgment, an open maintenance window, and two work orders. A custom prompt in Mattermost Agents V2 reads the channel and produces the same structured handover brief every shift, for every supervisor. The incoming supervisor is operational in minutes, and the prompt no longer leaves with whoever wrote it.
The challenge is no longer whether agents belong in mission workflows. It’s what they are allowed to see and do once they’re there.
An agent without limits is a spillage path
Most access models assume a human with a role, a set of channel memberships, and a physical location. Agents break each assumption. They act at machine speed, they run in more places, and they inherit whatever access their integration was handed on day one.
Matty’s rollout offers a useful parallel. The team found that most early failures came from poorly scoped work, not from the model. The fix was to treat the agent like a junior developer and give it a well-scoped ticket. Data access follows the same logic: an agent can only be as well-scoped as the access it was given.
A shared service account is the weak point. It holds its own rights and access, and someone has to keep them aligned with the people using it. When the two drift apart, an auditor will ask who approved what the agent read or acted upon, and the log may not have an answer.
Multiplayer tool calling is one piece of the answer
Multiplayer tool calling in Agents V2 puts a human’s access in front of each call. The person who asks the agent to act is the initiator from beginning to end, scoped to what that person can see and do. Two analysts in the same channel can get different search results because their access differs. The limits matter. External MCP servers without per-user authentication run on the agent’s configured credentials with various guardrails that attempt to restrict the request and response after the fact.
The model is the other piece of the answer
Every agent request carries context, and the model that reads it is part of the boundary. If requests and responses route to an external endpoint, sensitive context leaves, however well the tool call was approved.
This is where a model partner matters. Cohere foundational models can be deployed privately, including air-gapped environments, so inference stays in infrastructure you control. Using Cohere’s North 2 to power Mattermost Agent workflows gives you agents that carry the user’s permissions, a model within your boundary, and end-to-end auditing to meet your legal, compliance, and security needs.
Running inference inside your boundary also means owning the compute and the operations that come with it. For many programs that is the point, but it all points back to the same question: can you say where your data goes?
Five questions to ask before the next agent goes live
- Where do requests and responses get routed, and does that path stay inside your controls?
- For each tool, whose credentials does the agent use, and who keeps them aligned with the people it serves?
- Which tool results should stay out of shared context, and who decides?
- Can policy see rank, clearance, device, and network, or only identity?
- Can you attribute every agent action to a named person, in the channel where it happened?
If question two has no clear answer, start there. Service accounts and external tool connections are where the exceptions to user-scoped access live.
Also in Mattermost v12: access controls and data movement
Model sovereignty is just one of the pillars that supports Mattermost v12. Also in v12 are advancements in our Attribute-based Access Controls (ABAC) using Hierarchical Attributes and Environmental Attributes, allowing you to evaluate a user’s current state and rank attributes in policy enforcement. This drives the fine-grained controls the agents inherit from their users.
Finally, with the Cross Guard plugin, high security environments can connect through accredited cross-domain infrastructure to selectively share critical information in a timely but policy-compliant manner. Together, these three pillars expand your controls and where they apply, making the infrastructure customers have already invested in usable where teams collaborate.
v12 is available now. For air-gapped and sovereign configurations, contact your account team or get started.
