Signing Boundary Policy

An application that holds a signing key can be made to sign anything, and an application that requests signatures from a hardware module with no policy can request anything. In both cases the compromise of application code is the compromise of the asset.

Policy at the signing boundary changes that: destination allow-lists, value ceilings, velocity limits and time-of-day constraints evaluated by the module rather than by the caller. A compromised application can then request only what policy permits.

Why it matters

Application code is the largest and most frequently changed attack surface in the system — dependencies, deployments, developer access, injection paths. Making it non-load-bearing for the highest-consequence operation is the strongest available structural control.

Policy expressed in application code offers no protection against the failure it is supposed to address, which is the single most common misunderstanding in custody design.

Implementation patterns

• Keys never leave the hardware boundary. The application requests a signature; it never holds material.
• Policy evaluated at the boundary, with the module refusing requests outside it.
• Tiered custody: cold storage for the majority with keys never network-connected, a warm hardware-backed tier for replenishment, and a hot wallet capped at expected short-horizon volume. The hot balance is the maximum single-incident loss, which makes its size a risk decision rather than an operations convenience.
• Multi-party approval above a threshold, with genuinely separate credentials, devices and people. Segregation that shares an identity provider account is not segregation.
• Every signature request and decision logged immutably, including refusals.
• Continuous reconciliation between recorded liabilities and actual holdings, which detects a loss regardless of how it occurred and is the control that must never be skipped.
• Automated holds rather than alerts on anomalous patterns, since an alert during a drain is too slow.
• A tested emergency halt, exercised so that invoking it is not itself a risk.

Industry example

Exchanges and custodians such as CoinDCX operate exactly this spectrum, and the design question is always where to sit on it rather than how to escape it. The organisational requirement is the test that matters: can any single credential — including a root cloud account or a database administrator — cause an outbound transfer? If yes, the segregation exists on paper.

The same pattern applies outside crypto to payment initiation, treasury operations and any system authorising irreversible external transfers.

Failure scenarios

• Policy in application code, defeated by application compromise.
• A hot wallet sized for convenience, setting the maximum loss without anyone deciding it.
• Approvals sharing an identity provider, so one account compromise satisfies both.
• No reconciliation, so a loss is discovered externally.
• An untested halt, which either does not work or is too risky to invoke.

Trade-offs

Policy at the boundary is inflexible by design. A legitimate operation outside policy requires a slower process, and that friction is the point — but it means the platform cannot respond quickly to unusual legitimate demand, and pressure to loosen the policy is continuous.

The mitigation is a documented, approved, time-bounded exception path rather than a permanently permissive policy, so the loosening is visible and reverts by default.

Interview question

"Your application server is fully compromised. Walk me through what the attacker can and cannot do to customer funds, and tell me which of your controls is doing the work in each case."