Everything people ask, answered directly

Veristria builds verification infrastructure for software that ships fast. It is the parent company of three products — KeyDrift, VibeGuard and FeeGuard — each of which checks what an application actually deployed rather than what its source code intended. The company was founded in 2026 by Lars O. Horpestad and is based in Norway.

It means checking the deployed result rather than the plan. Traditional tooling reads your source: the repository, the migrations, the config. Veristria reads the artefact — the JavaScript your CDN is serving right now, the row-level security policies your database is currently enforcing, the transfers your payment platform actually made. Those two things diverge constantly, and every failure the products find lives in the gap between them.

They read your source; Veristria reads what shipped. The difference is not philosophical — it decides what you can find. A build-time environment variable is a variable name in your code and a literal secret in your bundle, so a repository scan of a clean repository returns nothing while the key is served to every visitor. Static analysis and deployed-artefact verification catch different classes of failure. Teams that need both should run both.

No. Where a product handles credential material it keeps a masked prefix and a fingerprint — enough to identify a key and track it across scans, never enough to use one. A scanner that retains the secrets it discovers has become the exposure it was hired to find.

As little as possible, and two of the three need none to begin. KeyDrift reads assets already served publicly to any browser. VibeGuard runs its free audit read-only, against what a project already exposes, with no database writes. FeeGuard needs a Stripe restricted key scoped to the reads it requires, with write scopes gating automatic recovery alone and remaining optional.

The first real answer is free on all three products, and no account is required for the public scans. That is a deliberate rule rather than a trial: you should not have to take our word for it that something is wrong. Payment begins when you turn on continuous monitoring — the part that keeps watching after the first scan.

No. Veristria is independent and is not affiliated with, endorsed by or sponsored by any platform its products examine. Those names appear descriptively, to identify the systems the products work with.

Veristria was founded by Lars O. Horpestad, a Nordic AI figure and the author of the first published Norwegian guide to large language models. He is based in Norway and leads all three products.

Vibe coding is safe to the extent that somebody verifies the result, and the honest answer is that most teams do not. The code an AI assistant produces usually works, which is exactly what makes it hard to review — there is no failing test to prompt a second look. The failures that follow are concentrated in a few predictable places: credentials that end up in the browser, database access rules that were never written, and money movement that nobody reconciled. None of those raises an error. All of them are checkable in minutes if you look at the deployed application rather than the source.

Yes, and the characteristic ones are configuration failures rather than exotic exploits. An assistant asked to make a feature work will reach for whatever makes it work, which is frequently the elevated credential or the permissive policy. The result compiles, passes tests and ships. The three most common in practice are a secret key inlined into the client bundle, a database table left readable because row-level security was never enabled, and a refund path that moves money one way but not the other.

Start with the deployed application, not the repository, and check three things in order. First, open your production JavaScript and search it for credential formats — a JWT prefix, sk_live_, sk-proj-, AKIA. Second, if you use a browser-reachable database such as Supabase, confirm row-level security is enabled on every table and that no policy evaluates to true unconditionally. Third, if you move money on behalf of other accounts, reconcile a sample of refunds against their transfers. Each of those takes minutes by hand, and each is what one Veristria product automates and then keeps watching.

It covers a different surface. CI secret scanners read commits and working trees, and they are good at what they do — but the most common leak in modern frontends never touches either. Build-time environment variables are substituted into the bundle during the build, on a runner, after the scan has passed. The repository stays clean, the scanner stays green, and the key ships. Checking the built output is a separate step that most pipelines simply do not perform.

If you ship a JavaScript frontend and want to know whether API keys are exposed in your client bundle, use KeyDrift. If you build on Supabase and want to know whether row-level security still covers your schema, use VibeGuard. If you run a Stripe Connect platform and want to know whether refunds, disputes or FX are silently costing you money, use FeeGuard. They are independent products with separate pricing; most teams need one.

Because the elevated key is the one that makes the feature work, and a prefix makes it reachable from the browser. When a query returns nothing under a restricted key, the shortest path to working code is the service_role or secret key — and to use it client-side it needs a NEXT_PUBLIC_ or VITE_ prefix. Those prefixes are build instructions, not security settings: they mean "inline this literal value into the bundle". The generated diff contains only a variable name, so nothing looks wrong in review. This is the failure KeyDrift exists to catch.

Because the dashboard reports configuration and the anon key exercises behaviour, and three things routinely separate them. Row-level security can be enabled on the table but with a policy that evaluates to true unconditionally, which is decoration rather than protection. A new table can ship without RLS enabled at all. Or a policy correct for the old schema can stop covering a column or join path added later. VibeGuard tests the live project as a caller rather than reading the configuration, and reports the exact query that returns a row it should not.

Almost certainly because the transfer to the connected account was never reversed. A Connect charge is three separate movements — the charge, the application fee and the transfer — with independent lifecycles. Refunding the charge returns the customer their money from your balance and touches nothing else, because reverse_transfer defaults to false. The customer is made whole, the connected account keeps its payout, and the platform absorbs the difference. Nothing errors and nothing is logged; the balance is simply smaller. FeeGuard reconciles those objects against each other and flags the gap while it is still recoverable.