Turn any action
into verifiable proof.The attestation API — seal any agent or system action as a quantum-safe, tamper-evident receipt.
Send an action, get back a tamper-evident receipt: what happened, when, and that it hasn't been altered — signed with post-quantum cryptography and verifiable by anyone, without trusting us. Making "produce evidence" a single call, so verifiability is as easy to add as a log line.
Actions happen.
Then they're gone.
An agent decides, a payment clears, a config changes, a file is exported. Each is a moment that mattered — and by default, all you keep is a log you have to trust the keeper of. When it's disputed, "our records say" isn't proof.
Cross the plane,
become evidence.
The action passes through one signing call. On the other side it isn't just a record — it's a signed, tamper-evident attestation. The exact moment a thing that happened becomes a thing you can prove.
What, who, when —
sealed.
The receipt records the claim about the action and binds it with a quantum-safe signature. Alter it and the signature breaks. It proves integrity and provenance — that this exact statement existed then, unchanged — not that the action was wise. Honest scope, durable proof.
Check it yourself.
Don't call us.
Verification is checking a signature against public material — anyone can do it, independently, even if you stop using RankShield. The verifier is not the vendor. Evidence that only its issuer can vouch for was never really independent.
Every action,
a receipt.
One primitive seals an agent's decision, a financial intent, an audit event. It's the layer beneath agent passports and governance: passports say who, the attestation API says what was done — as proof you can hand to an auditor, a counterparty, a regulator.
What is the attestation API?
The attestation API is a single interface that turns any action into verifiable proof: you send it a description of what happened, and it returns a tamper-evident, quantum-safe-signed receipt that records the action, when it occurred, and that it has not been altered since — verifiable independently by anyone. The design goal is to collapse verifiability into one call. Today, if you want to be able to prove later that a specific thing happened — an AI agent made a particular decision, a payment intent was authorized, a dataset was exported, a policy was changed — your options are mostly logs, and logs are records you have to trust the keeper of. The attestation API offers a different primitive. At the moment an action matters, you attest it: one request in, and back comes a signed attestation, a receipt that binds a precise claim about the action to a cryptographic signature so that any later tampering is detectable. Because the signature uses post-quantum, NIST-standardized algorithms, the receipt stays verifiable over time rather than resting on cryptography a future quantum computer is expected to break. And because verification means checking a signature against public material, anyone who needs to — an auditor, a counterparty, a regulator — can confirm the receipt independently, without calling RankShield and taking its word. That last property is the point: the attestation API is built so the proof stands on its own cryptography, not on trusting the issuer. It makes producing durable, checkable evidence as easy as producing a log line, which is what lets verifiability become a default rather than a special project. The primitive is deliberately general, because the need is horizontal — the same call that seals an agent's action seals a financial intent or a compliance event — and it's the same receipt-first foundation the rest of the RankShield platform is built on.
How is an attestation different from just writing to a log?
Because a log is a record you must trust someone to have kept honestly, while an attestation is a record anyone can verify without trusting the keeper — and that difference is decisive exactly when records matter most. Ordinary logging is essential for operations, and attestation doesn't replace it; you still log to understand and debug your systems. But logs have a structural weakness as evidence: whoever controls the log store can alter, reorder, or delete entries, and after the fact there is generally no way to prove the log wasn't changed. That's tolerable for routine observability and intolerable for the moments that end up disputed — a contested payment, a questioned agent action, an insider who edits the record to cover a mistake, a regulator asking you to prove what happened rather than assert it. In all of those, "here is what our logs say" is only as strong as the assumption that no one touched the logs, and that assumption is precisely what an adversary or a dispute attacks. An attestation removes the assumption. It is cryptographically signed and tamper-evident, so any alteration breaks the signature and becomes detectable by anyone who checks — the integrity of the record no longer depends on trusting its custodian. Just as important is what an attestation honestly does and doesn't claim. It proves integrity and provenance: that this exact statement about an action existed at that time and hasn't been changed. It does not claim the underlying action was correct, wise, or compliant — those are matters of judgment and policy that no signature can settle. RankShield is deliberate about that boundary, because an honest, well-scoped proof is far more useful than an overclaimed one: you get durable, checkable evidence of what happened, which is exactly what supports audits, disputes, and accountability, without pretending the cryptography certifies the decision behind the action. In short, use logs to run your systems and attestations to prove the actions that have to hold up later. For the broader philosophy, see verifiable AI security.
Why does "verify without trusting the vendor" matter, and what can you attest?
Because evidence that only its issuer can vouch for isn't independent evidence — and the attestation API is built so proofs stand on their own cryptography, verifiable by any party, across essentially any action worth proving. Start with the trust property, because it's the one most easily lost and most valuable to keep. Many "audit" and "trust" products produce records that you can only really check by asking the vendor's system to confirm them — which means the moment you stop using the vendor, or the moment the vendor itself is the thing in question, the evidence evaporates. RankShield treats that as a design flaw to avoid. Its attestations are verified by checking a signature against public verification material, an operation anyone can perform independently, that does not require calling RankShield, and that keeps working even if you later leave the platform. This is the "verifier is not the vendor" principle: the proof is useful to auditors, counterparties, and regulators precisely because they don't have to trust RankShield to accept it — they can check the math themselves. That independence is what makes an attestation count as evidence rather than a vendor's assurance. On the second question — what you can attest — the answer is intentionally broad, because verifiability is a horizontal need rather than a feature of one domain. You can attest an AI agent's decision or tool call, a payment or settlement intent, a data access or export, a configuration or policy change, a model output, or any compliance-relevant event. The same primitive serves all of them because they share the same requirement: a durable, checkable record of what happened that survives scrutiny later. That generality is also why the attestation API sits beneath the rest of the platform. It's the layer that pairs with agent passports — passports establish who an agent is, the attestation API records what it did — and it's the mechanism behind the receipts you can check on the verify page. Practically, it's designed to drop into systems you already run: a call you make at the moment an action matters, returning a receipt you can hand to whoever needs to be convinced, now or years from now. Because the receipts are quantum-safe-signed and re-sealable as standards advance — quantum-safe, never "quantum-proof" — that later moment is exactly the one they're built to survive. Explore more on the platform overview.
Where does the attestation API fit in a system you already run?
It fits at the exact moments that have to hold up later — a call you add where an action matters, not a platform you migrate onto — which is what lets verifiability become a habit rather than a rewrite. The design intent is minimal friction: you keep your existing services, databases, queues, and logging, and at the specific points where an action needs to be provable, you make one additional call to attest it and store the receipt alongside whatever you already keep. Think of it the way you think about instrumentation. You don't rebuild an application to add a log line; you add it at the point of interest. Attestation works the same way, except the output is evidence you can hand to a third party instead of a record only you can read. That placement is a judgment call worth making deliberately, because attesting everything is wasteful and attesting nothing leaves you back at unprovable logs. The actions worth a receipt are the ones that get disputed, audited, or questioned: an agent's consequential decision or tool call, a payment or settlement intent before it executes, a data export that could later raise a compliance question, a configuration or policy change to a sensitive system, a model output that a decision was based on. For each, the pattern is the same — capture the claim about what happened, attest it, and retain the receipt — and the payoff arrives whenever someone later asks you to prove rather than assert. Because the primitive is general and the receipts verify independently, the same integration serves audit, dispute resolution, regulatory response, and inter-company trust without bespoke work for each. And because attestation pairs with agent passports for identity and with the platform's governance layer for enforcement, adding it is also how you extend a receipt-first discipline across the autonomy you already operate. The receipts are quantum-safe-signed and re-sealable as standards evolve — quantum-safe, never "quantum-proof" — so the evidence you produce today is built to still verify when the question finally comes. See the platform overview for how the layers connect.
Ask RankShield about the attestation API.
What is the RankShield attestation API?
It is a simple interface that turns any action into verifiable proof. You send the API a description of an action — an agent decision, a payment intent, a data access, a configuration change — and it returns a tamper-evident attestation: a signed receipt that records what happened, when, and that it has not been altered since. The signing uses post-quantum, NIST-standardized algorithms, and the receipt can be verified independently by anyone, without trusting RankShield to vouch for it after the fact. The idea is to make "produce evidence" a single call, so that verifiability becomes something you add to an action as easily as you would log it — one action in, one checkable receipt out.
What does an attestation actually contain and prove?
An attestation records a specific claim about an action — what was done, by which identity, at what time, over what data — and binds it with a cryptographic signature so the record is tamper-evident. What it proves is integrity and provenance: that this exact statement about the action existed at that time and has not been changed since. It is careful about what it does not claim. An attestation proves that a claim was made and sealed, not that the underlying action was wise, correct, or compliant — those remain matters of judgment and policy. Used well, that scoping is a strength: you get durable, checkable evidence of what happened, which is exactly what supports audits, disputes, and accountability, without overstating it into a guarantee the cryptography can’t make.
How is this different from ordinary logging?
A log is a record you have to trust the keeper of. Anyone with access to the log store can alter or delete entries, and after the fact you cannot prove the log wasn’t changed — which is precisely the weakness that matters when a record is disputed or an insider is involved. An attestation is a record you can verify without trusting the keeper: it is cryptographically signed and tamper-evident, so altering it breaks the signature and the change is detectable by anyone who checks. Attestations complement logging rather than replacing it — you still log for operations — but for the actions that must be provable later, an attestation turns "here is what our records say" into "here is verifiable proof, check it yourself."
Can attestations be verified without trusting RankShield?
Yes — that is the point of the design. Verification is checking a signature against public verification material, which anyone can do independently; it does not require calling RankShield and taking its word, and it keeps working even if you later stop using the platform. This "verifier is not the vendor" property is deliberate, because evidence that only its issuer can vouch for isn’t really independent evidence. RankShield builds attestations so the proof stands on its own cryptography, verifiable by any party who needs to check it, which is what makes them useful for audits, counterparties, and regulators who reasonably won’t just trust a vendor’s dashboard.
Are the receipts quantum-safe and durable?
Yes. Attestations are signed with post-quantum, NIST-standardized signature algorithms so they remain verifiable over time rather than resting on cryptography a future quantum computer is expected to break, and they are built to be re-sealed as standards advance. RankShield describes this as quantum-safe, not "quantum-proof" — the strongest standardized protection, kept upgradeable, not a promise of permanent immunity. Durability matters because the value of a receipt is often realized long after it is issued, when a question about what happened finally arises, so it needs to still verify years later.
What can I attest with the API?
Essentially any action you need to be able to prove: an AI agent’s decision or tool call, a payment or settlement intent, a data access or export, a configuration or policy change, a model output, a compliance-relevant event. The API is intentionally general because verifiability is a horizontal need — the same primitive that seals an agent’s action also seals a financial intent or an audit event. It is the layer beneath RankShield’s agent passports and governance: passports establish who an agent is, and the attestation API records what it did as evidence. It is designed to drop into existing systems as a call you make at the moment an action matters, rather than a platform you have to migrate onto.
Make every action provable.
One call in, one tamper-evident receipt out — quantum-safe-signed and verifiable by anyone, forever.