RTK-1 runs an adversarial campaign against an AI system before deployment and produces a single cryptographically signed artifact. That artifact records exactly what was tested, exactly what was not, and a binary verdict bounded strictly to the tested surface.
It is signed with ECDSA P-256 over the SHA-256 of its RFC 8785 canonical bytes, and it verifies against a published key with no cooperation from RTK Security Labs required. The verification procedure is public. Trust sits in the math, not in us.
RTK-1 is the evidence-production layer of an AI safety case — the component that generates pre-deployment adversarial evidence under the Claims–Arguments–Evidence structure. It does not enforce anything at runtime, and it makes no claim about behavior after deployment. What it does, it does so that a hostile reviewer can confirm every assertion without taking our word.
Here is the coverage statement from a real signed artifact, reproduced verbatim. Notice that the second half is as important as the first — the artifact volunteers its own limits.
The verdict describes what was observed under defined adversarial pressure across a defined surface at a defined moment. It does not claim that no execution path could ever exist — only that none was observed within what was tested. That distinction is the difference between evidence and overstatement.
Across the declared coverage surface, at the time of testing, no unauthorized execution path was triggered under the adversarial pressure applied. Bounded strictly to what was tested.
The stronger observation, where applicable — no unauthorized path surfaced even under sustained pressure across the tested vectors. Still bounded to the declared surface; still empirical.
A procurement reviewer, an auditor, opposing counsel, or a peer can verify a signed RTK-1 artifact with only public libraries and our published key. The verifier imports nothing from RTK-1's code and contacts nothing beyond the published key URL.
pip install rfc8785 cryptography — both are standard public libraries.
python verify_rtk1.py evidence.json — it recomputes the canonical hash and checks the ECDSA P-256 signature.
It pulls the public key directly from the published URL — no key handed to you by us, no infrastructure trust required.
Hash integrity (the body is unaltered) and signature validity (signed by the RTK-1 key). Either failure returns NOT VERIFIED.
RTK-1's validated capability is the adversarial path that has been confirmed by running it against known truth and watching every claim hold. Other attack providers and the multi-agent composition work exist in development and are being validated one at a time. We will not present a capability as live until a signed artifact can stand behind it. This is a deliberate constraint, not a limitation we are hiding.
Each item in development becomes "validated today" only after it has been run against known truth and a signed artifact can be independently verified for it. Breadth is earned one provider at a time.
"An artifact that states what it proves, what it does not prove, where it sits, and what it must connect to — and that any party can verify without trusting the party that produced it."
A claim that cannot be checked is an assertion, not evidence. A claim that overstates its reach collapses the moment a reviewer finds the seam. RTK-1 is built so that neither failure mode is available to it: every artifact is bounded to what was observed, and every artifact is independently verifiable.
Pricing for direct engagements is fixed. An engagement produces a signed, coverage-bounded evidence artifact scoped to your deployment. Retainer and channel-specific arrangements are handled separately, not listed here.