ModernPentestModernPentest

Agents as customers

Sign up, pay, prove you own the domain and run a pentest — end to end, over MCP

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

Two steps deliberately still require a human, and they are not going away: paying and being approved to scan.

The MCP server never asks for payment details and never bypasses operator approval. Any flow that appears to let an agent pay or self-approve is a bug — report it.

The flow

Create the organization

A person authorizes an MCP client with their ModernPentest account, granting mcp:organizations:write. The agent then calls create_organization, which returns the URLs a human needs next.

This makes an additional organization, not the first one. Every call acts inside an organization the caller already belongs to, so an account that belongs to none is told to create one in the dashboard. An organization-scoped API key cannot create organizations at all — its writes are attributed to the organization's owner, and that would make a person the legal owner and billing contact of an account they never asked for.

A human chooses a plan and pays

The person switches to the new organization and picks a plan on the billing page. Payment happens in hosted checkout, in their browser, with their card. The agent's job is to hand over the link and wait; it can poll get_organization_usage to see the tier change.

An operator approves the organization

New organizations stay pending until a ModernPentest operator approves them. Until then, creating applications and starting pentests both fail — this is the platform's own gate, not an MCP restriction, and it applies to dashboard signups too. get_organization_usage reports the approval state, so the agent can say "we're waiting on approval" instead of retrying a call that cannot succeed.

Register the application

{
  "name": "Acme Storefront",
  "targetUrl": "https://app.acme.com",
  "restApiBaseUrl": "https://api.acme.com/v1",
  "environment": "production"
}

Only public http(s) targets are accepted. IP addresses, localhost and internal hostnames are rejected — there is no way to prove ownership of them, so they must go through an operator.

register_application creates the application, attaches the scan target, and starts DNS domain verification for every distinct registrable domain the targets live on, returning the records to publish.

Verify the domain by DNS TXT

Publish these DNS records to prove ownership:
  _modernpentest-verify.acme.com  TXT  "modernpentest-verify=1f4c…"   (domain: acme.com)

SCANNING IS BLOCKED: this application requires domain verification and a
pentest will be refused until every target domain is verified.

Publish the record with your DNS provider, then call verify_application_domain; it performs the lookup and reports whether the gate has opened. DNS changes take minutes to hours to propagate and checks are attempt-limited (25 per domain), so poll on the order of minutes, not seconds. get_domain_verification_status answers the same question without spending an attempt.

Point either tool at an application someone created in the dashboard and the answer reads differently: those are authorized by operator approval of the organization instead, so the DNS gate does not apply and the tools say so rather than claiming a block that will not happen.

Run the pentest

start_pentest with the application id. It is marked as requiring confirmation because it sends real attack traffic and spends quota. Poll get_pentest_progress while it runs, then list_vulnerabilities and get_vulnerability for the results.

Why domain verification 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, in most jurisdictions a criminal offence, 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 the agent's word.

  • The record is _modernpentest-verify.<domain>, valued modernpentest-verify=<32 hex characters>. Publishing it requires control of the domain's DNS, which is the thing being proven. The token is 128 bits of randomness and is the entire proof.
  • It is keyed on the registrable domain, so one record covers app.example.com, api.example.com and example.com:8443. A REST API on a genuinely different domain needs its own record.
  • It is per organization. An agency and its client may both legitimately verify the same domain; one proving control never grants the other the right to scan it.

The requirement is fixed when the application is enrolled and no tool can opt its own target out. It applies to every application registered over the MCP server or the REST API, and to every way of starting a scan on one.

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 — cheaper than discovering the limit from a failed start_pentest.
  • Tool calls land in the MCP audit log, visible to admins and owners under AI Assistants in the dashboard.

What an agent cannot do

Why
Pay, or enter payment detailsCheckout is a human, browser-hosted flow. The MCP server has no payment path at all.
Approve its own organization for scanningOperator approval is a platform gate and is not exposed as a tool.
Scan an unverified domain on an application it registeredThe DNS proof is checked before a scan can start, on every path that starts one.
Scan an IP address or an internal hostnameNo record can be published under them; these need an operator.
Read credentials, or another organization's dataNeither is reachable at any permission level — see Tools.

Last updated: September 2, 2026

On this page