Encrypted Prompting Is Not Enough: Securing Agent Communications for Healthcare and Finance

Encrypting an API connection is only the beginning. Sensitive agent workflows must protect data, identity, authority, and evidence across every handoff.

AI agents are moving into the most sensitive parts of the enterprise.

A healthcare agent may summarize a patient record, coordinate prior authorization, or prepare clinical documentation. A financial agent may investigate fraud, reconcile payments, review credit evidence, or assemble a regulatory report. In both cases, the agent does more than generate text. It retrieves protected data, communicates with other agents and tools, carries context across workflow stages, and may initiate consequential actions.

That changes the security problem.

◈ TLS is necessary, but it is not end-to-end prompt protection.
Sensitive data must be governed in transit, at rest, in use, and across every agent handoff.

For regulated AI, the right question is not, “Is the API encrypted?” It is:

Can every participant prove its identity, receive only the minimum data and authority required, and produce an auditable record of how sensitive information moved and was used?

The Prompt Has Become a Sensitive Data Container

Prompts are often treated like temporary instructions. In production systems, they are assembled data packages.

A single healthcare prompt can contain:

patient identifiers;
diagnoses and medications;
lab results;
insurance information;
clinician notes;
retrieved policy documents;
and a history of earlier agent decisions.

A financial prompt may include account numbers, transaction histories, income, identity evidence, risk scores, internal controls, and suspicious-activity indicators.

The prompt is only one copy. The same information may exist in retrieval results, embeddings, tool arguments, message queues, observability spans, model caches, retry buffers, and conversation memory.

This is why conventional “TLS plus database encryption” is incomplete. TLS protects data while it crosses a network. Storage encryption protects disks, objects, and backups. During computation, however, a conventional processor must expose plaintext in memory to the software performing the work.

NIST describes confidential computing as an extension of protection to data in use, with hardware-backed trusted execution environments and attestation used to restrict sensitive material to authorized code. Its 2026 confidential-computing blueprint specifically discusses protecting data processed by AI workloads and releasing decryption keys only to environments that can attest to the required hardware and software state. NIST IR 8320E: Hardware-Enabled Security—Confidential Computing of Data in Cloud Workloads

The practical conclusion is simple: encrypted prompting is not one feature. It is an end-to-end data-handling architecture.

What “Encrypted Prompting” Should Mean

The phrase can imply several different security models. They should not be confused.

Encryption in transit

The client encrypts the connection to the model gateway using TLS. This protects against interception between endpoints, but the receiving application and model service can still process the plaintext.

Encryption at rest

Prompt records, retrieved documents, embeddings, traces, and outputs are encrypted in databases, object stores, queues, and backups. Keys should be independently governed and rotated. Sensitive payloads should not be stored simply because storage is available.

Application-layer envelope encryption

Sensitive fields are encrypted before entering shared infrastructure. A data-encryption key protects the payload; a key-encryption key in a managed key system protects that key. Decryption occurs only inside an authorized service or execution boundary.

Tokenization and selective disclosure

The system replaces identifiers and sensitive values with scoped tokens before model processing. An agent receives only the fields required for the task. A downstream authorized service can resolve a token when necessary.

This is often more practical than sending the complete record through every stage. A coding agent reviewing a claims rule may need age band and coverage type—not a patient’s name. A fraud-classification agent may need transaction features—not the full account profile.

Confidential computing

A trusted execution environment protects data and code while they are running. Remote attestation provides evidence about the environment before a key or workload is trusted. The Confidential Computing Consortium describes attestation as central because encryption alone cannot prove that sensitive data will be decrypted by the intended code in an acceptable environment. Confidential Computing Consortium: Why Attestation Is Required

Privacy-preserving computation

Fully homomorphic encryption and secure multiparty computation can compute on protected data without exposing conventional plaintext to one party. These techniques are important, but they remain workload-specific and may impose material performance, model-compatibility, or operational trade-offs. They should be evaluated against a concrete threat model rather than presented as universal encryption for arbitrary agent reasoning.

No single encryption layer solves every risk. Confidential AI is a system architecture.

Agent Communication Creates a New Trust Boundary

A single-model application has a relatively simple exchange: application to model and back.

An agentic workflow creates a communication graph:

User
  → intake agent
  → retrieval agent
  → specialist agent
  → policy service
  → action agent
  → external system
  → verification agent

⇄ Every agent-to-agent connection is a trust decision.
The receiver must verify identity, audience, purpose, authority, integrity, and expiration.

The receiving agent needs to know:

who sent the message;
on whose behalf it is acting;
what task and case the message belongs to;
which data classifications the sender was allowed to disclose;
whether the content has been altered;
what actions are permitted;
and when the authority expires.

A shared API key cannot answer those questions. Neither can the natural-language statement, “The previous agent approved this.”

Agents need verifiable workload identities. SPIFFE and SPIRE provide a model for attesting workloads and issuing short-lived cryptographic identities that can be used with mutual TLS or signed tokens. The important property is that identity is bound to the workload, not embedded as a long-lived secret in its prompt or configuration. SPIRE concepts SPIFFE Workload API

The communication channel should then provide:

Mutual authentication — sender and receiver both prove their identities.
Message confidentiality — unauthorized services cannot read the payload.
Integrity and replay protection — the receiver can detect alteration or reuse.
Audience restriction — a message intended for one agent cannot be presented to another.
Purpose and task binding — data and permissions are limited to a specific workflow.
Expiration — messages and capabilities cannot remain valid indefinitely.
Provenance — claims retain their source, time, sensitivity, and transformation history.

Transport encryption protects the pipe. Identity, policy, and provenance protect the transaction.

Separate Information From Authority

One of the most dangerous design errors in agent systems is allowing content to carry authority.

A retrieved clinical note may say, “Discharge the patient.” An email may say, “Transfer the funds immediately.” A tool response may contain an injected instruction asking the agent to reveal its context. These strings are information. They are not authorization.

The system should maintain distinct channels for:

content — evidence the model may interpret;
control — trusted instructions and workflow state;
authority — cryptographically verifiable permission to access data or perform an action.

An action agent should not execute a wire transfer because another agent generated a persuasive message. It should require a scoped capability issued by a policy service after deterministic checks.

A capability might be bound to:

{
  "principal": "employee:1842",
  "agent": "payment-reviewer:v7",
  "workflow": "case:90317",
  "operation": "prepare_transfer",
  "account": "tokenized-account-reference",
  "limit": 5000,
  "audience": "payments-api",
  "expires_in": 60
}

✓The model recommends. The policy service decides. The tool independently verifies.

This follows zero-trust principles: trust is not inherited from network location, and access decisions should be least-privilege and resource focused. NIST’s zero-trust guidance emphasizes explicit authentication and authorization for subjects and assets rather than implicit trust based on location. NIST SP 800-207: Zero Trust Architecture

For tool ecosystems, authorization standards matter as well. The Model Context Protocol’s authorization specification builds on OAuth security practices, including HTTPS, secure token storage, short-lived access tokens, refresh-token rotation for public clients, and PKCE. Protocol compliance does not replace application policy, but it provides a stronger foundation than distributing permanent secrets to agents. Model Context Protocol: Authorization

Healthcare: Protect the Care Path, Not Only the Record

Healthcare security discussions often begin with whether protected health information is encrypted. That is necessary but incomplete.

The US Department of Health and Human Services explains that properly encrypted electronic PHI can be rendered unreadable to unauthorized individuals. It also makes clear that encryption alone does not satisfy every obligation concerning confidentiality, integrity, and availability. A cloud service that maintains encrypted ePHI may still be a business associate even when it lacks the decryption key. HHS guidance on rendering unsecured PHI unreadable HHS guidance on HIPAA and cloud computing

An agent architecture should therefore protect the full care workflow.

Consider a prior-authorization assistant:

An intake service tokenizes direct identifiers.
A retrieval agent receives only the minimum clinical evidence required for the policy question.
A specialist model runs inside an approved environment and produces a structured recommendation with cited evidence.
A policy service validates purpose, patient relationship, and permitted use.
A human reviews high-impact or low-confidence cases.
The submission service receives a short-lived capability for one payer, one patient token, and one request.
The result is verified against the payer system and recorded in an immutable audit trail.

No agent should accumulate the complete chart merely because the workflow touches healthcare data. Data minimization should occur before prompt construction, not after an oversized prompt has already been logged.

Finance: Protect the Decision and the Transaction

Financial workflows combine confidential data with immediate action risk.

A fraud agent might read transaction history, device intelligence, beneficiary information, and customer communications. A treasury agent may prepare a payment. A credit agent may use regulated evidence to support a decision.

Encryption must be paired with layered authentication, segmentation, monitoring, transaction limits, and reconciliation. FFIEC guidance emphasizes risk-based authentication and layered controls for financial institutions, including attention to users, systems, APIs, and third-party services. FFIEC authentication and access guidance

A secure payment-agent workflow should separate:

evidence collection;
risk assessment;
transaction preparation;
authorization;
execution;
and settlement verification.

Each stage should use a different identity and permission set. The investigator does not need execution authority. The action agent does not need unrestricted access to investigative data. The verifier should compare the external ledger with the intended transaction, not trust the executor’s narrative.

Sensitive messages should be encrypted for the intended service and bound to the case. High-risk actions should require fresh authorization. Unknown external outcomes must be reconciled before retrying; otherwise, a network failure can become a duplicate payment.

The important economic point is that stronger security does not require sending every request through the most expensive privacy mechanism. Data can be classified and routed. Low-sensitivity tasks can use standard protected infrastructure. Highly sensitive processing can use tokenization, customer-controlled keys, or attested confidential execution. Consequential writes can require human approval and transaction-specific capabilities.

Security becomes a policy-driven pipeline rather than one oversized perimeter.

Observability Without Creating a Second Data Leak

Agent systems need detailed traces, but observability can quietly become the most complete repository of sensitive data in the architecture.

Prompts, retrieved passages, tool parameters, model outputs, and error messages are commonly copied into logs for debugging. In healthcare and finance, that can reproduce protected records across vendors, regions, and retention systems.

The telemetry design should default to metadata rather than raw content:

message and trace identifier;
sender and receiver identity;
data classification;
policy decision and reason code;
model and tool version;
token counts and latency;
cryptographic hash of protected artifacts;
access event;
outcome status;
and evidence location.

When content capture is genuinely required, use field-level redaction, separate encryption keys, restricted access, explicit retention, and a documented incident purpose. Sampling rules should be sensitivity aware. “Debug mode” must not become a standing exception to the privacy model.

A useful audit record answers:

Which identity accessed which classified data, for what purpose, under which authority, inside which verified environment, and what outcome followed?

Observability must not become a second data leak.
Record identities, decisions, versions, hashes, and outcomes before capturing raw protected content.

A Reference Architecture for Confidential Agent Workflows

A practical architecture contains seven control layers.

1. Data-classification gateway

Detect PHI, financial information, credentials, secrets, and other restricted fields before prompt assembly. Apply minimization, redaction, or tokenization by policy.

2. Cryptographic workload identity

Issue short-lived identities to agents, tools, model gateways, and policy services. Use mutual authentication between services.

3. Policy and capability service

Evaluate principal, purpose, agent identity, data class, action, resource, risk, and workflow state. Issue task-bound, audience-bound, expiring authority.

4. Protected context service

Assemble the minimum context required for the current decision. Preserve provenance and keep untrusted retrieved content separate from system controls.

5. Confidential execution tier

Route sensitive workloads to attested environments when the threat model requires protection from infrastructure operators, host software, or memory inspection. Release keys only after policy and attestation checks pass.

6. Governed tool gateway

Validate schemas, identities, capabilities, transaction limits, idempotency keys, and approvals before any consequential action.

7. Privacy-aware evidence plane

Record decisions, identities, policy outcomes, versions, hashes, and external verification without indiscriminately copying sensitive content.

Together, these layers provide a stronger guarantee than “the prompt was encrypted.” They make confidentiality, authority, and accountability part of the workflow.

The Standard Enterprises Should Demand

For sensitive agent systems, every message should be treated as a protected transaction.

Before deployment, an enterprise should be able to answer:

Where is sensitive data decrypted?
Which code and machine identities can access it?
Can the execution environment be attested?
Are agent messages mutually authenticated and audience restricted?
Is data minimized before prompt construction?
Can retrieved content influence authority?
Are permissions short lived and task specific?
Are tool writes independently validated?
Can operators trace an outcome without exposing raw protected data?
Can keys, models, agents, and permissions be revoked independently?
Can the workflow prove completion against an external system?

If these answers are unclear, adding another encryption setting will not solve the architecture.

Encrypted prompting is an important control, but the real objective is larger: confidential, authenticated, least-privilege computation across an entire agent workflow.

Healthcare and finance do not merely require models that can reason over sensitive data. They require systems that can prove why the data was accessed, where it was processed, which agent was allowed to act, and what happened next.

The future of regulated AI will belong to architectures that make every prompt, message, capability, and action verifiable by design.