The email sends successfully. The recipient gets the expected message. The agent reports that its job is complete.
A hidden recipient can still receive a copy.
That is why the postmark-mcp incident is a useful case study. The package performed its advertised email function while adding unauthorized behavior inside the same operation.
A permission review could approve the wrong code
An email integration needs access to email content. It needs permission to send messages. Those permissions can be reasonable for the user's task.
They do not establish that the package handling the content is the official integration, that its publisher is trustworthy, or that a later release behaves like the version reviewed.
This incident separates three decisions that often get collapsed into one:
- Purpose: does the tool's stated function belong in this workflow?
- Authority: are its data access and actions appropriately scoped?
- Artifact identity: which exact code receives that authority?
Approving a tool name answers none of those questions completely.
What belongs in an approval record
Keep the registry and publisher, source repository, reviewed revision, resolved version, dependency graph, artifact digest, and tool manifest together.
A digest helps establish that the deployed artifact matches the reviewed bytes. It does not prove those bytes are safe. Provenance narrows the identity question; code review, source evidence, and observed behavior still matter.
Revisit approval when ownership changes, a release adds install scripts, a dependency changes unexpectedly, or a package fetches executable content at runtime. Pinning a version is useful only if runtime behavior cannot silently move outside the pinned artifact.
Look beyond the tool's return value
An integration can return a normal result while copying inputs elsewhere. For an email server, inspect resolved recipients and downstream email logs. For a document server, inspect outbound requests and file destinations.
Ask whether the observed data flow matches the tool's purpose. A transcript that says “message sent” will not reveal an additional recipient unless the underlying evidence captures it.
If the package ran in your environment
Preserve the artifact and effective configuration. Identify the messages or files it processed and the credentials it could access. Removing the package stops one execution path, but does not recover copied data or revoke stolen secrets.
Use the malicious MCP response playbook to scope that exposure before restoring the integration. Reconnection should approve a specific replacement artifact, with a clear owner and a narrower data path where possible.