Whitepaper V4.1
21. Security Architecture and Post-Quantum Cryptography
The legacy whitepaper used broad claims around Dilithium and Falcon. The current NIST position is more precise. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are finalized post-quantum signature standards. Falcon/FN-DSA has been selected for standardization but its FIPS standardization remains under development as of this edition.
IONON should therefore state finalized standards by their current names and describe any FN-DSA/Falcon use as implementation-specific or roadmap unless the deployed component can prove conformance to a final standard.
The security model is defense in depth:
- hardware-backed or otherwise strongly protected signing keys;
- least-privilege wallet and tool access;
- deterministic policy authorization;
- simulation before value-moving actions;
- rate limits, timelocks and approval quorums;
- bridge and adapter circuit breakers;
- append-only evidence;
- independent monitoring;
- reproducible builds and signed releases;
- software-supply-chain scanning;
- contract audits and continuous bug bounty;
- crypto-agility so algorithms can change without rewriting business logic.
IONON should not publish implementation details that create unnecessary exploit surface, but “security through obscurity” is not a substitute for independent review.
21.1 IONON Intelligence software-supply-chain security
A model/agent hub introduces risks that are different from a token contract. Before IONON Intelligence accepts third-party artifacts at scale it should implement signed provenance, malware scanning, secret scanning, unsafe serialization detection, license metadata, immutable hashes, publisher identity, versioned model/agent cards and quarantine workflows. Hugging Face's public security model demonstrates the direction: MFA/SSO, signed commits, malware scanning, pickle scanning, secret scanning and external scanning are now baseline expectations for serious AI artifact hosting.
21.2 Security control families
The public Security Center should map controls into at least seven families: Identity & Access, Key Management, Application Security, Smart Contracts, Agent/Model Supply Chain, Network/Cloud, and Incident/Recovery. Each control has an owner, evidence artifact, test cadence and status. A control without evidence is a policy statement, not an operating control.
21.3 Agent-specific threat model
V4 explicitly includes prompt/tool injection, confused-deputy behavior, over-broad delegated permissions, malicious MCP servers, poisoned model/tool artifacts, stale policy context, replayed authorizations, compromised memory, deceptive UI confirmations and model-induced routing errors. Financial authorization remains deterministic precisely because probabilistic intelligence cannot be the final control for value-moving actions.