Security Architecture & Trust Model

Transparent architectural guarantees, non-custodial operations, and cryptographic defense-in-depth on Base Mainnet.

🛡️

100% Non-Custodial

M2M Sentinel never accepts, stores, or handles private keys, mnemonic seed phrases, or transaction custody. Subscriptions and free tier challenges use standard cryptographic EIP-191 message signatures.

🔒

One-Way SHA-256 Hashing

API keys (sk_free_..., sk_live_...) are digested via salted SHA-256 before persistence. Even in the event of database exfiltration, plaintext credentials cannot be recovered.

⚡

Fail-Closed Isolation

All state validation and credit metering execute atomically in Redis Lua scripts. If primary persistence or RPC trust quorum becomes degraded, the engine fails closed with structured HTTP 503 errors.

Shared Responsibility Security Model

M2M Sentinel operates on a clear separation of security responsibilities across cloud infrastructure, application logic, and upstream blockchain nodes:

Security Layer	Provider / Owner	Enforced Controls
Platform & Edge Infra	Vercel Edge Network	TLS 1.3 edge termination, global DDoS mitigation, isolated ephemeral serverless container runtime (IAD1), encrypted edge environment variables.
Application Security	M2M Sentinel Engine	Zero-plaintext API key storage (SHA-256 salted hash), atomic Redis Lua state machine, PUSH-aware bytecode AST walker (preventing opcode spoofing), fail-closed payment state machine, URL credential refusal.
Blockchain Data & Consensus	Base RPC & Nodes	Multi-provider quorum consensus (≥ 2 independent Base mainnet nodes), Chain ID 8453 enforcement, bytecode hash integrity checks, fail-closed 503 on consensus mismatch.

Cryptographic Key Protection & In-Transit Security

M2M Sentinel enforces strict defensive boundaries across all network boundaries:

No URL Credentials: API keys and session credentials in query strings are rejected over HTTP to prevent proxy and log leakage. All authenticated calls require the x-api-key header.
TLS 1.3 Transport: All public traffic and upstream Redis connections require TLS encryption in transit.
Atomic Quota Consumption: Requests spend credits atomically only after successful completion; 404s, malformed inputs, and upstream failures cost zero credits.
Replay Defense: Free-tier challenge claims and on-chain payment intent registrations use single-use cryptographic tokens with persistent replay prevention markers.

RPC Trust Model & Provenance Levels

To eliminate reliance on single centralized RPC nodes, M2M Sentinel tracks multi-provider provenance for every observation:

HIGH_TRUST_PRIMARY: Observation confirmed by operator-credentialed Base archive node (e.g. Alchemy, QuickNode) over TLS with verified Chain ID (8453). Payment settlements accept only this trust tier.
QUORUM_PUBLIC: Result verified across at least 2 independent public Base consensus providers returning identical bytecode hashes.
DEGRADED_LOW_TRUST: Single anonymous provider response. The system automatically marks evidence unverified and prohibits on-chain settlement transitions.
UNTRUSTED_INSECURE: Plaintext HTTP endpoints or mismatched chain IDs; rejected immediately.

Responsible Vulnerability Disclosure

We welcome security researchers and developers to audit our platform, verify our open-source SDKs, and inspect our detection engines.

Reporting a Vulnerability

If you identify a security vulnerability, please disclose it responsibly by contacting our security team directly:

Security Contact: contact@m2msentinel.com

We acknowledge all legitimate reports within 24 hours and coordinate patches prior to public disclosure.