To verify real user journeys, ArgosX signs in to your app and does what a typical user would: navigating, searching, and filling in and submitting ordinary forms. It never deletes, pays, checks out, or sends emails or invites. This can create and change records in your app, the same way a real user would.

No. Our test agent refuses pay, purchase and checkout buttons, so it never makes a payment. A payment flow can be covered by a separate write-test in test mode, only with your OK.

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.

Yes, in the same way a real user would. Records may be created, forms submitted, and state changed (never deleted, paid for, or checked out). 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.

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.

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 can create and change records like a real user.

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

Should I give one test login, or two?

Then a Pro AI scan is not the right tool yet. Without a test login, a Pro AI 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 AI 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.

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.

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.

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.

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.

No. The ArgosX GitHub Action runs inside the client's own CI. On each push it calls ArgosX with the app's deployed URL and an API key, we scan the running app, and the build passes or fails on the result. We never read the repository, install a GitHub App, or receive the code.

The key is stored as a repository secret named ARGOSX_API_KEY in each client repo. You can mint one account-wide key, or, recommended for agencies, a key bound to a single appfrom the app's “Set up CI” panel on your agency dashboard: if a bound key ever leaks from one client's repo, it cannot scan, read, or attest any other client's app.

Yes. Each push re-attests the whole app, so the result is always a complete picture. Being straight about the trade-off: because we sign in and drive the app, that takes tens of minutes, which is why most teams gate merges and releases rather than every push.

You can also test a single subtree by setting scope-globs on the Action (for example "/billing/**"). We measured that at about a quarter faster and a third cheaper than a full scan. It is still tens of minutes, so it makes a cheaper merge gate rather than a per-commit one. A scoped run is clearly marked as a partial attestation, so a partial result can never pass as a full one.

Apps are identified by their deployed URL, not the repository. The usual setup is one repo, one deployed URL, one app, but a single repo can gate several apps (one Action step per URL) and the gate is always per-app.