Security
Security model, attack surfaces, credential encryption, and revocation for Agent Access
Security Architecture
Agent Access implements a defense-in-depth security model with three 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: XATA Application Layer
- Credentials encrypted at rest using AES-256-GCM
- Encryption/decryption within TEE (Trusted Execution Environment)
- Rate limiting per API key
- Audit logging for all operations
Layer 3: User Control Layer
Users retain full control and can revoke access at any time:
- Revoke agent wallets / remove API wallets / subkeys in venue UI (Model 1)
- Rotate credentials on the venue side (Model 2)
- Delete XATA 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/Aster/Paradex/GRVT) | Model 2 (Lighter/Kuru/Nado) |
|---|---|---|
| XATA DB compromised | Attacker gets encrypted keypairs. With sealing key: can trade on venues where agent is still registered. For HL/HyENA, cannot withdraw (protocol enforced) | Attacker gets encrypted credentials. With sealing key: full venue access for those credentials |
| API key leaked | Attacker can trade via XATA API | Same |
Revocation
Model 1 (Prepare + Confirm)
- Revoke in venue UI — revoke the agent wallet, remove the API wallet/subkey in the venue's web interface. For Hyperliquid/HyENA, the agent expires per the user-set expiry
- Delete via API — call
DELETE /v2/account/venues/{venue}to remove stored keypair
Model 2 (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 when possible — Prepare + Confirm avoids exposing any private key to XATA