Permit is a payment authority layer for AI agents developed by Marcus Richards. It interposes enforceable, human-set spending permissions, a budget cap, an approved-merchant list, an expiry time, and revocation, between an autonomous agent and the PayPal payments API, recording every authorization decision in a tamper-evident receipt ledger.
It is built as an entry to the PayPal AI Hackathon, with submission closing November 12, 2026, and is published as open source under the MIT license. As of October 2026 it is a working prototype: a 96-test suite passes, a six-beat demonstration exercises the full payment lifecycle including failure recovery, and an integrated run against PayPal's live sandbox is documented but not yet executed.
Background
Autonomous agents that can spend money create an authority problem distinct from a capability problem. A typical integration hands the agent payment credentials with no notion of how much may be spent, with whom, for how long, or how a human takes the permission back mid-transaction. Existing controls tend to be coarse: a static API key, a manual approval click, or killing the process.
Permit's conceptual origin is Interlock, Richards' agent safety substrate, which treats authority as a loan rather than a possession: leases expire, a global e-stop halts execution, and every claim carries its provenance. Permit applies that leased-authority model to a single high-stakes domain, agent spending on PayPal rails, where the failure modes are concrete and the accounting must balance.
Design
The permit
A permit is a revocable spending permission with four elements: a budget cap in integer cents, an approved-merchant list, an expiry timestamp, and a revocation flag. Amounts must be positive integers; negative or zero amounts are rejected at the authority boundary and recorded as blocked receipts. Accounting is cumulative: reserved plus captured spending counts against the cap, so a released reservation that was captured cannot be re-spent. A per-permit lock makes the budget check and reservation atomic across workers.
Blocked attempts are first-class records, not silent denials. Each carries a reason such as over_cap, invalid_amount, merchant_not_bound, revoked, or expired, and lands on the receipt ledger alongside approvals.
Settlement lifecycle
A purchase moves through a fixed pipeline: check (authority), reserve (hold budget), authorize (PayPal authorization), register escrow, release (delivery evidence checked against predicates), then capture or void. Exactly one component, the release verifier, is permitted to call capture. The merchant allowlist is bound to the provider's own identity: the payee merchant id reported by PayPal must match the configured merchant account, or the operation fails closed. Currency and amount are bound to the authorized operation, and material changes are rechecked before capture.
Failure handling
The design treats a lost provider response as the central hazard. If a capture call times out, the escrow is marked UNKNOWN, never optimistically captured or failed. A reconcile() procedure re-queries PayPal for the authorization's true state and converges the ledger: captured if the money moved, voided with the reservation freed otherwise. Capture requests carry idempotency keys derived from the permit and claim identifiers, so a retried capture after a timeout cannot double-charge. The ledger and the provider converge through this recovery procedure; there is no claim of synchronous agreement between systems that can lose contact.
Revocation and the e-stop
Revoking a permit, the e-stop, stops future execution and voids outstanding uncaptured authorizations, including authorizations that complete while the e-stop is in flight: operations are tracked before the external authorization call, and capture admission rechecks revocation and expiry. The boundary is stated explicitly: a completed capture cannot be voided and needs a refund path, which is outside the prototype's scope.
Receipt ledger
Every decision, grant, check, authorization, capture, void, refusal, and reconciliation, is appended to an in-memory SHA-256 hash chain that is verified before each capture. The ledger's guarantees are stated narrowly: it detects internal modification of recorded entries. It is not cryptographically signed, it is not durable across restarts, and it cannot detect deletion of its trailing entries without a trusted external checkpoint. Those are documented boundaries, not features.
Implementation
Permit is written in Python with no required runtime dependencies beyond the standard library for the core. It integrates PayPal's sandbox REST API, using the Orders v2 authorize-and-capture flow. An HTTP service exposes the permit lifecycle, including a structured payer-approval continuation: when the payer has not yet approved, the service answers 202 approval_required with an approval URL, retains the operation, order, and reservation under an operation id, and resumes the same order after approval rather than creating a second one.
A ReAct-style agent runner operates through narrowly defined tools and has no direct access to PayPal credentials or the ledger's tamper surface. A six-beat demonstration exercises the lifecycle end to end: an allowed purchase, a blocked over-cap attempt with no outbound payment operation, an e-stop voiding a mid-hold authorization, a tampered-evidence refusal, and a dropped capture response recovered through UNKNOWN to reconcile. The test suite, 96 tests as of October 2026, covers the authority predicate, settlement, concurrency, crash recovery, and reconciliation.
Validation
In October 2026 the public repository was examined by an independent reviewer who ran the full test suite, executed the mock demonstration, and reproduced six failure modes offline against the then-current revision: an e-stop losing a race with an in-flight authorization, the merchant allowlist not being bound to the provider-reported payee, negative amounts increasing available budget, a failed void stranding cleanup, a pending capture reported as completed spending, and a missing HTTP continuation for buyer approval.
A reviewed patch addressing all six findings, with a regression test per finding, was merged and pushed the same day; the suite remained green and the README's claims were reconciled with the implementation. Independent re-verification of the patched revision had not yet been reported at the time of writing. Under the project's own evidence standard, the claim that the findings are closed is therefore provisional, not verified.
Limitations
- All authoritative state, permits, escrow mappings, revocations, and the ledger, lives in memory. A restart loses it.
- The prototype targets a single configured merchant; arbitrary-merchant support is not claimed.
- The integrated run against PayPal's live sandbox is documented in a runbook but had not been executed at the time of writing; the automated demonstration runs against a mock provider.
- There is no fulfillment verification: delivery evidence is model-supplied and matched against a precommitted quote, which demonstrates integrity of the evidence, not independent merchant fulfillment.
- Refunds, disputes, partial captures, and multi-currency handling are out of scope.
- The HTTP service binds to localhost with no caller authentication: a local demo boundary, not a deployment posture.
Development history
Permit was named and specified in early October 2026 as Richards' entry to the PayPal AI Hackathon. The repository was made public on October 2, 2026 under the MIT license. The same day, following the independent review described above, a reviewed patch closed the six reproduced authority and settlement findings and added timeout recovery as a sixth demonstration beat. Six Friday development milestones run October 9 through November 6, with submission targeted for November 11 ahead of the November 12, 2026 deadline (12:00 pm Pacific Time).
See also
- Interlock, the agent safety substrate Permit draws its leased-authority model from
- AEGIS, token governance for AI coding work
References
- Permit source repository. github.com/marsojuji-cmyk/permit (public, MIT).
- PayPal AI Hackathon official rules, including submission requirements, judging criteria, and prize structure. paypalaihackathon.devpost.com/rules
- PayPal REST API idempotency reference. developer.paypal.com/api/rest/reference/idempotency/
- Voiding an authorized PayPal payment. developer.paypal.com/checkout/void-authorized-payment/
- PayPal webhooks REST API, including retry behavior for failed deliveries. developer.paypal.com/api/rest/webhooks/rest/
- PayPal Orders v2 order request definition, including the payee object. developer.paypal.com/sdk/orders/v2/definitions/order_request
- PayPal authorize and capture checkout flow. developer.paypal.com/v5/checkout/auth-capture/