Frequently Asked Questions

Questions about how ArgosX scans and tests your app.

Authenticated testing

What does authenticated testing actually do?

To verify real user journeys, ArgosX signs in to your app and performs actions a typical user would: creating an account, filling and submitting forms, and placing a test order. This creates and changes records in your app, the same way a real user would.

Will it make real payments?

No. Testing never makes real-money payments. It only interacts with sandbox/test-mode payment flows (e.g. Stripe test keys). You can explicitly allow or disallow this when you start a scan.

What actions does it refuse?

ArgosX refuses to click controls labelled delete, remove, pay, or purchase. It will not trigger destructive or real-money actions even if they appear in the flow.

Will it change data in my database?

Yes, in the same way a real user would. Accounts may be created, forms submitted, and state changed. Treat any environment you point ArgosX at as one where data can change, and keep your own backups. If you want a clean run, point it at a staging or test environment.

Who is allowed to submit an app for testing?

Only the owner of the app, or someone explicitly authorized to test it. By submitting, you confirm that you have that authorization. Submitting an app you do not own or control without permission is a violation of our Terms.

I built my app on Base44, how should I set it up for a Pro scan?

Base44 apps are fully supported. For the deepest scan, give ArgosX an email and password test login rather than a “Sign in with Google” (social) login. Our tester signs in the same way a person would, and it can fill an email and password form reliably. A Google sign-in popup it cannot, and should not, complete on your behalf, so a social-only login leaves the scan stuck on the logged-out surface.

If your app only offers social login, use bring your own session: you sign in once yourself and hand us the resulting session when you start the scan, so we test as the logged-in you without ever seeing your Google password. Either way, point us at a test account with sample data, not your real one, since an authenticated scan creates and changes records like a real user.

How do I enable an email + password login on Base44, Bolt, or Replit?

A Pro scan signs in and tests everything behind your login, so it needs a test account it can log into. An email + password account is the most reliable: our tester fills the login form the way a person would, but it cannot (and should not) complete a “Sign in with Google” popup on your behalf. Always use a test account with sample data, never your real one, since an authenticated scan creates and changes records. Here is how to get one on the common builders:

Base44, Base44 apps accept email + password on their own sign-up page:

Open your published app URL and use its Sign up form to register a test account with an email and password.
Log in once to confirm it works, and add a little sample data.
Give us that email and password when you start the scan.

If your app only shows a Google sign-in, use bring-your-own-session instead (below).

Bolt, Bolt apps usually authenticate through Supabase:

In Supabase → Authentication → Providers, make sure Email is enabled, and turn off “Confirm email” so a test account works immediately.
Create the test user from your app's sign-up page, or in Supabase → Authentication → Users → Add user.
Give us that email and password.

Replit, Replit apps with their own backend usually already have email/password sign-in:

Use your app's Sign up / Register form to create a test account.
Confirm you can log in with it.
Give us that email and password.

If it uses Replit's built-in social Auth instead, use bring-your-own-session (below).

Should I give one test login, or two?

One test login is enough for a full Pro scan of everything behind your own sign-in. But if you give us two separate test accounts, we can run the single most valuable check there is: can one user reach another user's data?

With two logins, we sign in as each account in turn and then try to make one account read or change the other one's records, its orders, profile, uploads, or messages. When that works, it is the kind of flaw where any customer can pull up any other customer's data just by changing an id in the URL. It is the most common serious bug we find in vibe-coded apps, and it can only be caught with a second account to test against.

To set it up, create two test accounts the same way as above, give each a little distinct sample data so we can tell them apart, and enter both when you start the scan, the second one goes in the “Second role” fields. As always, use test accounts with sample data, never real customer logins.

What if I don't have a test login to give?

Then a Pro scan is not the right tool yet. Without a test login, a Pro scan can only reach the same logged-out pages a visitor sees, which is exactly what our free deep scan already covers, at no cost. Run the free deep scan instead, and keep any Pro scan (or a sponsor/event code) for when you have a test account set up, since that is where Pro earns its keep, everything behind your login.

Free scans

Can I run a scan from Claude Code, Cursor or Windsurf?

Yes. ArgosX ships an MCP server, so your coding agent can start a scan, read the findings, and pull a fix prompt for any one of them without you leaving the editor. Setup is one block of JSON in your tool’s MCP config — the how-to is here.

Two things worth knowing before you try it. Scans run in our cloud, so the app has to be deployed somewhere reachable; localhost will not work. And scans started this way are signed-out only, because testing behind a login needs credentials you hand over deliberately, which is not something an agent should do for you in the background.

Those steps run free scans on your free-tier limits, no key required. To run paid scans through MCP, generate an API key on your profile page and add it as ARGOSX_API_KEY. Keyed scans are part of the monthly Pro subscription, so they need an active Pro plan.

What does the free scan check?

The free scan is unauthenticated: it checks publicly visible pages for security misconfigurations, exposed data, and common vulnerabilities without signing in. It does not create accounts or submit forms.

How many free scans can I run?

Two limits, and most people never meet either. Up to 5 free scans per hour from one network, which is there to stop automated abuse rather than to ration you. And up to 3 free deep scans on the same app in a rolling 7-day window.

The second one is per app, not per account, so scanning a different app is always free, you can check as many projects as you like. It only applies when you re-scan the same app repeatedly, which usually means you are iterating on fixes. If you reach it, we will show you the options rather than simply stopping you.

What does a Pro scan add that a free scan cannot do?

A free scan never signs in, so it only ever sees what a logged-out visitor sees. Most of what your users actually touch, dashboards, forms, uploads, anything behind your login, is invisible to it.

Pro signs in with a test account you provide and uses the app the way a customer would: filling forms, submitting them, and checking what really happened afterwards rather than whether a success message appeared. It also removes the per-app weekly limit above.