delegate signing without giving up keys
Delegate signing without giving up keys: hierarchical signatures explained
Delegation is the routine that breaks every key-management system. To let someone else sign on my behalf, I copy the key, share the share, mint a sub-credential, or grant API access, and from that moment the delegate has the same power I do, with weaker accountability. Hierarchical signatures change the granularity: the policy engine grants the right to sign a specific operation, under specific conditions, for a bounded period, without ever transferring the underlying key.
By Sue Pontius, Chief Executive Officer, Lokblok · Published 22 April 2026
Why conventional delegation fails
Sharing a key, even briefly, is custodianship transfer: the recipient now holds something they should not be trusted with for a moment longer than necessary, and you have no cryptographic guarantee they will not retain it. Sub-keys (intermediate CAs, derived signing keys, OAuth client credentials) reduce the blast radius but do not change the model, the delegate still holds material.
The audit story is also weak. Logs say 'a signature was produced'; they do not prove the signature respected the policy under which delegation was granted. Reconstructing 'did the delegate exceed their authority?' is forensic work after the fact.
Delegation as a policy-bound signing right
In a zero-persistence model, the underlying key is reconstructed inside hardware only when a quorum authorises an operation. Delegation becomes a policy: the delegate's identity is added to the set of acceptable callers, with constraints, operation type, value, counterparty, time window, geography, encoded in the policy that the quorum evaluates. The delegate never holds the key; they hold the right to trigger an authorised reconstruction within the policy boundary.
The audit chain is intrinsic. Every signature carries a hardware-attested record of which policy authorised it, which delegate triggered it, and which quorum members signed off. There is no 'unauthorised use of the delegated key' failure mode because there is no delegated key.
Side by side
| Dimension | Conventional approach | Zero-persistence reconstruction |
|---|---|---|
| What is delegated | Key material or a sub-credential | A policy-bound signing right |
| Delegate compromise blast radius | Everything the delegate could sign before revocation | Only operations within the policy bounds |
| Revocation | Re-issue or rotate keys | Update the policy; takes effect on the next operation |
| Audit | Logs of delegate activity | Cryptographic chain proving policy compliance |
| Bounded operations (e.g. value, counterparty) | Application-layer enforcement | Cryptographic enforcement at the signing step |
What this looks like in practice
- A treasury team delegating routine outflows to operations staff configures a policy that authorises sub-threshold transfers to a list of approved counterparties without operations holding the treasury key.
- An asset manager granting limited trading authority to a sub-advisor encodes the mandate (instrument list, position limits, time horizon) directly into the signing policy; off-mandate trades cannot be signed at all.
- A SaaS platform letting a third party sign artefacts on its behalf issues a per-tenant delegation that allows signing only artefacts matching the tenant's namespace, automatically expiring at the contract end date.
Related Lokblok material
- hierarchical signatures with cryptographically enforced approvals
- Phantom Secrets™ as the underlying key-derivation protocol
- MiCA-aligned institutional custody flows
About the author
Sue Pontius
Chief Executive Officer, Lokblok
Sue Pontius is CEO of Lokblok, where she leads the company's work on zero-persistence cryptography for digital assets, identity, and high-assurance custody.
View LinkedIn profile →FAQ
- How is this different from a sub-key or derived key?
- A sub-key is still a key the delegate holds; revoking it requires action and propagation. A policy-bound signing right grants no key material, the delegate triggers the reconstruction of the parent key under quorum control, and revocation is a policy update that takes effect immediately.
- Can the policy enforce arbitrary business rules?
- Within practical limits, yes. Common constraints include operation type, payload patterns, counterparty allow-lists, value thresholds, time windows, geography from the device attestation, and required co-signers. Anything that can be evaluated deterministically against the operation request can be made part of the policy.
- What happens if the delegate's identity is compromised?
- An attacker impersonating the delegate can only trigger operations the policy already permits. They cannot exfiltrate the key (it does not exist between operations), they cannot widen the policy without quorum approval, and every action is bound to the delegate's identity in the audit chain.
- Is this compatible with hardware wallets and existing signing devices?
- Yes. The reconstruction happens inside a certified secure element; the delegate's role is to authenticate to the quorum and trigger an operation. Their device can be a hardware wallet, a Toughkey™, a phone with attestation, or an integrated CI runner.