Most MSP work is not one environment. It is a book of them.
Someone has to open the right client, check what is still reachable, see what changed since last week, and leave a trail the next engineer can follow. That is a lot of clicking when the book is twenty organizations instead of two. Teams already point their own AI agents at ticketing, documentation, and internal tools. Those agents should be able to work PortWarden the same way: through an API, inside the same provider and client boundaries your staff already use.
That is what we built.
What shipped
PortWarden's API is ready for the AI agents an MSP already operates.
A provider administrator issues API keys from the MSP workspace. Those credentials let your agents work the provider account and the client organizations under it. They do not get a side door around tenant isolation. They act as your automation, not as a second product with its own privileges.
The portal is still the place you set the rules: which staff can administer the book, which client users can log in, and what each organization may see or change. The API inherits that shape. If an org cannot manage endpoints in the UI, your agent should not treat that org as a free-for-all either.
Why this belongs on the MSP side of the product
The homepage is for a lean team watching their own edge. The MSP page is for a provider watching many edges.
That is why the announcement lives on the MSP page, next to team users, organizations, permissions, and the API key screen. If you resell or fully manage monitoring for clients, that is the surface that already describes the book of business. The API is another way to operate that same book.
Useful jobs look like this:
- Open the right client organization from a ticket or a chat, instead of hunting through a list.
- Pull current inventory and finding context so an agent can draft the next step for a human.
- Keep provider work in the same system of record your staff already use, instead of a spreadsheet that drifts overnight.
We are not publishing a public endpoint catalog on the marketing site. If you need access for a live book of business, contact us and say you want MSP API access for your own agents.
What your agents should not pretend to be
PortWarden identifies and monitors internet-facing exposure. It watches authorized assets and reports what changed. An agent using the API does not become a SOC, a penetration tester, or a compliance stamp.
A few fences stay in force:
- Scan only assets you own or are explicitly authorized to test. Written permission still matters when you are the contractor.
- Advisory AI guidance in the product can be incomplete. Treat it as a starting point, not a verdict.
- Risk acceptance, false positives, and client-visible reports still need a human who can defend the call.
- Keys are secrets. The workspace already warns operators not to paste them into tickets.
If a client asks whether you "have an AI that keeps them safe," the honest answer is no. You have scheduled visibility, a trail of findings, and now a way for your own agents to operate that trail without making the security decision for you.
How to start
- Read the MSP workspace if you have not already. White-label, per-org permissions, and custom quotes live there. There is no public Free/Basic/Premium table on that page.
- Decide which automations get keys. Prefer one key per agent or workflow so you can revoke a single integration without killing the rest.
- Keep client portal logins separate from provider admin. Agents should not need a shared human password.
- Contact PortWarden with client count, whether clients log in themselves, and that you want API access for your agents.
If you already have a provider account, start from the API key screen your admins already use. If you do not, we quote MSP work from volume and how you want to run the book.