Security — HARP
Security by design
Separate trust boundaries. Cryptographic binding. Zero-knowledge relay. Fail-closed enforcement.
Threat model
Section titled “Threat model”Substitution
Decision signature bound to artifact hash
Replay
Nonce + expiry + replay cache
In-band compromise
Approval on a separate mobile device
Gateway snooping
E2E encryption; gateway sees only ciphertext
Enforcement bypass
Mandatory local enforcer gating
Key forgery
Ed25519 with device-bound private keys
Why out-of-band authorization
Section titled “Why out-of-band authorization”Separate device = separate trust
The signing key lives on your phone. Not on the machine where the agent runs. Even a fully compromised IDE cannot sign approvals.
Human attention, not UI clicks
You review the artifact on a dedicated screen. No chance of auto-approve scripts, UI spoofing, or clickjacking.
Cryptographic posture
Section titled “Cryptographic posture”Ed25519 signatures
All decisions signed with Ed25519. Base64url-encoded, verified at the desktop enforcer.
SHA-256 artifact hashes
Deterministic canonical JSON → SHA-256. Platform-independent. 64 lowercase hex characters.
X25519 + AEAD encryption
End-to-end encryption via ECDH key agreement. AES-256-GCM or ChaCha20-Poly1305.
What HARP does not mitigate
Section titled “What HARP does not mitigate”Enterprise security checklist
Section titled “Enterprise security checklist”- ☐ Use hardware-backed key storage (Secure Enclave, Android Keystore, TPM)
- ☐ Enable mTLS for gateway communication
- ☐ Enforce key rotation (recommended: annually or on device loss)
- ☐ Monitor and alert on signature verification failures
- ☐ Log all approval events with integrity-protected audit trail
- ☐ Conduct periodic code audits of the HARP Enforcer