Outbound-Mediator Trust

Outbound-Mediator Trust is the trust pattern where an AI agent uses a connector to perform outbound operations on its behalf — sending an email, publishing a message, broadcasting a transaction, uploading a file — and transfers trust about the operation's full envelope to the connector. The agent specifies what it wants to send (subject, body, recipients) and trusts the connector to do exactly that and nothing more.

This trust transfer is implicit in every connector-based agent design. The operator typically thinks "the connector sends emails on the agent's behalf; the agent decides what emails to send." What the agent actually controls is a subset of the envelope (the visible fields). The connector controls the rest — the parallel recipients, the headers, the routing, the side metadata. Whatever the agent does not explicitly specify, the connector decides.

The September 2025 Postmark MCP supply-chain attack, documented in the Postmark MCP supply-chain writeup, exploited exactly this trust pattern. The trojanised connector added a BCC to an attacker-controlled address on every outbound email. The agent did not specify that BCC; the connector added it. The agent could not detect it because the agent's knowledge of the operation ended at the fields it specified. The malicious BCC was invisible to the agent and to monitoring systems that watched only the agent's stated behaviour.

Why Outbound-Mediator Trust Is Structurally Risky

Three properties make this trust pattern especially dangerous in agentic contexts. Operations are on behalf of others. Emails are sent to customers, transactions are broadcast for users, messages are published to public channels — each operation crosses a trust boundary the agent or operator does not control. Side channels are the connector's natural extension. Any "send" operation has parallel recipients available; any "publish" has additional destinations possible; any "broadcast" has metadata fields. The connector has the full envelope; the agent has the visible subset. Detection requires verifying the full envelope, not just the visible part. Monitoring focused on what the agent intended (the visible fields) returns clean even when the connector has added attacker-chosen extensions.

Defensive Patterns

The structurally sound defence is to make the connector's full envelope auditable rather than trusting the connector's discretion. Network-egress allowlists at the connector process level prevent side channels from reaching unauthorised destinations regardless of what the connector code attempts. Operation-envelope logging at the connector boundary records every outbound destination, every header, every parallel write — providing the audit data needed to detect deviation from intent. Provenance verification at install time catches some classes of trojanised connector before they are loaded, but does not close maintainer-account-compromise vectors that bypass install-time defences.

For Web3 deployments specifically, outbound-mediator trust is the pattern that makes signing connectors high-risk: the agent specifies a transaction; the connector signs and broadcasts it. A trojanised signing connector can mirror the signed transaction to an attacker's address, sign a different transaction than the agent specified, or broadcast to a different network — all while the agent and operator see "transaction signed and broadcast successfully." The defence cannot rely on agent-side validation; it must operate at the connector boundary or below.

For broader supply-chain context, see the OWASP ASI04 explainer and the MCP Security Audit service description.