Your AI agent works. It reads the chart, drafts the follow-up, and now it needs to actually send that message to a patient. That last step is where HIPAA compliance can break.
You did the hard part right. You signed a business associate agreement (BAA) with your model provider, so the AI can process protected health information (PHI). What the model's BAA does not cover is what happens after the model produces an answer, when your application sends it. The outbound message is a separate channel, and it needs its own protection.
This is a short, practical guide to closing that gap: how to let an AI agent send PHI over email compliantly, without the agent ever holding a credential or sending patient data unencrypted.
Why the send is a separate compliance problem
A BAA with your model provider covers the model. It says nothing about the email your app sends afterward.
The moment an agent emails a result, a reminder, or a visit summary, PHI leaves your system through a path the model provider never agreed to protect. That send needs its own BAA-backed, encrypted channel, and it is the part an auditor will ask you to account for.
Agents make this sharper than a normal app does, because an agent decides on its own when to act. If it can call a "send email" tool, it can move PHI to the outside world without a human in the loop. So the tool it calls has to be compliant by default.
Why the obvious fixes fall short
The quickest thing a builder reaches for is to hand the agent an email API key and let it send. That path has two problems.
First, most general-purpose email tools will not sign a BAA, or will not encrypt by default. Postmark states it cannot sign a BAA. Twilio SendGrid says it is not a HIPAA eligible service. Amazon SES is HIPAA eligible under the AWS agreement but does not enforce encryption by default, so a misconfiguration can send PHI in plain text.
Second, putting a live credential in reach of the model is its own risk. Anything in the model's context can end up in a log, a trace, or a response. A send key that the agent holds is a secret you now have to defend in a much larger blast radius.
Give your agent a compliant tool
The Model Context Protocol (MCP) is an open standard that lets AI models call external tools in a consistent way. The Paubox MCP server uses it to give an agent the capability to send HIPAA compliant email through the Paubox Email API.
It works with Claude, Claude Desktop, Claude Code, Cursor, Windsurf, and custom agents built on the MCP spec. The agent calls a tool named send_secure_email, with companion tools like check_email_status and validate_credentials.
The design answers the credential worry directly. The Paubox API key stays with the MCP server process and is never shared with the model. It does not appear in a tool call or in the model's context. The agent can send a compliant, encrypted message without ever holding the credential that sends it.
How the flow works
In practice the flow is straightforward:
- Your agent decides a message needs to go out and calls
send_secure_emailwith the recipient and body. - The MCP server signs that request with the stored Paubox credential, which the model never sees.
- The Paubox Email API encrypts the message with TLS 1.2+ by default and delivers it, under a signed BAA.
The model orchestrates the send. It does not hold the key, and it does not handle the transport. That separation is what makes an autonomous agent safe to give a send capability at all.
Setting it up
Connect the server to your MCP-compatible client through the OAuth connector, or set the x-paubox-api-key and x-paubox-api-user headers for HTTP transport. For a local agent, run it over stdio with npx @paubox/mcp@latest and your Paubox credentials in the environment. The MCP server docs have the full setup.
Because it runs on the Paubox Email API, the compliance posture comes with it: a signed BAA on every plan, TLS 1.2+ encryption by default, HITRUST certified infrastructure, and an audit trail. You don't have to assemble those guarantees yourself; you are calling a service that already has them.
Start here
An AI agent that can act on PHI is only as compliant as the channels it acts through. Give it a sending tool that signs a BAA, encrypts by default, and keeps the credential out of the model, and the riskiest step in an agent workflow becomes the safe one.
This is one piece of the larger picture. For the full path, from choosing a model to keeping PHI safe at every step, see our guide to building with AI in healthcare. For the compliant send layer specifically, the Paubox Email API and MCP server let an agent send from day one, and you can start for free.
Related: Watch our on-demand webinar on the HIPAA Security Rule changes.
