My app is a thin wrapper over Claude. What is there to even audit?
Asked by makers — answered by AXIS. This question comes up repeatedly in listing intake and onboarding conversations; we have reworded it so no individual maker is identifiable.
The question: "My product is honestly a focused UI over a model API — prompt templates, some retrieval, billing. An audit feels like overkill for 4,000 lines of glue code. What would an auditor even find?"
The answer. The wrapper framing hides where your risk actually lives. "Thin" describes your code volume, not your attack surface — and in wrapper-architecture apps, the surface is mostly in the connections, which is exactly what 4,000 lines of glue is made of. What audits of apps like yours actually find:
1. Your API key is the crown jewel, and it's closer to users than you think. Wrapper economics mean your margin is your key hygiene. Findings that recur: keys reachable from client code or build artifacts; generation endpoints without rate limits (anonymous users spending your compute budget); no per-user metering, so one abuser is invisible until the invoice.
2. Retrieval is an injection channel. If your app fetches documents, emails, or web content into context, every one of those sources is untrusted input to a model that presumably has your system prompt — and possibly tools — in scope. Public demonstrations have repeatedly shown a document's hidden text steering an assistant into leaking what it knows. "Some retrieval" is quietly the most auditable sentence in your question.
3. The glue makes authorization mistakes. Whose documents can a crafted request retrieve into whose context? Multi-tenant retrieval bugs — user A's data surfacing in user B's session — are the wrapper-app equivalent of the classic object-access flaw, with the extra twist that the leak arrives inside model output, where nobody's grepping for it.
4. Billing-logic drift. Your subscription state, usage caps, and the model calls they're supposed to gate are three systems the AI helped you wire together. Auditors keep finding paths where expired or free-tier users still reach paid model calls.
5. The boring perimeter. Auth, sessions, webhook signature checks, dependency versions — wrapper apps have the whole standard web surface too.
Scope an audit like yours honestly and it's small — days, not weeks — precisely because the app is thin. The findings-per-day rate, though, tends to be the opposite of thin. Cheap engagement, dense results is the normal outcome for your architecture.
What's your retrieval doing — what sources reach the context window? Answer that here and we'll tell you what an auditor would poke first.
Replies (4)
Follow-up from maker intake: "The rate-limit point hit home. What does 'right' look like for a generation endpoint?"
Layers, cheapest first: (1) authentication before generation — anonymous access to model calls is a donation program; (2) per-user quotas metered in tokens or cost, not just request counts (one request can be expensive); (3) burst limits per IP and per account to slow scripted abuse; (4) a global spend circuit-breaker with alerting — the 'wake me before the invoice does' layer; (5) provider-side budget caps as the final backstop. Most wrapper apps have layer 5 only, discovered the month it mattered.
Follow-up from maker intake: "Is my system prompt itself worth protecting? Competitors could clone my product from it."
Assume it leaks and design accordingly — extraction techniques evolve faster than defenses, and a motivated user will eventually read yours. Two consequences: first, nothing secret goes in it — no keys, no internal URLs, no customer names (audit finding with its own line item in the pinned scope thread); second, if the prompt is your only moat, the moat is the problem, not the leak — durable wrapper advantages live in your data, integrations, distribution, and accumulated user context. Prompt secrecy is hygiene, not strategy.
Platform angle on the 'overkill' instinct: wrapper apps are the majority of what gets listed here, and they're also what acquirers are most cautious about — the diligence question is always 'what breaks when the model provider changes terms, prices, or behavior?' An audit report that maps exactly what the app depends on, where keys and data flow, and what's rate-limited is also the artifact that answers the buyer's dependency question. You're not buying paranoia; you're pre-writing the technical half of your own data room.
Follow-up from maker intake: "Practical scoping: for a genuinely small wrapper (one model, no retrieval, Stripe billing), what's the minimum credible engagement?"
With no retrieval you've deleted the nastiest surface, so: a 1-2 day source-assisted review covering key handling and metering, authorization on every route, billing-gate logic, webhook verification, dependency posture, and output rendering (model text into your UI — escaping still matters). Expect a short report; a competent auditor will say so rather than pad it. Below that floor, self-serve options exist — dependency scanners, the OWASP LLM checklist as a reading list — but they check boxes, not judgment. The judgment is what you're paying the 1-2 days for.
Threads are permanent — locked, not deleted, once resolved. New posts go through a submission form and are published by moderators, usually within 1 business day.