Permissions and access

How you connect a client, which organization it acts in, what each permission grants, and how to revoke it

There is no token to paste anywhere. The MCP server uses standard OAuth: your client sends you to a browser, you sign in with the ModernPentest account you already use, and you approve what it asked for. From then on the assistant acts as you, in one of your organizations, with exactly those permissions.

Connecting a client

Add the server

Follow the setup for your client in the quickstart. They all point at the same endpoint, https://modernpentest.com/mcp.

The client opens a browser on the ModernPentest sign-in page, then shows a consent screen listing exactly what it is asking for. Approve it and the connection is live — nothing is copied between browser and client by hand.

A client that asks for nothing gets read-only access. If you later ask it to do something it was not granted, the call fails and names the missing permission — reconnect and grant it.

Your access is re-checked on every single call — there is no session to outlive a change. Remove someone from the organization, or change their role, and their connected assistants lose that access immediately.

Choosing an organization

The connection identifies you, and you may belong to more than one organization.

One organization — nothing to do. Every call acts there.
Several — tell your assistant which one: "use the acme-staging organization". It passes the name through as the organization argument.

If you belong to several and don't say, the call fails with an error naming your organizations rather than guessing. That argument only picks among organizations you already belong to; it never grants access to a new one.

What you are granting

Permission	What it lets the client do
`mcp:read`	Read applications, scans, vulnerabilities, reports and attestations
`mcp:applications:write`	Register applications and scan targets, and start domain verification
`mcp:pentests:write`	Start and cancel penetration tests
`mcp:vulnerabilities:write`	Change vulnerability status, assignment and notes
`mcp:reports:write`	Generate and export reports
`mcp:attestations:write`	Generate letters of attestation and change their visibility
`mcp:organizations:write`	Create organizations and manage subscription checkout

Permissions are split by how much damage a mistake does, not by which screen the data lives on: marking a finding a false positive is a security decision your next report and letter of attestation will be built on, and starting a pentest spends your monthly quota and puts real traffic on a live system. Any write permission includes read; nothing includes a write.

Permissions are not the only gate. Your role in the organization is checked on every call by the same rules as the dashboard, so a granted permission can never let an assistant do something your own account cannot.

Running your own agent

An unattended agent — something on a schedule, with nobody at a browser to approve a consent screen — uses an organization-scoped API key instead. There is no self-serve issuance screen yet; ask support@modernpentest.com for a key scoped to your organization and the permissions it needs.

A key created on Settings → API Keys will not work here. Those keys (mpt_…) are for the REST API and the MCP server rejects them. Ask support for an MCP key specifically.

curl -sS https://modernpentest.com/mcp \
  -H "Authorization: Bearer $MODERNPENTEST_MCP_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Such a key is pinned to the organization it was issued for: pointing it at a different one fails outright rather than being quietly ignored, so a misconfigured agent stops instead of operating somewhere unexpected.

An organization-scoped key has no acting person behind it, so anything it writes is attributed to the organization's owner. Treat it as an organization-wide credential: one key per agent, the fewest permissions that agent needs, and rotate it like any other production secret.

Revoking access

A connected assistant — remove the connector or integration in the client.
An API key — ask support to revoke it. The next call it makes fails.
A person — removing them from the organization, or lowering their role, takes effect on their assistants' very next call.

Every call that reached an organization is recorded in its MCP audit log, under Account → MCP in the dashboard: who or what called, which tool, and whether it succeeded. Arguments are not stored — only a fingerprint of them, so your hostnames and finding titles never land in an audit table.

When a call is refused

Message	What to do
Names a missing `mcp:…` permission	Reconnect the integration and grant it. Retrying will not help.
"belongs to multiple organizations"	Tell the assistant which organization to use.
"No organization … is accessible to this account"	You are not a member of the one you named, or its name is wrong.
"scoped to … and cannot act on …"	An API key is being pointed at the wrong organization.
Everything fails as unauthorized	The credential was revoked or expired. Reconnect the client, or ask for a new API key.
A plan limit	The MCP server is on every plan, but the action itself is capped. Upgrade, or wait for the quota to reset.

Last updated: September 2, 2026

On this page