Security

Signing keys, reporting, and what the public implementation does not prove.

Inntris asks you to verify its evidence rather than trust it. That only works if the key you check against, the way to report a problem, and the limits of the published claim are all in one place you can read without an account.

Signing keys

Pin the key from one channel. Cross-check it against the other.

A verifier is only as independent as the key it checks against. Without a pinned key, a valid signature proves the artifact is internally consistent — not that Inntris produced it.

Channel one — this site

The published key registry mirror, served from the Inntris domain.

inntris.com/.well-known/inntris-keys.txt

Channel two — the verifier repo

KEYS.md and SHA256SUMS in the public verifier repository.

github.com/Inntris/inntris-verify

The two channels are controlled independently, so an attacker must compromise both to substitute a key. On any discrepancy between them, treat verification as failed and write to sales@inntris.com.

Reporting

Report a vulnerability or a key discrepancy.

sales@inntris.com

One address handles commercial, technical and security mail. Put “Security” in the subject line and it is triaged first.

Please report privately first and give us a reasonable window to respond before disclosing publicly.
Include the artifact — a receipt ID, an evidence pack, or a decision envelope — and the verifier output you saw.
We acknowledge security reports within one business day.

Published boundaries

What the public implementation is not evidence of.

The public implementation is a reference architecture. Listing its limits is cheaper than having a reader find them, and the same list is published in the technical pilot document and the x402 repository so the three cannot drift apart quietly.

Custody and recovery
No HSM-grade key custody or disaster-recovery guarantees. The managed signer path is planned, not proven.
Durable state
The public reference implementation uses in-memory nonce, decision and approval stores. A production deployment requires a durable, atomic store shared across executors.
Cumulative limits
Reference cumulative spend tracking is not a distributed ledger and requires an atomic durable store in production.
Follow-on packages
The AP2 and A2A gates are reference implementations on main. They are not evidence of a deployed production service.
Performance
No production latency or throughput figures are claimed.

Verifiers

Two artifacts. Two verifiers. Neither substitutes for the other.

The evidence-pack verifier does not verify decision envelopes. The decision verifier does not verify evidence packs. We do not claim otherwise.

Evidence packs

Signed pack manifest, file hashes in both directions, receipt fingerprints, agent signatures and Merkle inclusion proofs. Python standard library only.

github.com/Inntris/inntris-verify

Payment decisions

Decision schema, fingerprint, Ed25519 signature, action hash and binding, expiry at a supplied execution time, policy version and payment-requirements binding. Offline by default.

github.com/Inntris/inntris-x402-policy-adapter