Frequently Asked Questions

Seald Healthcare protects patient data itself, not just the systems around it. Each record is encrypted individually, with decryption authority kept separate from the data. Records stay encrypted wherever they are stored, accessed, or shared and decrypt only during authorized use under policy for an approved person, device, application, or AI agent.

No. TLS protects data while it moves between systems, and at-rest encryption protects storage. Seald Healthcare adds persistent, record-level protection that remains with patient data across applications, vendors, cloud environments, databases, backups, and AI workflows.

Seald Healthcare manages key infrastructure separately from the patient data, but cannot independently decrypt customer PHI. Each data key is protected under key material controlled by your organization, keeping decryption authority separate from the systems storing or transmitting the data.

No. Seald Healthcare works alongside infrastructure, identity, endpoint, network, TLS, and at-rest security. Those tools protect systems and access paths. Seald Healthcare protects the record itself.

Your organization does. Access is governed by policies that determine who or what may decrypt a record and under what conditions. Policies can account for the user, device, service, workflow, location, time, and other authorized conditions, with access revocable in real time.

Policy Studio is powered by Marlow, the AI that operates Seald Healthcare. Marlow analyzes your BAAs, vendor contracts, and security requirements and drafts record-level access policies. Your organization reviews and approves each policy. Seald Healthcare then enforces it cryptographically on every decryption request.

Yes. Because decryption remains policy-governed, your organization can revoke authorization in real time even after encrypted patient data has been distributed or stored outside your environment. Possession of the ciphertext alone does not provide authority to decrypt it.

No. Seald Healthcare is zero-knowledge by design. We manage the cryptographic infrastructure and policy enforcement required to protect the data, but we cannot independently decrypt customer PHI.

Seald Healthcare supports multiple integration paths depending on how patient data is used. Secure Portal Access gives authorized users browser-based access without requiring a native vendor integration. Native Integration uses Seald Healthcare's API and SDK for applications, vendors, and AI agents that need to process patient data programmatically. Protected Storage keeps files and records encrypted across OneDrive, Google Drive, S3, databases, archives, backups, and disaster recovery while preserving authorized access. Seald Healthcare can also integrate into existing healthcare data flows such as HL7, FHIR, X12, SFTP, integration engines, APIs, and outbound file workflows.

No. Seald Healthcare is designed to deploy alongside your existing healthcare infrastructure. For outbound workflows, it can sit at the egress point where patient data leaves your environment, encrypting PHI before it reaches third parties without replacing your EHR or requiring EHR vendor cooperation.

That depends on the integration model. In many existing data workflows, vendors continue receiving data through the same connection, schedule, and format they use today. The difference is that protected PHI remains ciphertext unless an authorized user, application, service, or workflow is permitted to decrypt it. For human-review workflows, vendors can also access authorized records through Seald Healthcare's secure portal without requiring a native integration.

It depends on the workflow. Your first workflow, such as files in OneDrive, Google Drive, or S3, can be protected in minutes. Native integrations with vendors roll out vendor by vendor, with help from our forward-deployed engineers.

Seald Healthcare is designed so that compromising the environment storing the data does not, by itself, provide the authority required to decrypt the protected records. Patient data remains encrypted, and decryption still requires an authorized request that satisfies the active policy.

Yes. Record-level encryption can persist across databases, cloud storage, archives, immutable backups, and disaster recovery environments. Protected records remain encrypted and decrypt only during authorized use, including during restoration and recovery workflows.

Seald Healthcare records decryption requests, denials, policy changes, revocations, key operations, and relevant access context in a tamper-evident audit trail. This provides visibility into who or what attempted to access patient data, when, and under what policy conditions.

Marlow is the AI that operates Seald Healthcare. It analyzes your contracts, BAAs, and security requirements and translates them into record-level policy. It monitors decryption activity in real time, flags policy violations and unusual access, and stages revocations, key rotations, and policy changes for your approval.

Yes. Each AI agent or workflow decrypts only the records its policy allows, and its access can be revoked in real time. Records sent to outside AI vendors stay encrypted and decrypt only during authorized use. Every decryption is logged.

Every AI agent acts with its own credentials, and compromising one can expose everything it can reach. With Seald Healthcare, each agent decrypts only the records its policy allows. Its access can be revoked in real time, and every decryption is logged.

Prompt injection can manipulate an AI system into disclosing data. Seald Healthcare does not stop the manipulation itself. It limits the damage, because a manipulated agent can still reach only the records it was authorized to decrypt, and every decryption is logged.