Preventing an AI agent from posting client NPI to Slack through an MCP server

How NPI reaches Slack through a tool call

An MCP server lets an agent discover and call external capabilities. For Slack, the relevant capability is any tool that writes content into a workspace, usually by taking a target channel and a message body. The agent decides both values at call time, from whatever is in its context.

Three paths put NPI into those arguments. The first is direct inclusion: the agent copies a name, account number or other client identifier from a record into a status update. The second is summarization: the agent condenses a retrieved document or case file, and the summary carries identifying details even though no field was copied verbatim. The third is forwarded tool output: a result from a database, CRM or document tool is passed into the message with little transformation. These categories are a practical working taxonomy, not a formal standard.

Prompt injection adds a fourth route. NIST identifies manipulation of generative AI systems as one of the most concerning vulnerabilities, and a retrieved document can carry instructions to post its contents somewhere. NIST also advises against trusting prompt instructions or artefacts from users or other agents. For this problem, that means the arguments of every outbound call should be treated as untrusted input, regardless of what the system prompt says.

Why the posting step needs enforcement in the path

Prompt instructions can be overridden by injected content or simply misapplied by the model. Workspace permissions answer who may post and where, not whether this particular message contains a client's nonpublic information. Review by DLP tooling or people after the post means the message has already been delivered, possibly to guests or external participants, and cleanup becomes incident response.

Enforcement at the tool call closes that gap because the content and the destination are both known at the moment of decision, and the call has not yet happened. This is the same idea as reviewing content before posting to a public system, a control NIST describes in a different context. Applying it to agent-initiated Slack messages is a design choice, and it fits because the agent is acting without a person reading the message first.

Trussed enforces policy in the execution path across agents, tools and MCP servers, on individual tool calls. Decisions are enforced at runtime, not reviewed after the fact.

Define the policy

Write the policy so that destination and content are evaluated together. A default-deny posture on channels keeps the content rules from carrying the whole burden.

• 1. Classify destinations: Resolve each target channel to a class such as private internal, broad internal, contains guests, or shared externally. Unlisted channels are denied by default.
• 2. Detect NPI in arguments: Scan the message body and any other free-text parameters. Combine pattern matching with checksum validation, client identifier lookups, and entity or classifier detection, and attach a confidence level to each finding.
• 3. Map findings to decisions: No NPI in an allowlisted channel is allowed. Confirmed NPI in a guest or externally shared channel is blocked. High-confidence NPI in an approved internal channel is redacted or blocked.
• 4. Route ambiguity to approval: Low-confidence findings or unusual targets go to a human approver, with the call held until a decision is made.
• 5. Cover every write path: Apply the same rules to replies, edits, file uploads and any other tool that places content in Slack.
• 6. Version the policy: Give each policy a version so every decision can be tied to the rules in force.

Handling ambiguity, false positives and redaction

Detection is probabilistic. A nine-digit number may be an identifier or an order code, and a name in a summary may be a client or a public figure. Strict patterns miss paraphrased details, while broad detection blocks legitimate work. Set thresholds per destination class: tighter for channels with guests or external members, looser for small private channels approved for client work.

Redaction suits messages where the sensitive element is incidental, such as an account number in an otherwise useful status line. Replace values with typed placeholders so the message stays readable, and return a clear result to the agent so it does not retry with a reworded version of the same content. Blocking suits cases where the destination is wrong regardless of content.

Escalation is for the middle ground. Keep the approval request short: the proposed message, the findings, the target channel and the reason the call was held. Track approval rates and overturned blocks, and use them to adjust thresholds. A high override rate signals noisy detection, not a reason to remove the control.

Guidance from NIST points to approval or confirmation flows for state-changing actions such as POST requests, which describes posting to Slack well.