NautsAI software & research
Back to NautGate

NautGate / Guide 3 of 3 / 4 min read

Beneath the bonnet: architecture, receipts and signatures

Follow a request through the gateway, then see how its recorded evidence can be signed and checked independently.

The reason

I wanted to know what my LLM was actually doing.

The same model could feel different from one week to the next. I wanted a record I could inspect instead of guessing what had changed.

NautGate grew from that monitoring tool into a gateway for connected applications and agents. It records their usage, controls model routes and can produce signed evidence for later inspection.

48Nauts / Product guides

How the gateway fits together

Request and response

Application or agent

Supported OpenAI and Anthropic request formats

↔

NautGate

Protocol adapters
Route rules and model selection
Provider connections

↔

Model provider

Configured cloud provider or local model

Captured routing decisions, usage and response metadata

Decision ledger and request records

Requested, selected and provider-reported models. Content capture follows the recording policy.

Dashboard

Review activity, routes and costs

Evidence receipts

Canonical receipt hashes → Merkle root → checkpoint

Optional signing · from the receipt checkpoint

Signing extension

Submits the checkpoint to the signing service

Signing service + TSB

Requests an authorised signing operation through the REST API

↔
Securosys hardware

HSM

Private signing key stays inside

Returned signature + checkpoint + receipt inclusion proof

Exported evidence → independent verifier

Checks hashes, inclusion and signature using a separately trusted public key. No HSM access required.

Only connected traffic is recorded. Signing is optional and verifies record integrity, not the truth of a model response.

NautGate sits between a connected application and its model providers. Its protocol adapters accept supported OpenAI Chat Completions, OpenAI Responses and Anthropic Messages requests. These entry points feed a shared routing and evidence pipeline rather than separate logs for each client format.

The routing layer turns the requested model, configured preferences and routing rules into a provider and model selection. It considers route health and the configured restrictions before forwarding the request. Explicit model selection and automatic routing use the same gateway, but do not make the same selection decision.

The provider connection sends the request upstream and returns the response, including streamed responses where supported. NautGate distinguishes the model requested by the application, the model selected by the router and the model reported by the provider. Keeping those separate makes a substitution visible instead of hiding it behind one model name.

The decision ledger and request records support investigation in the dashboard. The evidence path builds receipts and checkpoints from captured records. Optional signing adds a separate service and HSM connection; the HSM does not choose the model or generate its answer.

Where the boundaries sit

The application must actually send its requests through NautGate for this visibility to exist. Pointing a compatible client at the gateway connects that workflow; calls sent directly to a provider remain outside its record.

Provider credentials, route permissions and recording policy are configuration decisions. A local model route keeps model execution local only when its configuration and fallback rules enforce that boundary. Prompt and response retention also need an explicit policy, independently of where the model runs.

The signing service is another trust boundary. Restrict who can request a signature and which key they may use. A protected key helps preserve the integrity of captured evidence, but cannot repair missing or incorrect records at the gateway.

A canonical receipt

Verification starts with an agreed representation of the receipt. A verifier needs to hash the same bytes as the signer, rather than an arbitrary reformatting of the record.

Receipt hashes are combined into a Merkle tree. Its root summarises the batch, while an inclusion proof connects one disclosed receipt to that root.

What Securosys adds

Securosys provides the hardware security module used by this signing integration. An HSM is dedicated hardware that protects cryptographic keys and performs operations such as signing. In this setup, the private signing key stays inside the HSM; NautGate receives a signature, not the key.

TSB stands for Transaction Security Broker. It gives the signing service a REST API through which to request an operation on an HSM key. NautGate prepares a checkpoint, its signing extension passes it to the signing service, and that service calls TSB. The returned signature accompanies the checkpoint for later verification.

This separates the protected signing key from the gateway's ordinary application files. Using it requires a configured HSM or HSM service, TSB access and authorisation to use the chosen key. The integration is optional, and those services are not automatically supplied by installing NautGate.

Signing the checkpoint

The signing extension passes the checkpoint to the signing service, which calls Securosys TSB. The illustrated integration uses POST /v1/synchronousSign with SHA256_WITH_RSA. The private key remains inside the HSM.

Signing is optional. Routing, logging and the dashboard operate without it; a signed checkpoint adds an independently checkable reference to the evidence path.

  1. 01Receipt hash
  2. 02Merkle root
  3. 03HSM signature

An independent verifier

A verifier recalculates the disclosed receipt hash, checks its inclusion in the checkpoint and verifies the signature with a separately trusted public key. That check can run offline.

The trust in the public key matters. Accepting any key bundled with a receipt would let an attacker substitute the data and key together. A valid signature establishes record integrity relative to that key, not input truth, complete capture or a trusted timestamp.