Lovable's changelog entry for 2026-08-07 says: "Every app you publish publicly now gets a Trust Center: a security page that Lovable generates at /.well-known/trust.html on your app's domain." Ten days later, on 2026-08-17, another entry turned it off: "Your app's Trust center is now disabled by default... Trust pages that were live before are offline until you enable the setting."
The launch got written up as an enterprise-sales feature. What nobody seems to have done is fetch one and read it. So we did, including the example app Lovable links from its own launch post.
TL;DR
The trust page lists only the checks your app passes, and Lovable publishes the complete catalogue of possible checks. That combination makes it a diffable allowlist: subtract your page from the catalogue and you have a list of things you don't claim. Lovable is upfront that an omission is ambiguous, and for most checks it genuinely is. For the probed response-header checks it mostly isn't, and we confirmed that against Lovable's own demo app.
What is actually published
Two files on your app's own domain: a human-readable page at /.well-known/trust.html and a machine-readable claims file at /.well-known/trust.json. The docs describe about twenty checks in four groups.
Connection and browser security is ten checks: HTTPS redirection, HSTS, certificate validity, X-Content-Type-Options, framing protection, Content Security Policy, Permissions-Policy, Referrer-Policy, cookie flags, and mixed content on the first page checked. Deployment and runtime is six, covering dependency scanning, SBOM creation and freshness, deployment provenance, and health checks. Two more apply only to Lovable Cloud apps: a database access review, and row-level security on every checked table. Two more appear only if you've enabled the tooling: automatic security fixes, and synced Aikido results.
The page is generated from your live deployment, not from a questionnaire. That's a better design than most vendor trust pages, and worth saying before the rest of this post.
The sentence that makes it a diff
From the docs, in the section on the machine-readable file:
Only checks that currently pass are included.
And in the Limitations section, covering both surfaces:
The page and
trust.jsonshow the checks that pass right now.
There's no status field. We pulled the JSON for Lovable's example app and every entry in claims.controls[] has exactly these keys: id, assurance_class, subject_type, evaluated_at, expires_at. No pass, no fail, no pending. Presence is the pass.
Now pair that with the fact that Lovable publishes the full catalogue, and tells builders to compare: "To see which checks your app shows, open your own trust page and compare it against this list." That's a reasonable instruction for a builder. It's the same operation anyone else can run.
Lovable saw the obvious inference coming
To their credit, the docs get ahead of it, in writing, more than once:
If a check is omitted, Lovable makes no claim about its state. An omitted check is not an alert that something is wrong.
And, most directly:
A reviewer can't tell from the Trust center alone whether an omitted check failed or was never evaluated.
That's an honest limitation, published by the vendor, and it's correct for a good chunk of the catalogue. A check can be missing because you don't use Lovable Cloud, because you never connected Aikido, because automatic fixes are off, because your app predates the feature and needs a republish, or because Lovable couldn't identify your dependencies. Whole sections vanish when nothing in them is confirmed.
So "absence proves failure" is wrong, and if you read that somewhere, it's worth correcting.
There's one place the ambiguity really does bite, and it's the scary one. The Lovable Cloud database checks cover row-level security. An app that doesn't use Lovable Cloud shows no database checks at all. Reading that gap as "RLS is off" would be flatly wrong, and RLS-off is the failure mode most associated with leaked Lovable apps. Don't make that jump about someone else's app, and don't panic about your own.
Where the ambiguity gets thin
Then there's the header family. HSTS, CSP, X-Frame-Options, Referrer-Policy, X-Content-Type-Options, Permissions-Policy. These apply to any app served over HTTPS. There's no plan tier that exempts them and no configuration in which they're inapplicable. A response either carries the header or it doesn't.
For that group, "passing" and "no claim made" narrow down to almost the same thing. So we tested it rather than arguing about it.
The example app Lovable links from its own launch post publishes ten controls. Present: hsts, referrer_policy, content_type_options, plus TLS, redirect, mixed content, SBOM and provenance entries. Absent: CSP, framing protection, Permissions-Policy.
Then we asked the app directly, with no reference to the trust page:
strict-transport-security: max-age=31536000; includeSubDomains
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
Three headers present in the response, the same three present on the trust page. Three headers absent from the response (content-security-policy, x-frame-options, permissions-policy), the same three absent from the trust page. The diff was exact in both directions.
None of that is a vulnerability, and a demo app missing a CSP is not a scandal. The point is narrower: for this family of checks, the omissions were readable, and anyone holding the published catalogue could have worked out those three without ever fetching the site.
Where even this breaks down, because it's worth being precise. cookie_security is also missing from that page, and yet the app does set a cookie with HttpOnly, Secure and SameSite. An app that sets no cookies at all would look identical. So the header family is readable in general and still has exceptions. Treat a diff as a lead, not a verdict.
"Excluded from search engines" covers less than it sounds like
The docs say the trust page "is as public as your published app," that it's "excluded from search engines," and that it's "meant to be shared by link, not discovered by search."
The first is exactly right. The other two describe indexing, and it's worth knowing precisely what's behind them. On the live example:
trust.htmlcarries<meta name="robots" content="noindex">. That's the whole mechanism.trust.jsoncarries noX-Robots-Tagheader. Being JSON, it can't carry a meta tag either. There's no exclusion on it at all, and it's the file designed for automated consumption.robots.txtisUser-agent: */Allow: /. It doesn't disallow/.well-known/.- Both files return HTTP 200 to an anonymous request, with no authentication and no redirect.
A noindex asks compliant search crawlers not to list a page. It doesn't stop fetching, archiving, scraping, or anything enumerating well-known paths across a range of hostnames. /.well-known/ is a registered prefix that exists specifically so clients can find things without being told where to look. We wrote up the same pattern for AI config files after the SANS Internet Storm Center found .cursor/mcp.json already sitting in commodity scanner wordlists. Nobody needed your link.
One more detail from the file itself: "verification": {"platform_generated": true, "signed": false}. The document is unsigned. Its integrity rests on being served from your origin, so a copy of it proves nothing anywhere else.
Read yours the way a stranger would
curl -s https://your-app.lovable.app/.well-known/trust.json | jq '.claims.controls[].id'
A 404 means your Trust Center is off, which has been the default since 2026-08-17. The next command still applies either way, and it's the one that matters.
curl -sI https://your-app.lovable.app | grep -iE \
'strict-transport-security|content-security-policy|x-frame-options|x-content-type-options|referrer-policy|permissions-policy'
Whatever doesn't come back is a header you aren't sending, regardless of what any trust page claims.
Check the headers first, then decide about the trust page. Doing it the other way round makes the report the goal, and the report was never the point. A page listing twenty passing checks is worth publishing. One listing nine is worth fixing first.
So should you turn it on?
If your app passes the checks, publishing it is a small genuine credibility win, and it beats a PDF questionnaire nobody updates.
If it doesn't, switching the page off doesn't protect you. Your headers are readable by anyone with curl either way. Hiding the summary changes who has a convenient copy, not who can find out.
Two bits of housekeeping while you're in there. If you shared a trust page link with a customer or a reviewer during that first ten-day window, the URL went dead on 2026-08-17, and the changelog doesn't mention anyone being told. And Lovable's launch blog post still hasn't been updated: as of today it reads "Any app you publish to public (not just a workspace) will expose a trust center," with no mention of the setting. A founder reading that page right now would believe they have a live trust page. They probably don't.
What is the Lovable Trust Center?
It is a security page Lovable generates for a published app at /.well-known/trust.html, with a machine-readable version at /.well-known/trust.json. Lovable announced it in its changelog on August 7, 2026. The docs describe about twenty checks across connection and browser security, deployment and runtime, database access control for Lovable Cloud apps, and security tooling.
Is the Lovable Trust Center on by default?
Not any more. It was on by default from early August 2026, then Lovable changed it on August 17. The changelog says the Trust center is now disabled by default, that you enable it in Project settings then Publishing, and that trust pages which were live before are offline until you enable the setting. Lovable's original launch blog post still has not been updated and still describes the old automatic behaviour.
Does a missing check on my trust page mean my app failed it?
Not on its own, and Lovable says so plainly. Its docs state that a reviewer cannot tell from the Trust center alone whether an omitted check failed or was never evaluated. A check can be missing because it does not apply to your app, because the feature is not turned on, or because your app needs republishing. The exception is the probed header checks, which apply to any app served over HTTPS and have no not-applicable state.
Can anyone read my trust.json without the link?
Yes. It needs no authentication and returns HTTP 200 to an anonymous request. The docs say the page is excluded from search engines, but that is a noindex meta tag on the HTML page only. The JSON file cannot carry a meta tag, carries no X-Robots-Tag header, and is not disallowed in robots.txt. The /.well-known/ prefix is a registered convention, so the path is guessable by design.
Should I turn the Trust Center off?
Turning it off hides the report, not the configuration. Anyone can read your response headers directly with one curl whether or not you publish a trust page. The better move is to fix the checks you do not pass, then publish the page because it is accurate.
See what your headers actually say
CheckYourVibe reads the same response headers the Trust Center grades, and tells you which ones are missing.