Product

See every claim your agents relied on, and who stands behind it.

Signura gives you an issuer service, a verification API, a freshness engine, an evidence ledger and a governance console — the working parts behind reliance at decision time.

See it verified How price is set

The five parts you operate.

Issuer attestation service

An issuer's AI colleague drafts a signed Attestation against verified source facts, sets its scope, expiry and liability terms, and publishes it to the exchange. Before anything is issued, a human governor approves which facts the organisation will stand behind. You see each published attestation with the party named as liable.

Reliance and verification API

When your agent needs a counterparty's claim, it queries the exchange, verifies the cryptographic proof, and records the check as a Reliance Event. Inside your configured limits it proceeds; outside them it opens an Escalation Case rather than acting. Verified reliance is metered per event.

Freshness and revocation engine

Every proof carries freshness and revocation status, extending the established OCSP status pattern to assertions. At the moment your agent checks a claim, the engine reports whether the attestation is currently valid or has been withdrawn — so a stale claim is not mistaken for a live one.

Evidence and audit ledger

Each Reliance Event lands in a tamper-evident ledger as an Evidence Record: the claim, its scope, the named liable party, and the proof that was verified. When a past decision is questioned, your governor retrieves the record instead of reconstructing it from scattered logs.

One reliance, end to end

What happens when your agent acts.

The same path a claim follows, from the issuer's decision to the record your governor can retrieve.

Issue and publish an attestation

An issuer's AI colleague signs attestations against verified source facts within the policy its governor already approved, sets scope and expiry, and publishes them to the exchange. Your agents then see those attestations available to consume, each carrying its named liable party.

Rely at decision time

Your agent queries the exchange for the counterparty's claim, verifies the proof and checks its freshness and revocation status. It proceeds within the limits your governor configured, or hands ambiguous and high-risk cases to a person.

Revoke and propagate

When an underlying fact changes, the issuer revokes the attestation and the engine propagates the withdrawal to relying parties — so no agent keeps acting on a claim the issuer no longer stands behind.

Assemble evidence for a review

For any past decision, your governor opens the audit ledger and retrieves the Evidence Record showing which attestations were verified and that they were unaltered, ready for compliance, liability or dispute resolution.

Where the limits sit

What is enforced, and by whom.

The controls are part of the product, not settings you bolt on afterwards.

Agent discretion is bounded

Every agent operates inside configurable scope, value thresholds and expiry. Anything beyond those bounds is routed to an accountable human as an Escalation Case, so no material commitment is made on agent discretion alone.

AI colleagues run, humans decide

AI colleagues do the recurring work — issuing attestations, propagating revocations, running freshness checks, assembling evidence. Humans hold the consequential choices: what an issuer will stand behind, and which issuers a relying party may depend on.

Neutrality is a technical limit

The operator's obligations stop at the integrity of the proof and the accuracy of freshness and revocation status. Signura verifies and records; it never authors the underlying fact, so the accountable party remains the issuer named on the attestation.

Signed, and recorded

Attestations are cryptographically signed on the ratified W3C Verifiable Credentials 2.0 substrate with a revocation mechanism, and every reliance event is written to a tamper-evident ledger. Liability terms are attached before any reliance occurs.

The direction of the product.

Read this as direction

The sequence below describes what we are building toward with design partners, not commitments with fixed dates. We would rather state the path plainly than promise features we have not shipped.

Near term: one flow, real partners

The first working flow runs issuer to relying party for one or two attestation types — licence validity, policy status, certification, granted permissions — with a small group of design partners. Cryptographic verification and revocation are live, and the evidence ledger records every reliance event.

Reliance is metered per event so both sides can weigh it against the cost of a fresh verification, and so we replace assumption-based unit economics with figures from real usage.

Next: more types, more issuers

Coverage widens to multiple attestation types and a growing roster of issuers and relying parties. The governance console gains full value-threshold, scope and expiry controls with escalation routing, and early EU-facing eIDAS 2.0 conformance work begins.

Two-sided network effects become observable as relying parties reuse the same issuers rather than re-integrating each one.

Further out: a self-serve exchange

The exchange opens a self-serve onboarding path for issuers, standardised attestation schemas for common facts, and audit exports that feed external governance and dispute-resolution processes.

Pricing spans issuance fees, per-reliance usage and attestation-management subscriptions, with the neutral position between accumulating issuers and relying parties becoming the defensible one.

Before you integrate

How it works in practice.

How does my agent integrate with the exchange?

Your agent calls the reliance and verification API: it queries the exchange for a counterparty's claim, verifies the returned proof cryptographically, and either proceeds within its configured limits or opens an escalation. The check is recorded as a reliance event without any change to how your agent authenticates its own identity.

How do I know a claim is valid right now, not cached?

Each proof carries freshness and revocation status. At decision time the engine reports whether the attestation is currently valid or has been withdrawn, so your agent can distinguish a live claim from a stale one before it acts — rather than relying on when the claim was last seen.

What happens when a reliance falls outside its configured limits?

It does not proceed on agent discretion. When a request exceeds its scope, value threshold or expiry, the runtime opens an Escalation Case in the governance console for a human governor to approve or refuse. The outcome, and who decided it, is written to the evidence ledger.

Who sets which issuers our agents may rely on?

Your human governors do, in the admin console. They define the Reliance Policy — the admissible issuers and attestation types, and the value thresholds and expiry that bound agent discretion. Agents operate only within those settings; changing them is a governor action, not an agent one.

What does an issuer do to publish its first attestation?

An issuer's governor approves which facts and liability the organisation will stand behind. Its AI colleague then signs attestations against verified source facts, sets scope and expiry, and publishes them for relying parties. The MVP covers a narrow set of high-frequency common facts to start.

Do I have to rely on Signura itself as a party?

Only for the integrity of the proof and the accuracy of freshness and revocation status. The party that stands behind a claim is the issuer, named on the attestation with scoped liability terms. The exchange is neutral by design and does not take either side's part in a reliance.

See a reliance verified end to end.

Bring one attestation type and one counterparty claim. We will walk it from a signed fact to a retrievable evidence record.

Request a walkthrough

Site search