Security, Encryption and Passkey MFA

Security Architecture

Evercore is designed with a security-first, stateless architecture. No plaintext data ever touches Evercore infrastructure — encryption is enforced before any data leaves your environment.

The request lifecycle is:

1. Client encrypts the payload using AES-256-GCM with a key you control 2. Ciphertext is transmitted to the Evercore API over TLS 1.3 3. Evercore validates the request, applies Arweave tags, and forwards the ciphertext to the Arweave network 4. The Arweave transaction ID is returned to the client 5. No plaintext or key material is retained at any point

Encryption Standards

Data at Rest

All data stored on Arweave is encrypted using AES-256-GCM before upload:

• Algorithm: AES-256-GCM (NIST SP 800-38D) • IV: 96-bit random nonce generated per file • Auth Tag: 128-bit GCM authentication tag, stored on-chain as metadata • Key Material: Derived via PBKDF2-SHA256 (minimum 310,000 iterations) or Argon2id where supported

The encryption IV and authentication tag are stored as Arweave transaction tags (publicly visible), but key material is never stored anywhere by Evercore.

Data in Transit

• TLS 1.3 is required for all Evercore API endpoints — TLS 1.2 connections are rejected • Certificate pinning is recommended for mobile and CLI integrations • Arweave gateway communications are TLS-encrypted with certificate validation

Key Management

Evercore follows a strict zero-knowledge model with respect to encryption keys:

• Keys are derived client-side and are never transmitted to or stored by Evercore • API keys used for authentication are stored as bcrypt hashes — plaintext is never retained • Arweave wallet JWKs are managed via Encore.dev secrets and are encrypted at rest in the secrets store • Key rotation policies are enforced for all internal service credentials

Infrastructure Security

Evercore runs on Encore.dev managed infrastructure with the following controls:

• Network isolation: services communicate over private, authenticated channels • Principle of least privilege: each service component has only the permissions it requires • Dependency scanning: automated vulnerability scanning on every build • Container hardening: minimal base images with no unnecessary packages • Secrets management: all credentials managed via Encore.dev's encrypted secrets store — no .env files in production • Rate limiting: per-IP and per-API-key rate limits enforced at the API gateway layer

Arweave-Specific Considerations

Because Arweave is a public, immutable ledger, the following considerations apply:

• Transaction IDs and tags are publicly visible — do not include sensitive metadata in plain tags • Ciphertext is public but unreadable without the decryption key • Once data is confirmed on-chain, it cannot be deleted — choose carefully what you upload • Arweave gateway nodes are operated by third parties; use HTTPS gateways only • Multi-gateway redundancy is supported to avoid single-point-of-failure on retrieval

Access Control

API Authentication: • API keys are required for all non-public endpoints • Keys are scoped to specific operations (read, write, admin) • Compromised keys can be revoked instantly from the dashboard • All key usage is logged with IP, timestamp, and endpoint

Wallet Authentication: • User-signed transactions use ArConnect or compatible Arweave wallet signatures • Evercore verifies wallet ownership without ever holding private keys • Wallet pool management is gated behind admin-level API keys

Multi-Factor Authentication (Passkey)

Evercore supports WebAuthn/Passkey-based multi-factor authentication for administrative API keys. This adds a second verification layer using biometrics (Face ID, Touch ID), platform authenticators (Windows Hello), or physical security keys (YubiKey).

How It Works

MFA is bound to individual API keys, not browser sessions:

• Passkeys are registered via the WebAuthn standard (FIDO2) • The authenticator's private key never leaves the device — only the public key is stored server-side • Each authentication produces a signed challenge response verified by the server • A short-lived MFA proof token (15 min TTL, HMAC-signed) is issued on success • The proof token is sent via the X-Evercore-MFA header for step-up operations • The proof is cryptographically bound to the requesting IP and device — a captured token cannot be replayed from another network or browser

Step-Up Authentication

Step-up is an opt-in control you toggle per API key from your profile. When enabled, the most sensitive actions require a fresh passkey tap (a proof issued within the last 2 minutes), not just a valid session:

• GDPR erasure — create, approve, and execute (irreversible crypto-shred) • API key creation, revocation, and rotation • Arweave wallet changes and Hedera operator credential changes • S3 credential minting and revocation • Encrypted transfer creation/revocation and compliance-control changes

Autonomous agents act with your API key, so while step-up is on they cannot perform these actions — they receive an explicit denial so a human completes them. Disabling step-up itself also requires a fresh tap.

Security Properties

• Cloned-authenticator detection: signature-counter regressions are rejected • Replay protection: proofs are bound to IP + device and verified against stored hashes • Rate limiting: per-request throttling plus a 30-minute lockout after 5 failed attempts • Origin validation: RP ID and origin are strictly verified to prevent phishing • Recovery codes: 10 single-use backup codes for passkey-less recovery • Mandatory enrollment (optional): deployments can require a passkey before any access • Multiple credentials: up to 10 passkeys per API key for device redundancy • No shared secrets: WebAuthn uses public-key cryptography — no TOTP seeds or shared codes

Compliance & Certifications

Evercore's encryption and stateless architecture supports compliance with:

• HIPAA: AES-256-GCM encryption satisfies the HIPAA encryption safe harbor for PHI. Evercore does not store PHI. Customers requiring a BAA should contact us. • GDPR: The stateless design means Evercore holds minimal personal data. See Privacy Policy for details on data subject rights. • SOC 2 (in progress): We are pursuing SOC 2 Type II certification. Contact us for our current security attestation documentation. • ISO 27001: Infrastructure security policies align with ISO 27001 controls.

Note: Compliance is a shared responsibility. Customers must implement appropriate controls within their own environments.

Vulnerability Disclosure

We take security vulnerabilities seriously. If you discover a security issue in Evercore, please report it responsibly.

How to report: • Email: {{email}} • PGP key available on request for encrypted communications • Please include: affected component, reproduction steps, potential impact

Our commitment: • We will acknowledge receipt within 48 hours • We will provide an initial assessment within 7 days • Critical vulnerabilities will be patched and disclosed within 90 days • We do not pursue legal action against good-faith researchers who follow this policy

We do not currently offer a bug bounty program, but significant findings will be recognized in our changelog.