Security Boundaries

Threat model and production boundaries

EdgeORE's review candidate has useful defensive logic, but it is not a production security certification. It is debug-signed and includes debug/test surfaces that should be reviewed before a production release. The safe public claim is a gated review candidate with specific tested properties and remaining runtime checks. A self-awarded ten-out-of-ten audit score would contradict the project's own evidence discipline.

Identify assets and authorities

Wallet signing keys remain in the wallet. Node pairing credentials and receipt keys are different assets with their own storage and use policies. Plaintext documents sent to an AI host, local vault contents, operation state and exported receipts also need protection. Do not summarize all of these as keys never enter the app; that statement is accurate for wallet private keys, not a description of every app-managed key.

List who can make decisions: the user reviews and approves transactions, the wallet signs, the RPC reports observations, the node enforces scopes, the app key signs receipts and a future evaluator may judge service delivery. Each authority can fail or be compromised in different ways. A Solana transaction cannot make an off-chain evaluator honest simply by storing its decision.

Model likely failure paths

Consider altered wallet returns, duplicate taps, unavailable RPC, corrupted operation files, oversized imports, wrong TLS pins, stale telemetry and host cancellation ambiguity. These correspond to existing defensive code and test areas. Also consider compromised endpoints, leaked session credentials, weak recovery procedures and misleading public claims. Security includes how the user interprets a state, not only cryptographic primitives.

Hardware-backed keys improve extraction resistance but do not run arbitrary AI models inside StrongBox. A signed result hash can still represent an incorrect or fabricated result if the app supplied it. Remote attestation needs a verifier, freshness, trust anchors and a defined claim. Do not promise virtually impossible spoofing or TEE proof of compute from a generic Keystore signature.

Prepare a production hardening backlog

Review debuggable flags, exported activities, test components, backup/data extraction rules, network security configuration, dependency notices and release signing. Remove or constrain debug/test surfaces in the release variant and test the resulting binary. A release build changes artifact identity and may require a new qualification run. Signing with an owner keystore is a separate operational step, not a reason to claim the current debug artifact is unsafe for an isolated devnet test.

Do not place the release keystore or its passwords in the repository, documentation ZIP or agent prompt. Define key backup, access and rotation procedures before using it for a public distribution channel. Review the APK certificate and package upgrade path. A lost or changed signing key affects updates and data continuity, so the policy should be deliberate rather than improvised at publication time.

Publish limits beside strengths

A security page should name exact-message review, signature verification, durable operations, bounded I/O and pinned/scoped node access, then state the remaining runtime and production boundaries. Link preserved tests and qualified artifacts. Avoid implied partnerships, production guarantees or blanket privacy claims. The exercise is to take one marketing sentence and list the evidence required for it; if the evidence does not exist, narrow the sentence rather than inflate the ledger.

---

Wiki home · Qualification updates · Sources and credits