Threat model

AllowKit assumes the agent can be wrong, tricked, or compromised. Policy checks are designed to hold regardless of why a payment was requested — intent is never trusted by default. For the escrow and co-signing mechanics behind this, see Custody and enforcement model.

Threat	Mitigation
Prompt injection triggers an unwanted payment	Policy checks (host allowlist, service allowlist, per-payment cap) apply regardless of why the agent asked — intent is never trusted by default.
Compromised or buggy agent overspends	Daily and weekly caps bound total exposure even if every individual payment looks legitimate.
Agent calls an unknown or malicious endpoint	Unapproved service ids and unregistered recipients are blocked before escrow release.
Duplicate payment on retry	Idempotency keys ensure the same payment request settles at most once.
AllowKit’s policy service is unreachable	Fail-closed: the on-chain escrow requires AllowKit’s co-signature, so payments simply stop rather than bypassing policy.
Agent key is exfiltrated	The agent key can only request payments from its own escrow — it cannot reach the owner’s main wallet or other agents’ escrows.
Recipient address changes underneath a service id	Address changes are treated as pending approval, not applied silently.
Expensive one-off request slips through	Approval thresholds route anything above a configured amount to a human before settlement.