Harpocrates

Security & Privacy

A comprehensive overview of Harpocrates' security architecture and the privacy guarantees provided by our confidential computing infrastructure.

Overview of Privacy Guarantees

Harpocrates is designed from the ground up to ensure that your sensitive data remains confidential at every stage:

  • •Client-side encryption: Data encrypted before leaving your infrastructure
  • •Encrypted in transit: TLS 1.3 for all network communications
  • •Encrypted at rest: No plaintext data stored on disk
  • •Encrypted in use: TEE enclaves protect data during computation
  • •Verifiable privacy: ZK proofs demonstrate correct execution without revealing data

Data Lifecycle

Understanding how your data flows through the Harpocrates system:

1. Encryption (Client-Side)

Your sensitive prompt is encrypted on your device using AES-256-GCM before it leaves your infrastructure.

Threat Protection: Man-in-the-middle attacks, network sniffing, cloud provider access

2. Transmission (TLS 1.3)

Encrypted data is transmitted over TLS to the Harpocrates network. The payload remains encrypted end-to-end.

Threat Protection: Network interception, ISP surveillance, DNS tampering

3. Inference (TEE Enclave)

Data is decrypted and processed entirely within a hardware-enforced TEE. The host system, OS, and operators cannot access the plaintext.

Threat Protection: Host compromise, privileged user access, physical attacks

4. Response (Re-encryption)

The model output is encrypted inside the enclave before leaving the secure boundary. It's returned to you in encrypted form.

Threat Protection: Same as transmission phase

5. Decryption (Client-Side)

You decrypt the response on your device. Only you can read the plaintext output.

Threat Protection: Complete control over decrypted data

Trusted Execution Environments (TEEs)

TEEs provide hardware-level isolation for sensitive computations. Harpocrates uses Intel SGX and AMD SEV-SNP enclaves:

  • •Memory encryption at the CPU level
  • •Isolated execution environment separate from the host OS
  • •Remote attestation to verify genuine hardware
  • •Sealed storage for persistent encrypted data
TEE attestations are cryptographically signed by the CPU manufacturer (Intel/AMD), providing verifiable proof that code is running in a genuine secure enclave.

Attestation Verification Pipeline

Every inference generates a multi-layered attestation that you can verify:

  1. Hardware Attestation: CPU manufacturer signs enclave measurement
  2. Software Attestation: Hash of the exact inference code running in the enclave
  3. Data Binding: Cryptographic commitment to your input hash
  4. ZK Proof: Zero-knowledge proof of correct computation
  5. On-Chain Commitment: Attestation posted to Horizen blockchain

This layered approach ensures that even if one layer is compromised, the other layers maintain security guarantees.

What Harpocrates Does NOT See

It's important to understand what data remains completely hidden from Harpocrates operators:

  • ✓Your plaintext prompts and responses
  • ✓Intermediate model activations and hidden states
  • ✓Encryption keys (managed entirely client-side)
  • ✓Embedding vectors (if generated from encrypted inputs)

What Harpocrates CAN observe (for operational purposes):

  • •Request metadata (timestamps, API key, model used)
  • •Token counts (for billing)
  • •Response size and latency
  • •Error types (but not error content)

Best Practices for Sensitive Workloads

Maximize privacy and security when working with highly sensitive data:

Always verify attestations

Enable attestation verification for every request in production. Don't skip this step even if it adds latency.

Rotate encryption keys regularly

Use ephemeral encryption keys when possible. The SDK handles this automatically, but you can also implement custom key rotation.

Minimize metadata leakage

Consider padding inputs to fixed sizes and batching requests to reduce timing and size information leakage.

Use separate API keys per application

Don't reuse the same API key across different services. This limits the blast radius if one key is compromised.

Implement client-side rate limiting

Prevent accidental data exfiltration by limiting how much data any single component can send to Harpocrates.

Threat Model

Harpocrates is designed to protect against:

Protected Against:

  • • Malicious cloud providers
  • • Compromised host systems
  • • Network interception (MITM)
  • • Database breaches
  • • Insider threats at Harpocrates
  • • Physical server access
  • • Cold boot attacks

Limited Protection:

  • • Side-channel attacks (timing, power analysis)
  • • Spectre/Meltdown-class CPU vulnerabilities
  • • Metadata analysis (request patterns, timing)

NOT Protected Against:

  • • Client-side compromise (malware on your device)
  • • Compromised encryption keys
  • • Hardware backdoors in CPU manufacturer
  • • Quantum computing attacks (future threat)
No system is perfectly secure. Harpocrates provides strong privacy guarantees based on current cryptographic and hardware security standards. Stay informed about security advisories and update your SDK regularly.

Compliance and Certifications

Harpocrates is designed to help you meet regulatory requirements for sensitive data processing:

  • •GDPR: End-to-end encryption ensures data processors cannot access personal data
  • •HIPAA: TEE isolation suitable for protected health information (PHI)
  • •PCI DSS: Strong encryption for payment card data
  • •SOC 2 Type II: In progress (expected Q2 2025)

Note: While Harpocrates provides technical safeguards, compliance is a shared responsibility. Consult your legal team for specific requirements.