Security

We sell governance. So here is ours.

GateCore's job is refusing the wrong action and proving the right one. This page describes the security model exactly as it ships today — what's cryptographically enforced, how the system fails, and what evidence it leaves behind.

EVERYTHING BELOW IS BUILT AND RUNNING · NOT A ROADMAP

The crypto model

Every request proves itself before anything else happens.

There are no shared API keys and no bearer tokens standing in for an agent. A request is an Ed25519 signature over a canonical payload, and it clears this path — in order, every time.

SIGNATURE

Ed25519 over the canonical request payload — the request says what was signed, or it doesn't run

VALID

REPLAY

Unique request id plus a per-key nonce, reserved atomically — a captured request can't be replayed

FRESH

FRESHNESS

Signatures expire on a short window (five minutes by default) — stale requests are refused outright

IN WINDOW

KEY

Full key lifecycle — issued, rotated, revoked, expired. A revoked key fails on its next request

ACTIVE

GRANT

Key, agent, and access grant must all agree — approved, in scope, and funded — before execution

BOUND

RECORD

Every verification step — pass or fail — lands as an audit event with the key and reason attached

LOGGED

Any single failure refuses the whole request — DENY — before policy, pricing, or money is ever touched. Signed payloads and receipts use versioned, domain-separated formats, so a signature for one purpose can never be replayed as another.

Fail-closed posture

When anything is uncertain, the answer is no.

Security postures are defined by their failure modes. Ours is uniform: misconfiguration, ambiguity, or partial failure resolves to refusal — never to open.

Refusal is the default

Nothing unverified executes.

Unsigned or unverifiable requests are refused. The legacy unsigned mode exists for local demos only, ships disabled, and production refuses it.
Production refuses to start with unsafe defaults — development secrets or a missing admin token stop the boot, they don't degrade it.
Policy is declarative and ordered — allow, throttle, modify, hold, or deny; first match wins, and every decision names the rule that made it.
Even this website's access gate fails closed: unconfigured means unavailable, not open.

Money can't outrun the gate

Funds move only on proof.

Reserve before execute — funds are held before the action runs, captured on success, released on failure. Nobody pays for work that didn't happen.
Sensitive actions hold for human review with funds in escrow; a rejection releases the hold, and the reviewer's decision joins the signed record.
The ledger is append-only and non-negative by construction, and settlement operations are idempotent — retries can't double-move money.

The evidence chain

Don't take our word for anything. That's the design.

Most platforms answer "how do we know?" with logs you have to trust. GateCore's answer is cryptographic evidence that holds up without trusting GateCore.

§1

Signed receipts

Every executed action produces an Ed25519-signed receipt covering its verification, policy decision, price, and settlement facts — verifiable by any third party, offline, against a versioned receipt format.

§2

Hash-chained ledger

Every cent moves on an append-only, per-account hash chain. Altering history breaks the chain visibly — tampering isn't prevented by policy, it's evident by construction.

§3

Attributed decisions

Every allow, hold, and deny names the rule, the key, and the human when one was involved. Every key verification and access check — including failures — is its own audit event.

This is the same evidence we hand to prospects, auditors, and counterparties. There is no separate "compliance view" — the evidence chain is the system of record.

Supply chain

The quietest attack surface, kept deliberately small.

The 2025 npm worm waves compromised packages through install-time scripts and self-propagated through maintainer credentials. Our posture treats that class of attack as a standing threat, not a news story.

STATIC FRONT DOOR

This website is static HTML — no npm, no build step, no dependency graph to poison.

4 RUNTIME DEPS

The operator console runs four runtime npm dependencies. Adding one is a reviewed decision that names the package, the need, and its transitive weight.

IGNORE-SCRIPTS

Install-time lifecycle scripts are disabled for every npm install, local and CI — the worm class's primary vector doesn't run here.

LOCKFILE-EXACT

CI installs exactly what the committed lockfile says. New versions can't inject themselves between reviews.

7-DAY COOLDOWN

Dependency updates wait out a seven-day cooldown before they're even proposed — freshly poisoned releases in this attack class were typically yanked within days — then land as one human-reviewed batch, never a rubber-stamped trickle.

PINNED PYTHON

Backend services are Python with pinned, per-service requirements, audited per service in CI. CodeQL and dependency review run on every pull request.

Dependency audit status at last review (2026-07-11): zero advisories, production and full tree.

FOUND SOMETHING? Security reports go straight to the founder: [email protected]. We'll respond, credit you if you want it, and tell you honestly what we did about it.