Skip to content

Site search

Type to search Pages

For agent platform engineers

Stop re-verifying every counterparty agent's claim from scratch.

On every cross-boundary transaction your agent re-authenticates the counterparty and re-checks its credentials from scratch. Signura lets it verify one signed attestation and rely on it at the point of decision instead.

At decision time

How your agent resolves a claim at runtime.

The same path each time a counterparty claim gates a transaction — query, verify, check status, then proceed within limits or escalate.

Query the exchange

Your agent sends the counterparty's claim — a licence being valid, a policy in force, a permission granted — to the reliance and verification API rather than re-investigating it against the counterparty itself.

Verify the proof

The agent verifies the cryptographic proof against the W3C Verifiable Credentials 2.0 substrate, confirming the attestation was signed by the issuer that stands behind it and reading the scope that issuer asserted.

Check freshness and revocation

The freshness and revocation engine returns current status, so your agent distinguishes a claim that is valid right now from one that was cached earlier and has since gone stale.

Proceed or escalate

Within the scope, value threshold and expiry your governor configured, the agent proceeds. Anything outside those limits is routed to a human as an escalation case rather than settled on agent discretion.

What your agent stack talks to.

Reliance and verification API

Query a claim and verify its cryptographic proof in the hot path, then proceed or escalate per policy-as-code. Metered per reliance event and priced below a fresh from-source verification, because the checking work has already been done and signed for.

Freshness and revocation engine

Real-time status that extends the proven OCSP pattern to assertions, so your agent can tell a currently valid claim from a stale one before it acts, and a revoked claim fails verification instead of passing silently.

Policy-as-code limits

Scope, value thresholds and expiry set by your governor are enforced on every reliance, so agent discretion stays inside bounds you can point to when a decision is later questioned.

Escalation routing

When a reliance request falls outside its configured scope, value threshold or expiry, the case is delivered to a human governor for approval or refusal rather than committed on agent discretion alone.

Building reliance before the inter-agent protocols settle.

The dependency you keep paying for

If you build agents that transact across organisational boundaries, you already know the shape of the problem. Each time your agent meets a counterparty it has not met before, it authenticates that party, re-checks its authority, and re-verifies whatever credential the transaction depends on. There is no shared way to rely on a check someone else has already performed, so the work is repeated pairwise, and the number of pairs grows faster than the number of parties.

The two escapes on offer are both unacceptable under fiduciary governance: trust the claim blindly and risk acting on an impersonation or a fraudulent assertion, or refuse to proceed and wrongfully reject valid transactions out of over-caution. Neither gives your governors something they can audit.

What the exchange changes

Signura removes the repetition without removing the accountability. An issuer signs the claim and names who stands behind it; your agent verifies that proof at the moment it acts and retains it. The attestation carries explicit scope, so you know exactly what was asserted and what was not. It carries revocation and freshness status, so a claim that was true last week but no longer holds fails verification. And it carries a named liable party, because transferable reliance without someone accountable for the claim is the gap the exchange exists to close.

Why it is not another protocol to bet on

You may be waiting to see which inter-agent protocol prevails before committing to a reliance layer. That caution is reasonable, and it is why Signura is not another protocol. It is built on the ratified W3C Verifiable Credentials 2.0 substrate and aligned with the direction of eIDAS 2.0, so the attestations you verify are standards-based artefacts rather than a proprietary format you would later have to unwind. The exchange is neutral by design: it sits between issuers and relying agents and takes neither side's part. If a transport later carries these credentials natively, standards-based attestations travel with it.

The integration surface is deliberately small. Your agent already extends OAuth 2.0 and OpenID Connect and defers delegated authorization to external identity providers per integration. Signura replaces the per-counterparty re-verification step with a single query-and-verify call and returns a proof you keep. Agent discretion is bounded by the scope, value thresholds and expiry your governor configures, and anything beyond those bounds is escalated rather than decided by the agent. No material commitment is made purely on agent discretion — the audit trail exists to make that accountability real rather than nominal.

For the build team

What engineers ask before wiring it in.

Where does this sit relative to my existing OAuth and OpenID Connect plumbing?

It sits above your identity and credentialing primitives, not in place of them. Your agent still authenticates as it does today; Signura supplies the reliance step on top — a verifiable claim about a counterparty that you check without standing up another per-integration identity provider.

Do I have to commit to one inter-agent protocol to use this?

No. Signura is not a transport protocol; it is a neutral exchange built on the ratified W3C Verifiable Credentials 2.0 substrate. The attestations you verify are standards-based artefacts, so they are not tied to any single proprietary format you would later need to unwind.

What does adding Signura cost me in integration work?

One query-and-verify call replaces the per-counterparty re-verification step you write today. Reliance is metered per event and priced below a fresh from-source verification, because the issuer has already done and signed for the checking work you would otherwise repeat.

How does my agent know an issuer is one we are allowed to rely on?

Your governor defines the admissible issuers and attestation types in the reliance policy. Your agent verifies a proof only against that admitted set; a claim from an issuer outside it is not relied upon automatically but surfaced for a human decision.

If a winning protocol later internalises reliance and revocation, is this wasted?

The attestations you verify are standards-based, so they can travel with whatever transport prevails. Signura's defensibility comes from neutrality between issuers and relying agents and an accumulating reliance corpus, not from a single proprietary mechanism you would be locked into.

Can I show exactly which claims my agent relied on afterwards?

Yes. Every reliance event is recorded in a tamper-evident evidence ledger showing which attestation was verified and that it was unaltered, so a questioned decision can be reconstructed for governance, liability or dispute resolution.

Bring one counterparty claim your agents must rely on.

Describe the transaction and the claim it turns on. A person reads it and replies — no from-source re-verification required to start the conversation.