Can AI Read and Act on Encrypted Emails? Developer-SDK vs Staff-Tool Encryption Compared

A practice already using an encryption tool for outbound patient email usually assumes the hard compliance work is done, and then asks a follow-up question that stops the AI project in its tracks: can the new AI agent actually open an encrypted message that comes back in, or does someone still have to click a link and read it manually?

The honest answer depends entirely on which category of encryption product the practice already owns, and it's a distinction almost no vendor demo makes explicit. Staff-facing encryption tools are built for a human to click a secure link and read a message in a browser. Developer-facing encryption SDKs are built to be called from code, meaning decryption can happen programmatically, no human click required, which is the specific capability an AI agent needs to read and act on an encrypted message automatically. Confusing the two categories is the single most common reason an AI email automation project stalls after the encryption tool is already purchased.

The Distinction That Decides Everything

Both categories of encryption product solve the same underlying problem, protecting message content in transit and at rest, but they're built for a different reader.

Staff-facing tools, the category Egress Protect (NHSmail's official provider) and most out-of-the-box Outlook add-ins sit in, are designed to work invisibly for a human sender and require a manual step from the recipient: click a secure link, authenticate, read the message in a browser or app, no software installation required. This is exactly the right design for the vast majority of patient-facing correspondence, and it's why NHS trusts, GPs, and private hospitals overwhelmingly already use tools in this category. But by design, these tools generally don't expose an open API for automated inbound decryption. The message is meant to be opened by a person, not parsed by code.

Developer-facing encryption SDKs, the category Virtru sits in, solve the identical encryption problem but ship as software libraries, in JavaScript, Java, Go, and other languages, built to be called from an application. Virtru's SDK, for instance, supports programmatic decryption that returns the plaintext content directly to the calling code, no browser click involved, built on TDF (Trusted Data Format), an open standard that also exists in an open-source implementation, OpenTDF, worth knowing about specifically because it means the encryption scheme itself isn't proprietary or locked to one vendor's roadmap.

What This Means for an AI Agent Specifically

If a practice's encrypted inbound mail runs through a staff-facing tool only, an AI agent cannot automatically decrypt and act on that message. Someone still has to open it manually, which defeats the purpose of automating the workflow around it. The practical options at that point: keep the manual open-and-forward step as a deliberate human checkpoint (often the right call for genuinely sensitive content), or add a developer-SDK-based encryption layer specifically for the subset of automated workflows that need programmatic access, while keeping the staff-facing tool for everyday human-to-human correspondence. These aren't mutually exclusive; most mature setups run both, matched to the right use case.

If the practice is building or buying an AI agent that needs to read encrypted patient messages and act on them (routing, drafting, or flagging), the encryption product in the data path needs to expose that programmatic path from day one. This is a build requirement to specify before development starts, not a detail to discover mid-project. It's the same category of prerequisite question we raise on every integration project: does this system have a documented, accessible API, or are you looking at an unplanned re-architecture once the gap surfaces in week seven.

The Security Risk Nobody's Demo Covers

Making encrypted email machine-readable to an AI agent doesn't just require the right SDK, it also changes the threat model. Once an agent is parsing decrypted message content to decide what to do next, it inherits an attack class a human reader doesn't fall for: hidden prompt injection. An attacker embeds an instruction inside the message body using white-on-white text, a near-invisible font size, or CSS-hidden elements. A human glancing at the decrypted content sees a normal message. An AI agent parsing the raw text reads every character, including a hidden instruction telling it to forward data, approve an action, or exceed its intended scope.

This isn't theoretical. Security researchers documented a real case in September 2025, "ShadowLeak," where hidden prompt injection exfiltrated data from an AI email agent with no visible sign to the human operator. The broader numbers back it up: prompt injection attempts against AI systems have risen roughly 340% year over year, indirect injection delivered through content rather than typed by a user now accounts for more than 55% of observed attacks, and researchers estimate close to 40% of AI agent protocols in production carry some form of this exposure.

The practical implication for a practice adding programmatic decryption specifically to enable AI automation: decrypting the message is only step one. Everything the agent does with that decrypted content needs to be treated as untrusted input, with guardrails before it reaches any decision-making step and output validation before any action executes, exactly the same discipline required for unencrypted inbound mail, just applied one layer further in, since decryption doesn't make content trustworthy, it just makes it readable.

What a Working Architecture Actually Looks Like

A practice that has confirmed its encryption vendor supports programmatic decryption still has an architecture decision to make: where does decryption happen, and what sees the plaintext content afterward. The pattern that holds up under scrutiny keeps decryption as close as possible to the point where the content is actually needed, ideally inside the same secured environment that runs the AI agent's guardrail and validation layer, rather than decrypting early and passing plaintext content between multiple systems or services where it becomes harder to track and audit.

Concretely, this usually means: the SDK decrypts the message inside the application backend, the decrypted content passes immediately into an input-validation and guardrail layer before it ever reaches the model doing the drafting or classification work, and the plaintext is never written to a general-purpose log or a third-party analytics tool by accident, a genuinely common mistake when a team adds observability tooling without checking whether it's capturing message content along with metadata. Every decryption event, and every subsequent action the agent takes based on that content, should be logged with full context, not just a success or failure flag, so that if something does go wrong, there's a reconstructible trail of exactly what the agent saw and what it decided to do about it.

This is also where the sandboxing discipline used for any production AI agent applies directly: before an agent with programmatic decryption access touches live encrypted patient mail, it should be validated against a staging environment with mocked encrypted messages, not tested for the first time against real inbound patient correspondence. Agents behave unexpectedly at the edges, and the tool calls, in this case, a decryption call followed by an action based on the decrypted content, are exactly where real-world consequences occur if something is misconfigured.

Testing Programmatic Decryption Before Committing to a Build

Before writing a single line of AI drafting or triage logic, confirm the decryption path works end to end in isolation: a test message, encrypted through the normal patient-facing flow, decrypted programmatically by the SDK, with the plaintext content landing exactly where expected in a logging or staging system, nowhere else. This is a small, cheap test relative to the cost of discovering a gap after the agent, guardrails, and drafting logic are already built on top of an assumption about how decryption behaves. Treat it the same way you'd treat any other foundational dependency: verified early, in isolation, before anything else depends on it.

The Migration Question Nobody Asks Upfront

A practice already committed to a staff-facing encryption tool and now scoping an AI automation project often assumes the choice is binary: keep the existing tool and accept no automated decryption, or migrate entirely to a developer-SDK product and retrain every staff member on a new workflow for everyday correspondence. Neither is usually necessary. Most SDK-based providers, Virtru included, offer a staff-facing sending experience alongside the programmatic access, meaning a practice can often add SDK-level access to an existing account rather than replacing the whole platform. Confirm this directly with the vendor before assuming a full migration is required. It's a materially different, and usually cheaper and faster, project than a wholesale platform switch, and it's the kind of question a vendor's sales team won't necessarily raise unprompted if the bigger contract is more profitable for them.

Verifying the Product Claims Before You Buy

Egress is a real, verified NHSmail-integrated encryption provider, this is not in question. Virtru is a real, verified encryption product built on the open TDF standard, also not in question. What's worth verifying directly with any vendor before committing budget: does their SDK expose a genuine programmatic decrypt function usable from your own application code (not just an API for sending encrypted mail, which is a different and much more common capability), and does their pricing tier for that programmatic access match what a small-to-mid-size practice can actually afford, since enterprise SDK access is sometimes gated behind a much higher contract tier than the staff-facing product.

The Competitor Pulse Check

The Budget Conversation Vendors Don't Lead With

Programmatic decryption access is frequently gated behind a different, and meaningfully higher, pricing tier than the staff-facing sending product most practices already budget for. A vendor's marketing page will happily quote the per-seat cost of the staff-facing encryption tool, and stay quiet on SDK or API-tier pricing until a sales call, because that tier is usually sold on a custom enterprise contract rather than a published rate card. A practice manager scoping an AI automation project should ask for programmatic-access pricing explicitly, and early, since it can materially change whether the automation project is worth pursuing this year or worth deferring until volume justifies the cost.

Frequently Asked Questions

Can an AI agent read encrypted patient emails automatically?

Only if the encryption product exposes a programmatic decryption path, which developer-facing SDKs like Virtru are built for and staff-facing tools like Egress Protect generally are not. Check this specifically before scoping an automation project; it's a common and expensive gap to discover mid-build.

Is Egress Protect compatible with AI automation?

Egress Protect is a staff-facing tool designed for a human to click a secure link and read a message manually. It's the right tool for everyday patient correspondence, but it isn't built for an AI agent to decrypt content automatically without a separate API product, if the vendor offers one.

What is TDF and why does it matter?

TDF (Trusted Data Format) is the open encryption standard Virtru's SDK is built on, also available as open-source OpenTDF. Its openness matters because it means the underlying encryption scheme isn't locked to one vendor's proprietary format, reducing long-term lock-in risk for a practice building automation around it.

Does decrypting a message make it safe for an AI agent to act on?

No. Decryption makes the content readable, not trustworthy. Once an agent parses message content, it needs guardrails treating that content as untrusted input, because hidden prompt injection, invisible instructions embedded in the message, is a real and rising attack vector against exactly this kind of pipeline.

Should a practice replace its staff-facing encryption tool with a developer SDK?

Usually not entirely. Most practices keep the staff-facing tool for everyday human correspondence and add a developer-SDK layer specifically for the automated workflows that need it. The two categories solve different problems and typically coexist rather than replace one another.

How much does programmatic decryption access typically cost compared to the staff-facing product?

It's frequently priced on a separate, higher enterprise tier that isn't published on the vendor's standard rate card, unlike the per-seat staff-facing product. Ask for programmatic-access pricing explicitly and early in the sales process, since it materially affects whether an AI automation project is worth building this budget cycle.

What's the simplest way to test whether our encryption vendor supports programmatic decryption before committing budget to an AI build?

Ask the vendor directly for their SDK documentation and a sandbox or trial API key, then have a technical partner attempt a basic decrypt call against a test message before any contract is signed. A vendor that can't produce working developer documentation on request, only a sales deck, is a strong signal the programmatic capability either doesn't exist yet or isn't mature enough to build a production workflow against.

What's Next

Confirming which encryption category your practice already runs, and whether it supports programmatic decryption, is a prerequisite check, not an afterthought, for any AI email automation build. Our full guide to NHS-compliant encrypted email covers the compliance side of this decision, and our agentic AI for medical practice admin hub walks through how this fits into the wider automation architecture. Once decryption is confirmed to work programmatically, the next question is what the AI agent actually does with the content, our guide to AI-drafted patient replies and human approval covers that decision layer, and our guide to email security gateways covers the filtering layer that sits upstream of all of this. If you're not sure whether your current encryption vendor supports the programmatic access an AI build would need, get in touch and we'll check it with you before you commit to a build.