What an ArgosX assessment is

The process

1. 01

   Map

   We crawl the app signed out and signed in to find the pages, actions, and data endpoints that actually exist, not just the ones linked in the menu.

2. 02

   Test

   An AI agent signs in and uses your app like a customer, then goes after the failures that actually leak data: exposed databases, secrets shipped to the browser, and access that crosses from one account into another.

3. 03

   Confirm

   When it finds an exposure, it confirms it and captures the proof: the exact request and a screenshot of the data that came back. You see what actually happened on your live app, not just a warning that something might be wrong.

4. 04

   Human-verify

   On a human-verified assessment, a person on our team reviews the findings, confirms the real ones, and runs the checks that apply to your app hands-on, so the report is not a false-positive dump. This is the tier that earns the word assessment.

A real ArgosX report (our own app): the VibeScore, findings ranked worst-first, each carrying the proof we reproduced and a one-line fix.

How we grade and evidence findings

• Severity by real impact and exploitability. Each finding is graded critical, high, medium, or low on what an attacker could actually do and how easily, the way industry standards such as OWASP and CVSS reason about risk.
• Evidence on every confirmed finding. It carries the request and a screenshot, the steps to reproduce it, and the fix, so you can verify it yourself and close it.
• Data exposure ranks highest. A confirmed anonymous or cross-account read of real data is graded above a theoretical or posture-only issue.

How we count

When we quote numbers about the apps we have scanned, this is what they mean.

• As of 2026-10-01, automated scans have run on 13,121 distinct apps. Public-surface scans make up the bulk; signed-in Pro scans and human passes are a small subset.
• A finding is a check that failed, graded by a fixed severity rubric. Findings we later confirm are false are retracted.
• “High severity” spans security and accessibility. 43.8% of those apps had at least one high-or-critical finding; 13.2% had a high-or-critical security finding.
• “Readable without a login” is not the same as “sensitive data exposed.” Many readable tables are public by design (catalogs, blog posts).

Coverage and limitations

The honest part, and the part most tools skip. A report is only useful if you can trust what its clean checks actually mean.

• We tell you what was tested and what was not. A clean result is scoped to what we assessed, not a blanket guarantee.
• We name any role we could not sign in as, so you can see the gap rather than mistake it for coverage.
• The human pass is read-only: our tester signs in and looks, and doesn't submit forms, upload files, start a checkout, or test several users at once. The AI scan does fill in and submit ordinary forms like a user would, but refuses to delete, pay, check out or send messages, and doesn't upload files. Issues inside those flows can remain; a separate write-test can cover them, only with your written OK.
• We test the app an attacker reaches. We do not scan your cloud infrastructure, your dependency tree, or your internal network; those are different tools for a different job.
• This is an independent security assessment, not an accredited audit or a certification. If you need a formal compliance attestation, that is a separate, accredited process.

Want the other side of this, the specific checks we run? See what we test.

Common questions