Defensive Publication: Compilation of a Passkey-Signed Work Mandate into a Machine-Checkable Execution-Gating Policy

Abstract

A method for converting a human-authored, cryptographically signed "Work Mandate" document into a compiled, machine-checkable policy artifact that constrains the runtime execution of an autonomous software agent. The mandate is signed by the authorizing human using a passkey (WebAuthn/FIDO2) credential prior to compilation. The compiled policy's content hash and the scope it authorizes are carried forward into every execution receipt the agent produces, so that any receipt can be checked against the original signed mandate without re-parsing prose, and the agent cannot silently exceed what the human actually authorized.

Field and problem

Autonomous agents (LLM-driven or otherwise) are increasingly authorized to take actions - call tools, move funds, submit filings, sign documents - on behalf of a human principal. The conventional approach is to give the agent a natural-language instruction ("do X, but not Y") and trust the agent's own adherence to it. This has two known failure modes: (1) natural-language instructions are not machine-verifiable, so nothing outside the agent's own reasoning enforces the boundary; (2) even when an execution log or receipt is produced, there is no cryptographic linkage between that receipt and the original human-authorized scope, so a reviewer cannot algorithmically confirm the agent stayed inside its mandate - they must re-read prose.

Prior approaches in access control (RBAC, ABAC, OAuth scopes) constrain which API calls are permitted, but do not compile a human-signed natural-language authorization document into a policy whose hash is then propagated into a receipt chain, and do not require a passkey-class signature specifically as the authorization step prior to compilation.

Detailed description of the novel mechanism

1. Authoring. A human principal authors a Work Mandate: a structured document stating the scope of work an agent is authorized to perform (e.g., permitted tool/kernel names, resource limits, time window, monetary caps, escalation conditions).
2. Signing. The principal signs the mandate document using a WebAuthn/FIDO2 passkey credential bound to their identity. The signature covers the canonicalized byte content of the mandate (e.g. JCS-canonicalized JSON or an equivalent deterministic serialization), producing a verifiable assertion that this specific human authorized this specific scope at this specific time.
3. Compilation. The signed mandate is compiled - deterministically, not by an LLM - into a machine-checkable gated policy: a structured, enumerable set of allow-rules (e.g. "kernel X may run with inputs matching schema Y, at most N times, before date Z"). Compilation is a pure function of the signed mandate content; the same mandate always compiles to the same policy, and the compiled policy's own content hash is computed and retained.
4. Binding at execution time. Each time the agent invokes a gated action, the runtime checks the requested action against the compiled policy before execution. If the action is outside the policy's allow-set, execution is refused (or routed to a human escalation path) rather than attempted.
5. Propagation into the receipt. When an action is executed within the mandate's scope, the execution receipt produced for that action includes: (a) the compiled policy's content hash, (b) the original signed mandate's content hash, and (c) an indication of which specific mandate clause authorized the action. This means any third party holding only the receipt and the (public or disclosed) mandate can verify - without trusting the agent's own report - that the action was within scope, without needing to re-run the agent or manually interpret prose.
6. Chain verification. Because every receipt in an agent's execution history carries the mandate hash, a verifier can confirm that an entire sequence of actions was performed under a single, consistent, human-authorized mandate, and can detect the moment (if any) a mandate was changed, revoked, or superseded, since a changed mandate produces a different hash.

Variations

• The signing credential may be any asymmetric-key credential recognized as principal-bound (passkey, hardware security key, did:key), not limited to a specific passkey vendor.
• The compiled policy may be expressed as an allow-list, a deny-list, or a hybrid, provided compilation remains deterministic and the compiled artifact's hash is retained.
• The mandate may include time-boxed or usage-boxed grants (expires after N uses or after a wall-clock deadline), with expiry enforced at the pre-execution gate check.
• Escalation: an action that does not match any mandate clause may be routed to a human-review queue and recorded as an "escalation" receipt rather than being silently refused, preserving an audit trail of near-misses.

Prior-art context

Existing OAuth/API-scope systems constrain calls to known scopes but do not compile a human-signed natural-language mandate document into that scope set, nor propagate the mandate's own hash into a downstream receipt chain. Existing audit-log and workflow-engine systems record what an agent did but do not cryptographically bind that record back to a specific human-signed authorization artifact whose hash travels forward as a first-class field of every receipt.