A verifiable trust layer for AI gateways

Every AI request.
Evidence you can verify.

TrustedAIProxy observes real traffic between gateways and model providers, binds it to verified upstream TLS, and signs it with an Ed25519 key inside Google Confidential Space.

Explore verification View on GitHub

No MITM CA installation or internal proxy connection for end users

Attestation verified

Just now

✓

Proof chain verified trusted-ai-proxy-v1

Runtime: Confidential Space
Algorithm: Ed25519
Upstream domain: api.openai.com
Signed scope: Request + response text

proof_ref proof-J4vLQ0p…cY9Q

01Google Confidential SpaceWorkload attestation

02Ed25519Content signatures

03RFC 8785 · JCSDeterministic payloads

04Verified upstream TLSUpstream identity binding

WHY TRUSTED AI PROXY

Trust should come with evidence

HTTPS proves that a user connected to the gateway. It cannot tell them what happened beyond it.

A conventional gateway

User request?Model provider

Only the platform's word to rely on

Was the model replaced?
Were prompts added or removed?
Was the response rewritten?

With TrustedAIProxy

Real traffic✓Cryptographic proof

Give users a way to verify

Attest to the upstream domain and TLS certificate
Attest to the actual model, path, and message order
Verify an approved confidential computing workload

HOW IT WORKS

Evidence generated on the traffic path

TAP sits at the gateway's egress and verifies the model provider's TLS connection. It signs only complete protocol semantics that can be parsed deterministically.

End userStandard HTTPS request

Request

AI gatewayNew API / One API

Internal proxy

CONFIDENTIAL SPACE

TrustedAIProxyObserve · Normalize · Sign

Verified TLS

Model providerOpenAI / Anthropic / Bedrock

Observe the interaction

The gateway routes upstream traffic through TAP using an HTTP(S) proxy. Outbound TLS still verifies hostnames and certificate chains.

Extract protocol semantics

Provider protocols are normalized into a stable model and ordered messages. Ambiguous, oversized, or unsupported content remains unsigned.

Build a deterministic payload

Canonicalize the upstream certificate fingerprint, domain, path, and messages with RFC 8785 JCS to create reproducible claims.

Attach the attestation

The workload key produces an Ed25519 signature and proof_ref. Attestations return in headers; the API response body stays unchanged.

VERIFY, DON’T ASSUME

From workload proof to response verification

The trust chain has two layers. Cache workload proofs for the public key or workload lifecycle; verify each API response and check for replay.

llm-conversation-text-v1 Covers plain-text request and response messages

1
Start with the response
Read the proof reference
Extract X-Attestation-Proof-Ref from the API response; fetch a proof bundle if there is no valid local cache entry.
2
Customer-initiated
Get a workload proof with a one-time challenge
Call /.well-known/confidential-attestation with a unique, customer-generated challenge each time.
3
Google trust root
Verify the OIDC token and workload policy
Check the signature, issuer, audience, validity, image digest, project, instance, service account, hardware, and Secure Boot.
4
Key binding
Bind the Ed25519 key to the workload
Recompute the public key binding nonce and confirm that the Google token's eat_nonce binds both the challenge and the public key.
5
Every response
Rebuild claims and verify the signature
Normalize the request and response for the profile, apply JCS, verify Ed25519, enforce route/model policies, and check the nonce for replay.

EVIDENCE, NOT LOGS

Know exactly which facts are signed

Verifiers reconstruct the same signed payload from the public protocol, so the evidence can be checked independently.

Read the full verification guide →

canonical-claims.json

{
  "version": "trusted-ai-proxy-v1",
  "profile": "llm-conversation-text-v1",
  "tls_certificate_sha256": "8f9a…d21e",
  "domain": "api.openai.com",
  "request_path": "/v1/chat/completions",
  "request_fields": ["model", "messages"],
  "response_fields": ["messages"],
  "timestamp": 1787749200,
  "nonce": "R6I8…F0qw"
}

✓ RFC 8785 canonicalized Ed25519 valid

CLEAR TRUST BOUNDARY

Clear boundaries are part of trust

A signature proves only what its profile explicitly covers. Unsigned fields cannot be inferred from the proof.

✓

NON-STREAMING

What it can prove

Upstream identityDomain and HTTPS leaf certificate fingerprint
Request detailsRequest path and actual model
Text integrityRoles, order, message boundaries, and text
Signature originAn approved Confidential Space workload

—

OUT OF PROFILE

What it cannot prove

Multimodal contentImages, files, audio, and tool calls
Model internalsReasoning and the provider's generation process
Business behaviorGateway billing, availability, and uncovered fields
Streaming response bodyThe streaming profile covers only the request and upstream metadata

About streaming responses

llm-request-upstream-v1 attests to the request reaching the specified upstream and its response metadata. It does not cover any SSE event or streaming body. Clients must label streaming content as unverified.

PROTOCOL COVERAGE

One trust layer for major model APIs

Versioned extractors handle provider message formats and normalize them into public, reproducible signature semantics.

APIExtractorStatus

OpenAI Chat Completionsopenai-chat-conversation-v1Supported

OpenAI Responsesopenai-responses-conversation-v1Supported

Anthropic Messagesanthropic-messages-conversation-v1Supported

AWS Bedrock Invokebedrock-invoke-conversation-v1Supported

AWS Bedrock Conversebedrock-converse-conversation-v1Supported

START WITH EVIDENCE

Make trust something your users can verify

Explore the signing flow locally, deploy to Google Confidential Space, and give customers the policies they need to verify it.

Google Cloud deployment Read the user guide

Every AI request.Evidence you can verify.