Meilynx completed an independent, authenticated (Tier 2) penetration test of the Meilynx proxy in August 2026, conducted by an independent security firm. No critical or high-severity findings were identified. The single medium-severity finding was remediated and verified closed in a retest. The full report is available under NDA through our Trust Center.
That is the whole announcement. The rest of this post is about why we tested what we tested, and how we think you should read any vendor's pentest claim, including ours.
Scope
We tested the thing that carries your traffic
Security testing is only as meaningful as its target. Ours was the Meilynx proxy: the inline data plane that sits between a customer's applications and the model providers, enforcing policy on every request. It is the component that touches prompts and responses, holds the enforcement logic, and writes the audit trail. If an attacker gets to choose one Meilynx component to break, this is the one, so it is the one we handed to professional attackers first.
The test was authenticated, which matters more than the word "penetration" does. An unauthenticated scan tells you whether your front door locks. An authenticated assessment gives the tester valid credentials and asks what a legitimate but malicious client could reach from the inside: authorization boundaries, tenant isolation, routing controls, error handling, the places where real risk lives in an API product. Testing was performed against live managed proxy endpoints, following OWASP methodology.
One architectural choice shaped what this test could even reach. Most AI security gateways route every customer's traffic through shared, multi-tenant infrastructure, which means a data-plane finding is every customer's finding. Meilynx's data plane is single-tenant: each customer's managed proxy is a dedicated, fully isolated instance with customer-scoped keys and a customer-scoped audit store. That is a heavier way to build, and we built it that way on purpose. Your prompts and responses never transit infrastructure shared with another tenant, so the blast radius of anything a tester (or an attacker) finds is one customer's dedicated stack, never a shared pipe.
Results
What was found, stated plainly
Vendors like to say they "passed" a pentest. Penetration tests are not pass/fail, and a diligence team knows it, so here is the actual result: zero critical findings, zero high-severity findings, one medium-severity finding, and a small number of low-severity hardening items.
The medium finding was a validation gap in how one proxy handled a request-path identifier. It was fixed and independently verified closed in a retest before the final report was issued. The low-severity items were configuration-hardening recommendations of the kind these assessments exist to surface; they were addressed or are tracked to closure.
We are publishing the severity summary and not the finding details, deliberately. The specifics belong in the report itself, which names endpoints and reproduction steps, and that level of detail is exactly what NDA-gated distribution is for.
Why it matters
The same standard we sell
Meilynx exists because regulated firms should not have to take anyone's word for how their AI systems behave, including ours. Our product's core claim is examination-grade evidence: a tamper-evident audit trail an examiner can verify independently, produced by controls that were themselves examined in our SOC 2 audit.
An independent penetration test is that philosophy applied to our own attack surface. Not a questionnaire answer, not a self-assessment: an outside firm with credentials and a mandate to break things, followed by a written record of what they found and what we did about it.
Reading pentest claims
Questions worth asking any vendor
If you are evaluating AI infrastructure vendors, a pentest claim deserves the same scrutiny as a compliance badge. Four questions you should ask potential vendors that will help separate substance from marketing:
- Was it authenticated? Unauthenticated testing exercises the perimeter. Authenticated testing exercises the product.
- What was in scope? A test of the marketing site says nothing about the data plane. Ask whether the component that touches your data was the target.
- Were findings retested? "Findings remediated" is a claim; "verified closed in retest" is a record.
- Can you read the report? A vendor who will not share the report under NDA is asking you to trust the summary. Ours is in the Trust Center.
Getting the report
The report lives in our Trust Center
Like our SOC 2 report, the penetration test report is not published on the open site. Customers and prospects can request it under NDA through our Trust Center, alongside live control status and our GDPR documentation. If your diligence process needs more, write to hello@meilynx.com.