Every claim here carries its scope and the date it was checked.
A security page is only useful if its sentences can be argued with. These can: each one says where it holds, how it is known, and when somebody last looked. The ones that do not hold sit in the same table as the ones that do.
How each row is known.
- Code inspection
- Somebody read the source that implements it on the date shown. It proves what the code does, not what a running deployment answered.
- Automated test
- A test asserts the behaviour and fails the build when it stops holding, so the date is the last time the suite ran rather than the last time anybody looked.
- Tool scan
- A scanner produced the result on the date shown. A scan is a photograph: it is true of that commit and says nothing about the next one.
- Configuration
- A setting in this application's own configuration. It is what the deployment is asked to send, which is not the same as a response observed in a browser.
The website and the accounts on it.
This storefront and the administration behind it. The hosted Tools platform is a separate application and is not covered by implication here.
Administration requires an internal role, a second factor enrolled against that account, and an elevation minted by that factor within the last thirty minutes.
Every administration page and every server action behind them. The three conditions are re-derived on the server for each request, because an action is reached by a request of its own and the page having passed proves nothing about it. The elevation is absolute rather than idle-based, so it expires thirty minutes after the factor was accepted however busy the sitting was.
Code inspection · checked
The administration address is not treated as a control, and nothing on this site depends on it being unknown.
Stated so it is on the record: an unlisted address survives one screenshot and one browser history export. The three conditions above are what keeps people out.
Code inspection · checked
Transport security, frame protection, content type sniffing, referrer policy and permissions policy are all set, and the framework version header is suppressed.
Configured on this application for every path. Transport security is two years with subdomains and preload. What a deployed response actually carries has not been verified against a live host and is not claimed here.
Configuration · checked
A content security policy is sent report-only, which means it blocks nothing.
It is a measurement instrument with no collector connected to it yet, so at present it neither blocks nor records. Enforcing it is a separate piece of work that has to inventory the actual scripts first, and until that happens this site has no script-injection prevention from this header.
Configuration · checked
Sign-in and sign-up only ever return to a destination on this site, including after an external identity provider callback.
Both forms and the callback path share one return-path check that rejects absolute addresses and backslash tricks.
Code inspection · checked
Repeated password and second-factor attempts are counted, and an account locks for thirty minutes after enough failures.
The counters live in one server process's memory. They are not shared between instances and do not survive a redeployment, so they are protection against one browser in a loop and are not distributed protection. Making them durable is open work.
Code inspection · checked
An error shown to a visitor is either an error written for visitors or a generic one.
Internal messages are not forwarded to the browser. The classification leans partly on a heuristic over unnamed errors rather than on an exhaustive type, so it is a strong default rather than a guarantee.
Code inspection · checked
Twenty-five public pages are rendered and audited for accessibility on every run, and a serious or critical finding fails the build.
Automated rules only, which is roughly a third of what accessibility means. The keyboard path and real assistive technology are covered separately and by use.
Automated test · checked
Hosted Tools, and the data inside them.
A separate application, a separate database and a separate sign-in. A storefront account is not a Tools account and cannot become one by accident.
Tools run in their own identity realm, with their own sign-in and their own signing secret. A session on this storefront cannot reach them.
An architectural separation, inspected in this application's configuration. The storefront reads only the Tools platform's public catalogue endpoint, which is unauthenticated by design and returns only published Tools.
Code inspection · checked
No Tool is published for sale yet, so no customer document, prompt or run history exists on the platform today.
The state of the catalogue. It is the reason several rows here describe intended behaviour rather than operating experience, and it is better said plainly than implied by silence.
Code inspection · checked
A Tool's system instructions, thresholds, evaluation cases and model configuration stay on the server.
They are excluded from client bundles, from the public catalogue payload and from anything a browser receives. A customer-facing activity record can say what was read, what was done and what was approved without carrying any of it.
Code inspection · checked
If the Tools platform stops answering, this storefront shows an empty catalogue rather than an error.
Every failure of that call resolves to an empty list behind a short timeout. A Tools outage therefore never takes the applications for sale, their prices or the way to ask about one off the air.
Code inspection · checked
Nothing measures whether a hosted agent completes its work, or how often it fails.
No monitoring vendor is connected to either application. This is an open gap rather than a quiet one, and the Status page reports it as unmeasured rather than green.
Code inspection · checked
What a buyer receives as evidence.
Produced by a transfer checker that runs from a clean clone with pinned scanner images, so a result never depends on what happened to be installed on the machine that produced it. The artifact by artifact view, including the open items, is on the Trust page.
Each application was swept by a twelve-check transfer checker from a clean clone, at a recorded commit.
Mission Control, Real Estate and Family Travel on 2026-10-24; Teams on 2026-10-25. The report names the commit it ran against, and a sweep is only true of that commit.
Tool scan · checked
Each application installed, migrated and built from an empty database with nothing from our machines involved.
Passed for all four, with the number of tables the migration produced recorded in each report.
Tool scan · checked
No required VoyantIQ runtime service dependency was found in any of the four repositories.
A scan for sibling imports and calls back to VoyantIQ across every source file. It is an architectural finding about the inspected commit. It is not a licence position, and what VoyantIQ retains is settled in the agreement rather than by this check.
Tool scan · checked
The full commit history of each application was scanned for secrets, not only its current tree.
Passed for all four. One finding in Family Travel was reviewed and recorded as ignored rather than silently suppressed.
Tool scan · checked
Dependency advisories were enumerated rather than summarised as clean.
No critical advisory in any of the four at the swept commit, and high severity advisories in all four, counted in each report. An advisory count ages immediately, so a buyer receives a fresh one at delivery.
Tool scan · checked
Three of the four applications currently have a required check that has not passed.
The handoff documentation check fails for Mission Control, Real Estate and Family Travel. The licence allowlist is in review for all four. These are open items with a readiness status on the Trust page rather than footnotes.
Tool scan · checked
What VoyantIQ is not, and does not claim to be.
- VoyantIQ holds no SOC 2 report, no ISO 27001 certificate and no equivalent attestation, and none is in progress.
- No third party has performed a penetration test, a security audit or a code review of this application.
- Every row above is VoyantIQ checking its own work. That is worth something, it is not worth what an audit is worth, and the difference should not have to be inferred.
Reporting something you have found.
Write to dwayne@voyantiq.com with the address you were on, what you did, and what happened. You will get a human acknowledgement within three working days. There is no bounty programme and no money changes hands, which is said here rather than discovered after the work is done.
What keeps a report safe to make: use your own account or one you created for the test, stop at the first proof rather than going further, take nothing that belongs to anybody else, and do not degrade the service for other people. Automated scanning against the site is not useful and is not wanted. Give it ninety days before publishing, or sooner once a fix has shipped and you have been told so.
A report made inside those lines is treated as a contribution, and we will not pursue you for it.