Wrapping your client with Sentinel
A practical walkthrough for engineers adding cryptographic audit to an existing gpt integration.
Nothing in your codebase changes
Most audit tools ask you to refactor. New abstractions, new call patterns, new things to maintain. Sentinel doesn't. The entire integration is one function that wraps your existing client. Your call signatures stay identical. Your response objects stay identical.
What you get on each response
Each response now carries a sentinel.seal field — a short hash you can store, share with a compliance team, or ignore entirely if you don't need it yet. The dashboard populates automatically. Within 30 seconds of your first wrapped call, you'll see model version, token counts, latency, region, and the full seal hash.
Zero overhead in your application
Sentinel runs at the edge node closest to the model's datacenter — not inside your application process. There is no cpu overhead in your lambda, container, or server. Your users never see the latency. The sealing happens entirely outside your boundary.
Bundle size
The sdk itself is 4.2kb gzipped. It adds zero transitive dependencies. It works in node, deno, bun, and browser environments. Most teams are in production within the same session they started the integration.
Jane Ley
Faq
Everything you need to know, answered.
Latency, data exposure, compliance, cost. self-hosting. We answer the hard ones here without the marketing language. If something is missing, the spec is public.
01
Does sentinel add latency to my llm calls?
02
Does sentinel see my prompts or responses?
03
What happens if sentinel goes down?
04
Is this compliant with hipaa, soc 2, and gdpr?
05
How is this different from just logging my llm calls?
06
What does a seal actually contain?
The proof layer your
stack is missing
Sentinel seals every prompt, every response, every inference. Ship AI with the same confidence you ship code.
