Security and Recovery

Protect Auto Drive credentials and recover safely from uncertain operations.

Storage and blockchain operations can finish remotely even when the local process loses its response. Recovery should preserve evidence without turning uncertainty into duplicate work.

Required controls

Risk	Minimum control
Credential theft	Server-side secrets, least privilege, rotation, redacted errors, and no browser bundling
Oversized or malicious payloads	Schema allowlist, byte and nesting limits, quotas, and validation before and after storage
Resource exhaustion	Deadlines, cancellation, bounded concurrency, backpressure, and rate limits
Stored-content injection	Treat reads as untrusted; escape output and prohibit direct HTML, shell, template, or evaluator use
Wrong transaction approval	Bind the signer, account, network, recipient, fees, payload identity, and exact transaction bytes
Duplicate uncertain operation	Preserve dispatch evidence and reconcile external state before any retry

Interrupted-operation procedure

1

Stop automatic retries

An upload or submission may have completed even if the application did not receive the response.

2

Inspect non-secret evidence

Compare the intended payload identity, operation identifier, timestamps, and last dispatch state. Never retain provider credentials, wallet secrets, or raw authentication headers in evidence.

3

Query external state safely

Use authenticated, rate-limited, read-only lookups through public typed libraries. Validate identity inputs before sending a provider request and cap the duration and number of lookups.

4

Decide explicitly

Classify the operation as absent, present, finalized, failed, or still uncertain. A human or an application-specific recovery policy should decide whether a new operation is appropriate.

Hidden GitBook pages can still be reachable by direct URL after publication. Never use page visibility to protect secrets or private implementation details.