Enroll from your repository

Read the repository and agree on the target

The agent reads deployment configuration, environment examples, OpenAPI files, authentication routes and existing seed scripts. It checks your ModernPentest applications before creating anything, then shows the proposed public URLs, environment and test-account roles. Use a deployed environment you control; localhost, private hosts and IP addresses cannot be enrolled through these tools.

One application can include a web app and its REST API. For an API-only application, the agent registers the API target and removes the web surface before scanning. Registration consumes an application slot but does not start a pentest.

Prepare authenticated coverage

Your agent creates dedicated accounts with your application's existing signup, admin or seed tooling, then verifies that they can log in. Two accounts in separate tenants, with the roles you want tested, allow checks across account and organization boundaries. It sends the intended account roster through set_test_users, then adds any TOTP or existing fixed test code through set_verification_code_source.

set_test_users stores the accounts ModernPentest will use; it does not create them in your application. It replaces the entire roster, so your agent first checks the existing account summary and preserves it unless you want a replacement. Passwords and code secrets are never returned by MCP.

For a REST surface, configure_application accepts the repository's OpenAPI JSON or YAML directly, up to 512 KB, or enables discovery for the scan. There is no need to expose a private specification at a public URL.

Prove ownership after configuration is ready

The tools return the exact proof for each host: a DNS TXT record or an HTTPS file at /.well-known/modernpentest-verify.txt. Your agent prepares the file or DNS change using your normal deployment tooling. A file in your local checkout only becomes proof after it is deployed. Hosts on shared hosting such as vercel.app use the HTTPS method.

An existing application created in the dashboard may already have an automatic first scan requested. In that case, checking proof or changing to a proven target can start that scan. The agent finishes accounts and API configuration first, shows the live entitlement from get_organization_usage, and asks you to approve the scan before taking that step. Proof is shared by host within your organization, so it also checks for other pending applications using the same host before releasing their scans.

get_domain_verification_status reads status without spending an attempt. verify_application_domain checks the published proof; failed checks use a limited attempt budget, so DNS retries should be minutes apart.

Follow one pentest

The agent checks list_pentests before calling start_pentest. If a first scan is already starting or running, it follows that scan instead. For a new scan it shows the current plan quota, credit or free preview it would consume, then starts once you approve.

The scan runs asynchronously. Ask for progress at any time; your agent reads get_pentest_progress and can return the scan link while it continues. If an automatic start is refused, the agent reports the recorded reason instead of starting another scan or polling indefinitely.

Bring the finding back to the code

When the scan finishes, the agent reads the findings and the captured evidence needed for the fix. It proposes changes in your repository and runs your project's checks. After the fix is deployed to the tested environment, you can ask it to mark the finding remediated, which requests live verification. This step needs mcp:vulnerabilities:write and your authorization for the verification run. The platform marks the finding fixed only when verification confirms the fix.

Free-preview findings may have locked details. The agent follows the returned unlock link rather than guessing hidden evidence; purchases happen in your browser.