- Trusted request
- Verified path
- Authorized signer
- Policy passed
Trusted request and path verified.
How It Works
How SignTrail Decides Before a Signature
The three pre-sign questions, the ALLOW / HOLD / REJECT decision, and what changes before versus after SignTrail.
How It Works
Three Questions Before Every Signature
A transaction is signed only when the request, path, and signer are all verified.
- Request
- Approval
- SignTrail Gate
- Signature
- Asset Movement
Is the request unchanged?
- Canonical transaction payload
tx_payload_hash- Payload integrity
Did it come through a trusted path?
- Runtime event window
- Process chain
- File access
- Network egress
runtime_provenance_digest
Is the signer allowed to execute it?
signer_idpolicy_hash- Decision artifact
- Replay/TTL validation
Pre-sign decision
ALLOWHOLDREJECT
- All verifiedALLOWthe request is signed
- Needs reviewHOLDthe request waits for review
- Unsafe/manipulatedREJECTthe request is stopped
No trusted path, no signature.
Decision Outcomes
Allow. Hold. Reject. Before Signing.
SignTrail decides before signer execution — not after the transaction is broadcast.
ALLOW HOLD - Additional review
- New recipient
- Unusual runtime path
- High-risk method
- Policy exception
Needs manual review before execution.
REJECT - Payload mismatch
- Invalid decision artifact
- Unknown signer
- Runtime provenance mismatch
- Unsafe context
Unsafe context or manipulation detected.
Fail-closed by default when trust is missing.
Before / After
Before SignTrail vs After SignTrail
Before SignTrail
- Approver checked
- Signer checked
- Policy checked
- Execution path NOT checked
- Runtime not bound
- Evidence fragmented
Unsafe request may reach signer.
After SignTrail
- Request verified
- Path verified
- Signer verified
- Policy verified
- Decision artifact generated
- Audit recorded
Unsafe request is held before signing.
The difference is not who signs. The difference is whether the path can be trusted.