Privacy

Privacy notice

The first public-page report is free and requires Google sign-in; paid and pilot offers have separate availability shown on Pricing. Domain verification is the one tool here that still works while you are signed out. This page describes, in plain terms, what the live tools do with the data you provide.

यह पृष्ठ केवल अंग्रेज़ी में उपलब्ध है।

Effective date: 3 September 2026

Who operates this site

Seges Trust is operated by 吳遠佛界, an individual trading as a natural person in Taiwan. There is no company behind it: “Seges” and “Seges Trust” in this notice mean that individual, who is the controller of the data described below. See the Terms page for more, and “How to reach us” below for what each route is for.

There is no data protection officer and no EU or UK representative. One person operates this site and answers everything here; saying so is more useful than naming a role that does not exist.

The instant page check (/critique)

When you submit a public URL to /critique, the server performs a one-time headless-browser visit to that page. The resulting report (the submitted URL, its host, a timestamp, and the findings) is scheduled for deletion 90 days after creation under a randomly generated report ID, so the report can be revisited later at its own permalink. Firestore TTL deletion is asynchronous, so an expired permalink can remain available briefly while the deletion is processed. If you are signed in when you submit, the report is also tagged with your Google account ID so it can appear on your Account page; if you are not signed in, no account ID is stored on the report. Some findings (the client-side secret scan) are withheld from that stored report and from the immediate response unless the submitted URL's host also holds a currently-verified domain-verification record. An unverified attestation alone does not unlock them.

Domain verification (/domain-verification)

Requesting a DNS ownership challenge stores the submitted host, a randomly generated verification token, a status (pending or verified), and timestamps in our database. Whether your Google account ID is stored on that record is decided when you first request the challenge, not when you confirm it: if you are signed in at that moment, your account ID is bound to the record, so a different account cannot claim it, and the verified domain will appear on your Account page. If you request the challenge anonymously (signed out), no account ID is stored on it, and signing in only later, when you confirm the challenge, does not retroactively add one. Confirmation must still complete under that same account (a mismatched or absent session at confirmation is rejected), but it never adds an account ID that wasn't already there. No other information about you or your site is collected by this feature. Each record is automatically deleted after its documented retention window: 24 hours for an unconfirmed challenge, or 30 days after a host is successfully verified.

Registering interest in a paid plan (/interest)

The paid plans on the Pricing page are not all available to buy. The signed-in audit begins with a scope conversation, Active Scan checkout is held closed, and continuing products remain design-partner pilots. If you use the form on the Register interest page to tell us you would pay for one, we store exactly three things: the email address you enter, which of the published plans you selected if you selected one, and your answer to the single free-text question on that form if you wrote one. Nothing else is collected there. No account is required, none is created, and the form does not read or attach your Google sign-in session even if you happen to be signed in.

Why we store it: so the operator can send one message about availability or the next step for the option you named, and count demand across current offers and application-only pilots when deciding what to prioritize. That is the only use. We never sell this information, never share it with anyone else, and never add it to a marketing list or an advertising profile. It is not linked to your critique reports, your verified domains, or any account record.

How long: each registration is scheduled for automatic deletion 90 days after your most recent submission, the same retention period as a critique report. Firestore processes TTL deletion asynchronously, so a record may remain briefly after its scheduled time while deletion is processed. Submitting the form again from the same address updates that one record rather than creating a second, and schedules deletion 90 days from that submission. Your address is stored in readable form, because being able to write back to you is the entire point of the record; the identifier used to file it is a SHA-256 hash of the address, which keeps the address itself out of database paths and error messages but is not an anonymisation claim. To have a registration removed sooner, write to contact@trust.seges.ai from, or naming, that address, and it will be removed by hand.

Purchase records (Creem)

Paid plans are sold through Creem, a third-party merchant of record. Creem, not this site, runs the checkout page and handles your card details: no payment card number, expiry, or security code ever reaches our systems or is stored by us. What Creem collects from you at checkout is governed by Creem's own privacy terms.

When a payment completes, Creem notifies us and we store one record per order in our database. That record contains: your email address as given to Creem, in readable form; Creem's own order and checkout identifiers; which product was bought; the order amount, the amount actually paid, any discount, and the currency; the order status; the time of purchase and the time we recorded it; and, if you were signed in when you followed the checkout link, your Trust account identifier. We store no card data, no billing address, and no name.

Why we store it: so that a signed-in owner can see on their Account page what they have actually bought, and so the operator can answer a refund or support question without you having to prove the purchase. Your email address is the key that links a payment to an account, which is why it is kept readable rather than hashed. We never sell it, never share it with anyone beyond Creem and our own hosting, and never add it to a marketing list or an advertising profile.

How long: indefinitely, with no automatic deletion. This is the one record type on this site that does not expire on its own, and the difference is deliberate rather than an oversight. Critique reports, interest registrations, product-research records and rate-limit entries have bounded retention targets because they are bounded-utility records. A completed financial transaction is not: refund windows, chargeback disputes and tax records all outlive any retention target we could honestly promise, so we do not state one we would have to break. If you want your purchase record deleted, ask at contact@trust.seges.ai and we will delete it unless we are still required to keep it for one of those reasons, in which case we will tell you which and for how long.

Signed-in audit private-page evidence and reports

A Signed-in Audit is operator-conducted against one written, approved HTTPS scope. For the run, our Cloud Run job loads a controlled Seges Google session from a private Secret Manager mount and completes the agreed sign-in to the customer's product. The customer does not send us their password, authentication code, payment credentials, or a browser cookie export. Apart from that agreed sign-in, the evidence pass is read-only: it uses GET and HEAD navigation within the approved host and path boundary and does not submit forms, create accounts, make purchases, or change customer data.

The resulting owner-only report stores an allowlisted summary: the operator-approved target URL and response status; bounded journey and accessibility counts; stable measured, observed, inferred or not-assessed finding codes; presence or quality booleans for selected trust, security-header and search signals; suspected-secret candidate and script counts; limitation codes; and job provenance. It does not store any page-derived free text, including the page title; the full browser report or arbitrary nested evidence; the Google or product session artifact; passwords or credentials; cookie or local-storage names or values; request-header names or values; form values; link or selector targets; secret labels, source filenames or excerpts; full raw HTML; screenshots; or complete matched secret values. A report outside that closed shape is refused before storage and again before buyer readback. The Signed-in Audit path does not send this private-page evidence to Moonshot AI or OpenRouter.

The report is stored in our Firestore database under a random report identifier, tied to the Trust account that owns the approved host, and shown through the signed-in Account surface rather than a public permalink. It is scheduled for deletion 90 days after the report is created; Firestore TTL deletion is asynchronous, so it can remain briefly while deletion is processed. When no Signed-in Audit request needs resolution, deleting the account also deletes that account's report immediately. The request and the Creem purchase ledger are different records and follow the separate rules below and above.

Signed-in audit requests and account deletion

A Signed-in Audit request is separate from its finished report. It records the approved scope, the authorization wording and attestations, the request and report identifiers, and, where money has moved, the order, refund, dispute, and delivery-reconciliation facts needed to determine whether work may start and whether it was delivered. It is scheduled for deletion no earlier than 90 days after creation or the latest accepted lifecycle event, such as scope approval, payment binding, run approval or claim, delivery, failure, refund, or dispute. Each accepted event moves the deadline at least 90 days forward and never shortens a later deadline. Firestore TTL deletion is asynchronous, so the record can remain briefly while deletion is processed.

The Account page never directly deletes a Signed-in Audit request. While that request records open work, an attributed paid order, a refund or dispute, or delivery that still needs reconciliation, account deletion is stopped before any account data is removed. Contact us first so the audit and its request record can be cancelled, refunded, completed, reconciled, or deleted safely. The Creem purchase record is a separate financial ledger, is not the report or authorization record, and follows the indefinite retention rule above even after an account is deleted.

Copying a fix prompt on /critique

Clicking “Copy fix prompt” writes the secret-redacted prompt already displayed in your report to your clipboard. It sends no separate request, asks for no additional email address, and creates no lead record.

The copied text is produced in your browser from the report already on the page. Copying it does not change the underlying report record or its retention period. Optional product-research questions remain separate and never unlock, hide, or change the prompt.

If you want the underlying critique report deleted, write to contact@trust.seges.ai and name the report ID. Copying the prompt creates no additional server-side record to delete.

Product research (/research and the end-of-report survey)

Two surfaces ask the same short set of market-research questions: a panel that appears at the end of a completed /critique report, and a standalone public page at /research that needs no report, no account and no scan to reach. Both write to the same record type. Answering is optional and answering nothing changes what the report itself shows or what /critique does for you.

If you submit either form, we store: which of the two surfaces you answered on; your answer to that surface's one required one-click question (whether anything in the report was new to you, on the panel, or whether you paid for a developer tool yourself in the last year, on /research); and whichever of the following you chose to answer: what worried you last time you shipped something, which paid developer tools you use and roughly what you spend, which AI coding tool you used most recently (/research only), where you usually work from, how often you actually worked from a cafe or co-working space last month, a one-line description of yourself, and an optional email address. On the panel only, we also record whether the report you had just read passed. No report ID, URL, host, or account ID is collected on either surface, even if you are signed in and even though the panel is embedded in a page that has all four: the form does not read your session and the route that stores answers never asks for them.

Why we store it: to understand who is likely to pay for a tool like this, where they work, and whether a coffee-shop partnership (the same idea described under “Copying a fix prompt” above) is worth building, before committing to build it. The email address, when you give one, is a way for us to follow up with you; it is optional, never used to identify or deduplicate a submission, and answering the form twice creates two separate records rather than updating one, because two opinions are worth keeping as two opinions. We never sell this information, never share it with anyone else, and never add it to a marketing list or an advertising profile.

How long: we aim to keep each submission no longer than 90 days, the same target as an interest registration, but the automatic deletion that would enforce that on our end is not switched on yet for this record type, so nothing currently deletes itself on schedule. If you gave an email address and want a submission deleted before then, write to contact@trust.seges.ai naming that address and roughly when you submitted it; a submission with no email address cannot be found or deleted on request, because nothing in it identifies who sent it.

Signing in with Google (required for a report)

Receiving a report from /critique requires a signed-in account, and so does requesting an active scan. Domain verification is the one tool here that still works while you are signed out. Google sign-in requests only your Google account ID and email address, never your password, contacts, files, or any other Google data. We store the Google account ID, email, and the times you first and most recently signed in until you delete the account from the Account page. When no signed-in audit needs resolution, that action deletes the account record, every verified domain attached to that account, any of your own still-pending (unconfirmed) domain challenges, every critique report, active-scan report, and segesagent audit report attached to that account, and your own activity log described below under “Your own account's activity log”. Signed-in audit requests and Creem purchase records follow the separate rules below. Signing in does not widen what these tools check; it is what lets a report be issued to you at all, and the withheld secret-scan findings still turn on DNS domain verification rather than on the account.

Two counters are the deliberate exception to that deletion. A record of how many free critique reports, and how many free or paid active-scan units, your account has used, a Google account ID and a bare count of what has already been spent, nothing else, no IP address and no report content, is kept even after you delete your account. Google account IDs are permanent, so deleting and recreating an account would otherwise reset these free allowances to zero and let anyone reclaim them at will; the counters exist solely to stop that, and hold nothing usable for any other purpose.

Account consent records (Terms acceptance and marketing preferences)

Signing in the first time holds you at a one-time consent step before your account is usable. Accepting the Terms there is required; four marketing choices shown next to it are not, are decided separately from that acceptance, and can be changed at any time from the Account page, where withdrawing is exactly as easy as granting.

Terms acceptance is written once, the moment you accept, and never overwritten afterwards: which version of the Terms and which wording of the checkbox you were shown, the date and time, the language you read it in, and the IP address and browser/device identifier (user agent) the acceptance came from. This is what lets a later dispute over these Terms be checked against the version you actually agreed to, not whatever version is live today.

Each of the four marketing categories (product updates, discounts and offers, security news, and Seges ecosystem news) is recorded the same way, separately, every time you change it: whether you granted or declined it, the date, which wording you saw, the language, whether the decision was made at signup or later on the Account page, and the same IP address and user agent. Choosing the “Seges ecosystem news” category specifically means your email address is used to tell you about noesis.seges.ai and farm.seges.ai as well as this site; every other category, and declining that one, keeps your address scoped to Seges Trust alone.

Why we store it: consent is our only lawful basis for the marketing categories, and a consent record that only says “yes” is not evidence of what you actually agreed to or when. We never sell this information and never share it beyond what “Seges ecosystem news” itself describes. How long: these records live on your account and are deleted, along with everything else described under “Signing in with Google” above, the moment you delete your account.

Referral program

If you are signed in, you have your own referral link, built around a code minted the first time anything asks for it. Sharing it and having someone else create an account through it is recorded on both accounts: your own account stores the referral code your link carries, and the account that was referred stores which code brought them and which account that code belongs to, written once at the moment their account is created and never rewritten afterwards. We use this only to work out how many people you have referred and whether any of them has gone on to buy a paid plan, which unlocks additional free reports under the referral ladder described on /critique and /account.

Why we store it: to run the referral ladder honestly, crediting the account that actually sent the link rather than one it merely claims to. We never sell this information, never use it for advertising, and never share it with anyone else.

How long: this lives on both accounts' records. Deleting your own account deletes your referral code and stops it from crediting anyone in the future. If an account you referred deletes itself, that account's record of having been referred by you is deleted with it, and it stops counting toward your referral total from that point on, because the count is worked out fresh from live accounts each time rather than stored as a running total.

Active scanning (signed-in, verified owners only)

A signed-in account holding current DNS verification for a host can request an active scan of that same host only after separate authorization; injection testing needs an additional acknowledgment. There is no free-form target field. We store the request (host, tier and timestamps) and a bounded execution record: tool and check names, status, timing, stop or failure metadata, permitted hashes and byte counts. Raw tool output is discarded and is not stored in the report. The report has no public link, is readable only by its account, and is scheduled for deletion 90 days after creation. Active Scan checkout is currently held closed; payment never verifies a host, grants authorization or starts a run.

Proof of authorization for active scanning

Because an active scan sends real, non-passive requests to your own infrastructure, we keep a separate, durable record every time one is authorized, so that if it is ever disputed later whether a particular scan was authorized, we can show who agreed, when, from where, to exactly what wording, and for exactly what host and tier. This record is written the moment you submit the active-scan form, before the scan itself runs; if we cannot write it, the scan does not run.

Each record holds: your Google account ID; the exact host and scan tier (whether injection testing was included) the request covered; the two authorization checkboxes above, recorded separately; which version of the checkbox wording you were actually shown; a server-generated timestamp; and the IP address and browser/device identifier (user agent) the request came from. Unlike the hashed IP address behind the rate-limit record described below, this IP address is stored in plain, readable form, it exists specifically so it can be produced and read as evidence of where a request came from, which a hash cannot do on its own.

Why we store it: solely to prove, if it is ever questioned, that a specific active scan was authorized and by whom. We never sell this information, never share it with anyone else, and never use it for analytics, marketing, or any purpose other than answering that one question.

How long: 3 years from the scan request, longer than the 90 days an active-scan report itself is kept, because a dispute about whether a scan was authorized can surface well after the report has already expired, and because a claim over an authorized-but-disputed action of this kind is realistically raised within the first year or two if it is raised at all, not a decade later. Three years also stays well short of the longest limitation period that could apply, so the plain IP address in this record is not retained for longer than is actually useful to its one purpose. To ask about or request deletion of a consent record before its 3 years are up, write to contact@trust.seges.ai naming the host and approximate date of the scan.

Automated interpretation by third-party AI (Moonshot, OpenRouter fallback)

Two features can send bounded, minimized data to a third-party large-language-model API. For Active Scan, only the execution structure described above may be sent to summarize run completion and coverage; raw tool output is discarded before this boundary and no graded security findings are generated from it. Separately, when /critique flags a marketing-claim pattern, the matched phrase and a surrounding excerpt capped at 1,500 characters may be sent so the explanation addresses that wording. A page with no flagged wording does not trigger that call.

These calls go to Moonshot AI first, with OpenRouter used only if the call to Moonshot fails. We do not have a signed data-processing agreement with either provider governing how long they retain request content on their own systems; what we send is bounded by a fixed character limit per item and used only to generate the interpretation returned to us, and we do not use either provider to build a profile of you. The resulting interpretation is stored as part of the same report described above (critique or active-scan, same 90-day retention) and is always advisory: it can add plain-language context and, for marketing claims, an explanation of why a phrasing pattern commonly draws regulatory attention, but it can never invent, remove, downgrade, or override a finding our own deterministic checks did or did not make.

IP address use

Every request's IP address is used for country-based access control and rate limiting. Country resolution is handled in memory and is not stored by the geography gate. The current policy is worldwide by default, with United Kingdom requests refused on protected functional routes and mainland China requests refused only for Active Scan routes. Functional routes also fail closed when location cannot be resolved. Public documents including this notice, pricing, refunds and contact remain readable from those locations.

Region gating writes nothing. The country is resolved by a lookup against a local data file, in memory, for the duration of that single request. Nothing about the request is stored.

Rate limiting does write a record. For each rate-limited request we store one document in our database whose identifier is a SHA-256 hash of the route you called, your IP address, and that route's window and request-count settings. The document contains the timestamps of your recent requests to that route and a scheduled deletion time; it is automatically deleted about 10 minutes after the last request it counted. Your IP address is not stored in plain text. We do not describe that hash as anonymous: an IPv4 address is drawn from a small enough space that anyone holding the hash and a candidate address can test whether they match, so it remains an identifier, just one we do not store in readable form and cannot reverse in bulk. These records are used for nothing except enforcing rate limits: they are not analytics, they are never linked to your reports, verified domains, or account, and they are not shared.

Your own account's activity log (first-party, always on for signed-in use)

Separately from Microsoft Clarity below, our own server keeps a log of what your signed-in account did: the pages you loaded while signed in, when a critique or active scan you requested started, finished, or failed (and which host it was for), when you signed in or out, and when a purchase completed or was refunded. Each entry is written by the same server request that did the thing it describes, never by a script running in your browser that could fail to send, be blocked, or be skipped because of a choice you made about Clarity.

This is not gated by your Clarity choice, and is not the same kind of thing. /critique and /active-scan already require you to be signed in, so every action this log records is one our server was already doing on your account's behalf, using the account ID from your signed, HttpOnly session cookie, the same fact the report you asked for, the scan you ran, or the purchase you completed already required us to know. Recording that it happened is how a signed-in product keeps working (so your Account page can show what you have done, so we can investigate abuse of the free allowance, and so a disputed action can be checked against what our own server actually did), not a form of marketing measurement, so declining or never answering the Clarity banner does not turn it off. Nothing is logged here for a visitor who is not signed in: there is no substitute identifier minted to track anonymous browsing, and none of this exists before you sign in for the first time.

Why we store it: to operate the account-gated parts of this product (showing you your own history, protecting the free allowance and rate limits described elsewhere on this page from abuse, and being able to answer a dispute about what a specific signed-in action actually did), and, in aggregate, to understand how the product is used well enough to improve it without depending on a third-party recorder. We never sell this information, never share it with anyone else, and never use it for advertising.

How long: we aim to keep each entry no longer than about 13 months, but the automatic deletion that would enforce that on our end is not switched on yet for this record type (the same stated gap as the product-research records above), so nothing currently deletes itself on schedule. Deleting your account from the Account page deletes every entry in this log immediately, the same as every other record described under “Signing in with Google” above.

Analytics and session replay (Microsoft Clarity)

This site can use Microsoft Clarity, a third-party analytics and session-replay service. It does not load unless you have accepted it. Until you choose, and if you decline, no Clarity script is fetched, no connection to Microsoft is opened, and no cookie of theirs is set. Ignoring the banner counts as declining, because nothing loads until an affirmative yes. Before 3 September 2026 this was not true: Clarity loaded for every visitor on every page, with no consent step, and this notice said so.

Our lawful basis is your consent, and nothing else. We do not claim a legitimate interest in recording you. That means you can refuse without giving a reason and without losing access to anything: every tool on this site works identically whether you accept or decline, and declining is one click in the same place, at the same size, as accepting.

What Clarity records is more than page views. It records how you interact with the page (mouse movement, clicks, scrolling, keystrokes into the page, and the page content around them) and reconstructs those interactions into a replayable recording of your individual visit, plus aggregate heatmaps. We use these only to understand and improve how the site is used. It also sets its own cookies (in current versions, a persistent visitor identifier and a per-session identifier) to recognise returning and in-session visits. Clarity applies content masking by default to reduce the capture of sensitive input, but a session replay is still a recording of your visit, not an anonymous counter, and that is the reason it is gated rather than merely disclosed.

This data is collected and processed by Microsoft as an independent analytics provider, under Microsoft's own terms and on Microsoft's systems, not ours. What Microsoft does with it is governed by the Microsoft Privacy Statement and the Microsoft Clarity terms. We use it purely to improve the site; we do not use it to build an advertising profile of you.

How to withdraw, and what withdrawing actually does. The control below changes your answer at any time, in either direction, without giving a reason. Withdrawing does two real things: Clarity is not loaded again on any later page view, and we ask it to clear the cookies it already set. It cannot un-run a recorder that is already running in the page you are on, and it cannot delete a recording already sent to Microsoft. If you want an existing recording removed, write to contact@trust.seges.ai and we will act on your request. Your choice is stored only in your own browser, under the key trust-analytics-consent, and is never sent to us; clearing your site data therefore clears the choice too, and you will be asked again.

Independently of the control above, you can also block third-party scripts or cookies in your browser or use a tracker or content blocker. Because Clarity is never loaded without consent, those measures are a second layer here rather than the only defence.

Cookies

If, and only if, you accept the analytics described above, Microsoft Clarity sets its own cookies. Decline, or simply never answer, and it sets none, because it is never loaded. Separately, where Google sign-in is enabled and you use it, one signed, HttpOnly session cookie is set, containing your account ID, email, and an expiry; it keeps you signed in and expires automatically after 14 days, and a second short-lived cookie exists only during the sign-in redirect itself and is deleted within minutes. Your analytics choice itself is not a cookie: it is kept in your browser's local storage and never sent to us. This site sets no advertising or cross-context tracking cookies at all.

Your privacy rights

Whatever your location, you can ask us to exercise your rights over the small amount of data this site holds about you: to access what a specific record contains, to correct it, to delete it, or to object to a particular use. Apart from the Microsoft Clarity analytics described above (which Microsoft processes on its own systems, and which you can opt out of as explained there), this site keeps very little of its own, no advertising profile, and nothing beyond a short-lived rate-limit hash unless you sign in, submit a check, register interest in a paid plan, or answer the product-research questions on /research or at the end of a report. Most requests therefore come down to opting out of Clarity, or deleting a critique or active-scan report by its ID, a domain-verification record by its host, a research submission that named an email address, an interest registration by its email address, or your own first-party activity log. You can clear the account-linked records described under “Signing in with Google” from the Account page, subject to the signed-in audit and purchase-record exceptions described above.

If you signed in with Google, you can use the Account page to delete your account record and the records it can safely remove immediately, when no signed-in audit requires resolution. For anything else, including any signed-in audit request that remains on its separate retention schedule, or if you did not sign in, write to us using the details just below and we will action it. We do not sell your personal information and we do not use it for cross-context behavioural advertising; we do share site-interaction data with Microsoft as our analytics provider, as described under Analytics above, and, only for the two bounded cases described under Automated interpretation above, scan or page-text data with Moonshot AI and (on fallback) OpenRouter.

How to reach us

Privacy questions and requests about your own data (access, correction, deletion, or an objection to a particular use) go to contact@trust.seges.ai. The same address takes security reports, and objections from anyone whose site was checked by /critique without their authorization. Please include enough detail to identify the record: a critique report's permalink or report ID, or the host on a domain-verification record. If you signed in with Google, you can delete your account record and the records that can be safely removed immediately from the Account page, without writing to anyone, when no signed-in audit needs resolution. See the Contact page for the full description of what that address covers.

You can also post or telephone a request, using the trading address and number under “Who operates this site” above. Email is the practical route and the one that leaves you a record, but a right you can exercise through only one channel is not much of a right, so the others are published and they work.

This notice describes current behavior only and is not a substitute for legal advice. See also the Terms page for the conditions that apply to using /critique.