Security Model
Ephos is designed around a Zero-Knowledge, Zero-Trust, Zero-Access philosophy. This means we do not trust our own servers with your raw credentials (Zero-Knowledge), we do not trust autonomous agents with unconstrained access (Zero-Trust), and backend administrators have no persistent access mechanism for inspecting your plaintext credentials at rest (Zero-Access).
Zero-Knowledge Vault (Storage Layer)
When you register a Phantom Key, your browser encrypts the data locally using your Master Passphrase. These encrypted payloads are stored in the Zero-Knowledge Vault as opaque blobs. Because Ephos never receives your passphrase or your unencrypted keys, your data remains secure even in the event of a full database exfiltration.
Ephos Enclave (Execution Layer)
During a proxy request, your secret is retrieved from the vault and decrypted *only* into the Ephemeral Memory of an isolated Ephos Enclave. This momentary, stateless lifecycle is known as Ephemeral Execution—ensuring secrets exist in plaintext only for the milliseconds required to make an outbound call. While these secrets are stored in our Zero-Knowledge Vault for your convenience, they are encrypted with your Master Passphrase before storage. This ensures that only you (via your browser) or the Ephos Enclave (via the Token Secret) can ever view the raw plaintext. Ephos administrators and infrastructure providers have zero access to the underlying keys.
Delegated Identity (NHI)
Ephos decouples the Delegated Identity (Ephos Token + Token Secret) from the Phantom Key (Encrypted API Credentials). When you delegate access to an agent, your browser re-encrypts the Phantom Key using a unique Token Secret. This architecture ensures that even in the event of a total database exfiltration, your credentials remain secure because your Token Secrets exist only locally in your dashboard or within your agent's environment. The only time these secrets enter the Ephos infrastructure is during the momentary request lifecycle inside the isolated Ephos Enclave.
The Sliding Scale of Security
Ephos is designed to adapt to your specific threat model. We offer two modes of execution depending on your security requirements:
Mode A: Delegated Identity
Method: Persistent Token Secret (ps_xxx)
The standard execution mode. The Token Secret is transmitted via TLS in the request header to authorize the decryption of the associated Phantom Key within the enclave.
- ✅ Stateless execution
- ✅ Direct Header-based Auth
- ⚠️ Secret is transmitted over the wire
Mode B: Zero-Knowledge Autonomy
Plus & Pro Plans Only
Method: One-Time Derived Key (PBKDF2)
The hardened execution mode. A Salt Handshake is used to derive a transient, non-persistent key locally. Long-lived credentials remain isolated from the agent runtime and are not directly exposed during execution.
- ✅ Zero-persistence of secrets
- ✅ Resistant to traffic interception
- ⚠️ Requires Ephos SDK (Dashboard Access)
Intelligent Credential Redaction
Ephos scans every response from target APIs for the presence of your raw secrets. If an API accidentally "echoes" a key back in a response (a common vulnerability), Ephos redacts it before it reaches the agent.
Domain Whitelisting
Ephos Tokens can be restricted to specific hostnames (e.g., api.openai.com).
Even if a token is stolen via prompt injection, it cannot be used to exfiltrate data to unauthorized domains
or probe your private internal network. The proxy layer enforces these boundaries at the network level.
Forensic Auditing
Every execution is recorded in forensic audit logs. While we cannot see your secrets, we maintain a forensic record of which token was used to access which domain, providing full accountability and audit transparency for agent actions.
Human-in-the-Loop (HITL) Approval Flows Coming Soon
Integrating seamlessly with our Zero-Knowledge, Zero-Trust philosophy, the upcoming Human-in-the-Loop (HITL) Approval Flow framework provides an essential safeguard for autonomous agent actions. Rather than granting unconstrained execution agency, administrators can configure granular policy triggers that require multi-party cryptographic authorization.
When an agent requests an operation requiring HITL verification, the Ephos Gateway stages the call in a secure pending state without performing in-memory decryption. A secure challenge is presented to designated human approvers within the dashboard. Only upon explicit human verification does the Gateway derive the decryption key, execute the proxy call within the Ephos Enclave, and record the complete human authorization chain in the forensic audit log.