Enforcing Information Barriers When Agents Read Slack and SharePoint Through MCP Servers

Why barriers fail in the MCP read path

Information barriers, often called ethical walls, are built around human identities. A person belongs to a business unit, matter or group, and the source system limits what that person can see. An agent that reads Slack or SharePoint through an MCP server changes the shape of that model. The MCP server holds a credential, the agent holds a task, and the user's barrier membership may not be present at the point where content is fetched.

NIST SP 800-53 draws the relevant distinction. Information flow control regulates where information can travel within and between systems, in contrast to who is allowed to access it, and it applies without regard to subsequent accesses. Passing a source-system permission check is therefore not the same as keeping content on the correct side of a barrier. Once a tool response is returned, nothing in the source system governs what happens next.

NIST material on agentic security adds that agents often reuse user or service credentials embedded in context, memory or tool responses, that tokens can propagate across task boundaries and agents, and that agents can misuse legitimate tools through prompt manipulation, resulting in data exfiltration. These are general categories, but they describe the conditions under which a barrier is bypassed without anyone breaking a permission rule.

• Over-privileged connector: A shared service account or broadly scoped token lets the source evaluate the connector's access, not the requesting user's barrier membership.
• Permission-trimming gaps: Search and retrieval may return or rank content using an index or identity that does not reflect the user's restrictions.
• Container inheritance: If restrictions are set at a channel or site level, item-level results must be resolved against that inheritance on each read.
• Cached or summarized content: Context windows and memory stores can retain restricted content after the original retrieval.
• Downstream tool calls: Content read under one barrier can be passed to another tool, or into a response, that serves a different audience.

What source permissions and MCP authorization can and cannot settle

Treat the read path as an enforcement problem, not a connector-configuration problem. Configuration matters, and least privilege should be applied to restrict both visibility and accessibility of the connectors and tokens an agent uses. Scope tokens narrowly, prefer credentials that represent the user over a shared identity where the connector allows it, and inventory every point where a credential is held or passed: the MCP server, the token, agent memory and tool responses.

Configuration still answers only the access question. It does not decide whether a particular response, for this user and this task, may enter a model context or be handed to another tool. NIST zero trust guidance points in the same direction: access enforcement should rely on assigned permissions plus contextual information about each access request. A static grant is an input to the decision, not the decision.

The provenance of the connector is also a control point. NIST material names poisoned or impersonated tools and MCP connections as a way to propagate malicious logic, so knowing which MCP servers an agent may call belongs in the same policy.

Define barrier policy as attributes on users, sources and content

Write the barrier as attribute-based policy so decisions can be automated. NIST describes security attributes and information flow techniques as a basis for automated decisions about sharing and collaboration. Three attribute groups are enough to start.

User attributes must describe the delegating human, not only the agent. Carry both identities into each decision so that the agent's actions remain tied to an accountable person, and so records can tell agent activity from human activity.

• User and agent identity: Delegating user, barrier group or matter membership, and the agent identity acting for that user.
• Source attributes: Platform, workspace, channel or site, the MCP server being called, and the barrier classification of the container.
• Request attributes: Tool name, operation, query terms or target path, and the task the agent is performing.
• Content attributes: Barrier or matter labels on returned items, sensitivity classification, and whether content originated across a barrier.
• Destination attributes: Where the content will go next: model context, a user-facing response, memory, or another tool.

Specify the evidence an auditor will need

A regulator or auditor will want to see what the agent was permitted to read and what it actually read. Configuration exports show intent. Assessment procedures such as those in NIST SP 800-53A ask whether information flows are actually separated, so evidence should show enforcement outcomes, not only settings.

For each tool call, capture the delegating user, the agent identity, the MCP server and tool, the source container, the policy version applied, and the decision. For each response, capture the content attributes evaluated, the outcome (allowed, redacted, blocked or escalated), and the destination. For escalations, capture the reviewer and the result. These fields are inferences from the accountability and visibility goals in NIST agent identity work, which stresses linking users to agents and seeing actions taken and data generated.

Two gaps deserve attention. Evidence should distinguish content that was permitted from content that was returned, since a response can differ from what the call-time check expected. And it should cover summaries and memory writes, because content retained there can resurface after the original retrieval. NIST is still developing AI-specific guidance, including agent identity and control overlays for AI systems, so review the field list periodically.

Where Trussed fits

Trussed enforces policy in the execution path on individual tool calls and MCP interactions. The decisions described above, allow, redact, block and escalate for human approval, are enforced at runtime, not reviewed after the fact, and that enforcement generates audit-ready evidence mapped to frameworks including HIPAA, NYDFS and NIST. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

This guide stands without it. The central point is architectural: barrier enforcement has to sit where tool calls and responses are exchanged, because that is where the source system's authority ends and the agent's use of content begins.