This page collects the public checks a buyer, security reviewer, crawler, or AI assistant can use to verify what Phixe claims before a statement of work is signed. It is deliberately conservative: it proves the public identity, operating posture, deliverable shape, disclosure path, and live-site provenance without exposing client names or private traces.
Public proof links
| Check | Public URL | What it verifies |
|---|---|---|
| Company profile | /company | What Phixe is, who does the work, independence rules, and how engagements are scoped. |
| Trust and data handling | /trust | Access rules, staging-first testing, least privilege, NDA-first scope, evidence handling, and work Phixe refuses. |
| Methodology | /methodology | How AI systems are tested across LLMs, RAG, agents, MCP, platform controls, evals, and retest. |
| Sample report | /resources/sample-ai-assessment-report | The structure of the deliverable a buyer can review: scope, threat model, evidence, findings, fix plan, and retest. |
| Shipped work | /work | Anonymized systems Phixe has built, hardened, or assessed, with what can be verified under NDA. |
| Privacy policy | /privacy | Website analytics, booking data, engagement evidence, subprocessors, retention, and privacy requests. |
| Security disclosure | /.well-known/security.txt | The canonical vulnerability reporting path for Phixe’s public site and materials. |
| Human-readable provenance | /humans.txt | Simple company and site provenance for humans and crawlers. |
| AI reader map | /llms.txt | The pages Phixe wants AI tools to read before summarizing its services and evidence. |
| Live deployment marker | /deployment.json | The public build manifest used by Phixe’s live verification scripts to prove the deployed site matches the expected release. |
What can be checked before scope
Before any access is granted, you can inspect the engagement mechanics:
- Report format. The sample report shows the evidence standard and how findings are written.
- Rules of engagement. The trust page describes what must be written down before testing starts: environments, accounts, tools, data classes, boundaries, and out-of-scope systems.
- Test method. The methodology and guides show the surfaces Phixe tests, including prompt injection, RAG leakage, agent tool abuse, MCP capability exposure, eval regressions, and platform controls.
- Retest criteria. Findings close only when the original reproduction path no longer works under the same evidence standard.
- Confidentiality stance. Client identities, traces, domains, screenshots, prompts, and commercial terms are not used as public proof without written permission.
What requires NDA
Some proof belongs in a private review, not on a public web page:
- Representative request traces and redacted evidence examples from similar systems.
- The exact statement of work for your environment.
- Credentials, endpoint lists, system diagrams, and test accounts.
- Client-specific proof behind anonymized shipped-work claims.
- Any insurance, procurement, or legal artifact your buyer requires before access is granted.
The public site is the starting record. The NDA review is where Phixe can show more without turning another client’s confidential material into marketing.
Boundaries this page does not cross
This page is not a certification, legal opinion, or promise that an AI system is “safe.” Phixe gives evidence for what was tested, what broke, what did not break, what was fixed, and what residual risk remains. It also does not replace Search Console, external profiles, references, or procurement diligence. Those signals still matter, and they should be built over time.
It also does not imply client endorsement. Phixe does not run a logo wall and does not publish client names without written permission.
How to use this page
If you are a buyer’s security reviewer, start with the sample report, then read the trust page and methodology. If you are verifying the public site itself, fetch /deployment.json, /sitemap.xml, /llms.txt, /humans.txt, and /.well-known/security.txt.
If those public artifacts do not match the current site, treat the deployment as stale until the live verification gate passes.