Agents as customers

An AI agent can be a ModernPentest customer. It can create the organization, register the application, prove you own the domain and run pentests without anyone opening the dashboard for the routine parts.

One step deliberately still requires a human, and it is not going away: paying. Every eligible organization gets one free preview, so an agent can get to a first result on its own: the preview's findings are listed by title, severity and endpoint, but their details stay locked until a pentest credit ($1,500) or a plan unlocks them. Anything beyond that preview needs a credit or a plan, bought by a person at /dashboard/billing in their browser.

Enroll from a repository

For Claude Code, Cursor or another coding agent, use Enroll from your repository. The server distributes the workflow as initialize instructions and the enroll_application MCP prompt, so there is no separate skill to install.

The sequence is: select an organization and check usage, reuse or register the application, prepare test users and API configuration, prove ownership, follow one approved scan, then fix and verify reproduced findings. Account and API configuration comes before checking proof because an application created in the dashboard may already have an automatic first scan requested.

Organizations and payment

A person creates their first organization in the dashboard and authorizes the MCP connection. create_organization is for an additional organization and requires mcp:organizations:write. It cannot be called with an organization-scoped API key. An account that has already created three organizations, including deleted ones, gets its next organization held; contact support rather than creating another to evade that hold.

The free preview belongs to the organization. get_organization_usage reports the exact next entitlement and any refusal. Purchases stay in the browser at the returned purchaseUrl; no MCP tool purchases a credit or a plan.

Why proof of domain control is required

A pentest sends genuine attack traffic (authentication attempts, injection payloads, active probing) at a live system. Doing that to a system you do not control is unauthorized access, and ModernPentest's infrastructure is what generates the traffic. If an agent could register competitor.example and press go, the platform would be the party attacking it. So we ask for proof of control rather than taking anyone's word, and there is no operator who approves a target instead.

Two methods, either of which proves a host:

• DNS TXT record. Publish _modernpentest-verify.<host> with the value modernpentest-verify=<32 hex characters> at your DNS provider. It is keyed on the exact hostname, one record per host: a record at _modernpentest-verify.app.example.com proves app.example.com and nothing else, and api.example.com needs its own. Not offered for shared hosting suffixes, where the tenant cannot publish records under the provider's zone.
• HTTPS well-known file. Serve https://<host>/.well-known/modernpentest-verify.txt containing the line modernpentest-verify=<32 hex characters>, over HTTPS on the default port, with status 200 and no redirect. It is keyed on the exact hostname too: a file on app.example.com proves that host and nothing else. The file may carry several lines, so an agency and its client can both prove one host.

Both proofs name the host rather than the domain on purpose. Anyone who can add records under a shared DNS zone could publish a record at the zone's apex, so a record keyed on the domain would prove hosts that are not theirs; a record under the host's own name is the host owner's to publish. An operator approval, granted by ModernPentest support, is the one proof that covers a whole domain, along with a domain-wide record an organization verified before September 2026, which keeps proving the hosts under it; the tools report either as the proof for each host, and verify_application_domain issues nothing for a host that is already proven.

The token is 128 bits of randomness and is the entire proof. Proof is per organization and never expires: an agency and its client may both legitimately verify the same host, one proving control never grants the other the right to scan it, and a host an organization has proven once stays proven for every application that targets it.

The requirement is fixed when the application is created and no tool can opt its own target out. It applies to every application created since September 2026, whether over the MCP server, the REST API or the dashboard, and to every way of starting a scan on one. Applications created before that were authorized by an operator at the time and keep working; the tools tell you when you are looking at one rather than claiming a block that will not happen.

Running unattended

For an agent that runs on a schedule with no human in the loop, use an organization-scoped API key instead of a browser authorization. See Permissions and access.

• Grant the minimum permissions. An agent that reports on findings needs mcp:read and nothing else.
• An org-scoped key is pinned to one organization. Passing a different organization fails outright rather than being ignored, so a misconfigured agent stops instead of acting somewhere unexpected.
• Writes are attributed to the organization's owner, since the key has no acting user. Issue one key per agent so the audit log stays readable.
• Call get_organization_usage before anything that spends quota; it is cheaper than discovering the limit from a failed start_pentest.
• Tool calls land in the MCP audit log, visible to admins and owners under Account → MCP in the dashboard.

What an agent cannot do

Last updated: September 7, 2026