Agent Access
Security
Security model, attack surfaces, credential encryption, and revocation for Agent Access
Security Architecture
Agent Access implements a defense-in-depth security model with four layers of protection.
Layer 1: Venue Protocol Layer
Each venue enforces permission boundaries at the protocol level:
| Venue | Protection |
|---|---|
| Hyperliquid / HyENA | Agent wallets cannot withdraw (protocol enforced) |
| Paradex | Subkeys cannot withdraw (platform enforced) |
| GRVT | API keys scoped to sub-accounts |
| Lighter | API keys cannot fast-withdraw to other addresses |
Layer 2: Privy Policy Layer (Model 1 Only)
For programmatic venues (Hyperliquid, HyENA):
- HyperETH's signer can only sign
ApproveAgentoperations - Policy is enforced by Privy before any signing occurs
- The user controls the Policy — HyperETH cannot modify it
- Revocation also uses
ApproveAgent(with the zero address), so no additional policy rule is needed
Layer 3: HyperETH Application Layer
- Credentials encrypted at rest using AES-256-GCM
- Rate limiting per API key
- Audit logging for all operations
Layer 4: User Control Layer
Users retain full control and can revoke access at any time:
- Revoke HyperETH's Privy signer (Model 1)
- Remove API wallets/subkeys in venue UI (Model 2)
- Rotate credentials on the venue side (Model 3)
- Delete HyperETH API keys via API
Credential Encryption
All credentials (private keys, API keys, secrets) are encrypted using AES-256-GCM before storage:
- Encryption is performed within a TEE (Trusted Execution Environment) using a sealing key
- Credentials are never logged or exposed in plaintext
- Decryption occurs only at request time when the credential is needed for signing
Attack Surface Analysis
| Scenario | Model 1 (HL/HyENA) | Model 2 (Aster/Paradex/GRVT) | Model 3 (Lighter/Kuru/Nado) |
|---|---|---|---|
| HyperETH DB compromised | Attacker gets encrypted API wallet keys. With sealing key: can trade, cannot withdraw (protocol enforced) | Attacker gets encrypted keypairs. With sealing key: can trade on venues where agent is still registered | Attacker gets encrypted credentials. With sealing key: full venue access for those credentials |
| HyperETH auth key leaked | Can approve new agents for users who added HyperETH as signer. Cannot withdraw. Users can revoke signer in Privy | No impact | No impact |
| API key leaked | Attacker can trade via HyperETH API | Same | Same |
| Privy compromised | Theoretical private key reconstruction. Affects Model 1 users only | No impact | No impact |
Revocation
Model 1 (Programmatic)
Three revocation options:
- Revoke Privy signer — remove HyperETH as a signer in Privy dashboard
- Delete via API — call
DELETE /v2/account/venues/{venue}(triggersrevokeAgent) - Natural expiry — agent wallet expires via
valid_until(HyperETH auto-renews by default)
Model 2 (Prepare + Confirm)
- Remove in venue UI — delete the API wallet/subkey in the venue's web interface
- Delete via API — call
DELETE /v2/account/venues/{venue}to remove stored keypair
Model 3 (User Credentials)
- Rotate on venue — generate new credentials on the venue side, invalidating old ones
- Delete via API — call
DELETE /v2/account/venues/{venue}to remove stored credentials
Best Practices
- Store your API key securely — use environment variables or secrets vaults
- Rotate API keys periodically — generate new keys and delete old ones
- Use separate keys per agent — don't share one API key across multiple agents
- Monitor venue activity — check your venue accounts for unexpected trades
- Use Model 1 or 2 when possible — these models avoid exposing any private key to HyperETH