Skip to content

HARP-THREATMODEL Specification

Version: 0.2 Draft (Standards-Grade) Status: Draft Specification (Security Analysis)


This document provides a formal threat model and security analysis for the Human Authorization & Review Protocol (HARP) suite, including:

  • HARP-CORE
  • HARP-PROMPT
  • HARP-SESSION
  • HARP-TRANSPORT
  • HARP-KEYMGMT

This analysis applies structured threat modeling methodology (STRIDE) and defines:

  • Assets
  • Trust boundaries
  • Attack surfaces
  • Threat categories
  • Mitigations
  • Residual risks
  • Operational security requirements

This document is REQUIRED for enterprise-grade adoption and security review.


This threat model uses:

  • STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
  • Asset-centric modeling
  • Trust boundary analysis
  • Attack surface decomposition

This document focuses on protocol-level threats and enforcement guarantees.


The following assets are security-critical:

Mobile Approver private signing key (MA-SK)

Compromise impact:

  • Unauthorized approvals
  • Full loss of human control guarantee

HARP Enforcer integrity and execution gating logic

Compromise impact:

  • Bypass of approval requirement
  • Silent execution of malicious actions

Canonicalized artifact representation and artifactHash

Compromise impact:

  • Approval bound to incorrect content
  • Substitution attacks

Integrity and authenticity of transported artifacts and Decisions

Compromise impact:

  • Replay
  • Message injection
  • Availability degradation

Metadata audit records

Compromise impact:

  • Loss of forensic traceability
  • Repudiation risk

HARP defines the following trust boundaries:

  1. Between AI Agent and HARP Enforcer
  2. Between HARP Enforcer and Mobile Approver
  3. Between HARP components and Gateway
  4. Between user and Mobile Approver device

The HARP Enforcer is the primary enforcement boundary.


Threat:

  • Attacker impersonates Mobile Approver.

Mitigation:

  • Ed25519 signature verification
  • signerKeyId binding
  • Secure provisioning
  • Revocation enforcement

Residual risk:

  • MA private key compromise

Threat:

  • Artifact modified after approval.
  • Decision modified in transit.

Mitigation:

  • Deterministic canonicalization
  • artifactHash binding
  • Signature verification
  • Hash mismatch rejection

Residual risk:

  • Canonicalization implementation flaws

Threat:

  • User denies approving an action.

Mitigation:

  • Cryptographic signature
  • Audit logging with timestamp
  • Device binding

Residual risk:

  • Shared device scenarios

Threat:

  • Gateway inspects artifact content.
  • Transport leakage.

Mitigation:

  • Zero-knowledge compatibility
  • Optional E2E encryption
  • TLS enforcement

Residual risk:

  • Metadata leakage
  • Traffic analysis

Threat:

  • Flooding artifact or prompt submissions.
  • Replay attempts.

Mitigation:

  • Rate limiting
  • Idempotency enforcement
  • Replay cache

Residual risk:

  • Large-scale distributed attacks

Threat:

  • AI Agent bypasses HARP Enforcer.
  • HE compromised.

Mitigation:

  • Mandatory enforcement requirement
  • OS-level process isolation
  • Code signing (recommended)

Residual risk:

  • Local privilege escalation outside protocol scope

Paths:

  • Compromise MA private key
  • Bypass HE
  • Exploit canonicalization flaw
  • Replay valid Decision

Mitigations:

  • Secure key storage
  • Replay cache
  • Deterministic hashing
  • Expiration enforcement

Gateway is assumed untrusted.

Risks:

  • Message delay
  • Message reordering
  • Message dropping
  • Metadata observation

Mitigations:

  • Signature validation at HE
  • Idempotency
  • Replay protection
  • Optional E2E encryption

Mitigation:

  • Cryptographic agility defined in KEYMGMT
  • Algorithm identifier fields

Mitigation:

  • Secure CSPRNG requirement
  • OS-backed key generation

HARP does NOT mitigate:

  • Compromise of Mobile Approver device
  • Compromise of HARP Enforcer binary
  • Insider threats with valid keys
  • OS-level compromise

Operational controls are REQUIRED to mitigate these risks.


Enterprise deployments SHOULD:

  • Use hardware-backed key storage
  • Enable mTLS
  • Enable rate limiting
  • Monitor signature verification failures
  • Rotate keys periodically
  • Conduct code audits of HARP Enforcer

HARP provides:

  • Strong cryptographic authorization binding
  • Replay resistance
  • Deterministic artifact integrity
  • Zero-knowledge compatibility
  • Clear enforcement boundary

Security ultimately depends on:

  • Key management practices
  • Enforcer integrity
  • Operational controls

An implementation is HARP-THREATMODEL compliant if:

  • It documents trust boundaries
  • It enforces signature validation
  • It enforces replay protection
  • It implements secure key storage
  • It publishes residual risk acknowledgement