Managed Service Providers

This guide is for a managed service provider (MSP) running Shadow AI and the gateway for several clients. Your organization is the provider. Each client gets an organization of its own, and you act in it through a grant: the record that lets your organization work in the client’s with a role, without your staff joining it. The client’s side of a grant, and how a client approves or ends one, is in Organizations & Teams. To try all of this on two test clients first, with pass/fail criteria, follow Evaluate as an MSP. Everything below is done by an Admin of the provider organization, from the provider organization (the organization selector in the dashboard’s top bar names the one you are acting as).

Before you start

Your organization must already manage a client. The first client relationship is set up with us: contact sales. After that, creating clients is self-serve. Until then, creating a client is refused with 403.
Your Plan covers your clients. A client you create has no subscription of its own: it runs on your Plan, and you are billed for it. To roll out Shadow AI to client devices, your Plan must include fleet management (a Shadow AI plan, see Pricing).

1. Create a client organization

Go to Dashboard → Clients and click Add client
Enter the Client name
Optionally, enter the Client’s owner: an email address at the client. They are invited as the client organization’s owner, so the client owns its environment: they can see everything, add their own people, and end your access. You still pay for the client
Click Add client

The client is created with no owner and no members, and your organization holds an Admin grant over it at once, with no approval step: you created it, so there is nobody to ask. If you invited an owner, the invitation follows the usual rules: only that address can accept it, and if the email could not be sent the dialog shows the link to send yourself, once. The same through the API, acting as your own organization:

/dashboard/* takes a dashboard sign-in, not an API key. These endpoints are the API the dashboard at app.promptguard.co calls. They are not part of the public API, and no API key or long-lived token works on them. Everything under /api/v1 takes your X-API-Key instead (API reference).To script one anyway, sign in with your email and password. This needs an account that has a password, and an email domain that requires SSO is refused. The access token lasts one hour.

# 1. Sign in. The response body carries access_token; the jar keeps the cookies.
curl -c jar.txt https://api.promptguard.co/dashboard/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com", "password": "..."}'

# 2. Any GET under /dashboard sets the csrf_token cookie.
curl -b jar.txt -c jar.txt https://api.promptguard.co/dashboard/auth/me
CSRF=$(awk '$6 == "csrf_token" { print $7 }' jar.txt)

# 3. Send the cookies on every call, and X-CSRF-Token on POST, PUT, PATCH and DELETE.
curl -b jar.txt -H "X-CSRF-Token: $CSRF" -X POST https://api.promptguard.co/dashboard/...

Where an example shows YOUR_SESSION_TOKEN or YOUR_SESSION_COOKIE, it means the access_token from step 1, sent as Authorization: Bearer <token> or as the access_token cookie. A request acts on your personal organization unless it sends X-Organization-Id.

curl -X POST https://api.promptguard.co/dashboard/organizations/clients \
  -b jar.txt -H "X-CSRF-Token: $CSRF" \
  -H "X-Organization-Id: YOUR_PROVIDER_ORG_ID" \
  -H "Content-Type: application/json" \
  -d '{"name": "Acme Dental"}'

The response is the new organization, with owner_id null. To give it an owner later, invite one from the client’s Settings → Team while acting as it (an organization with no owner can be sent one owner invitation).

2. Act as the client

On Dashboard → Clients, click Act as on the client’s row (or Act as in the dialog that follows Add client). The dashboard switches to the client organization and opens its Shadow AI fleet. Everything you do there is done in the client’s organization, and recorded in its audit log as your organization’s action. Act as is offered on clients where your grant is Admin. Switch back to your own organization with the organization selector. Through the API, acting as a client is the same X-Organization-Id header, naming the client.

3. Roll out Shadow AI, one fleet per client

Each client organization has its own Shadow AI fleet, with its own Shadow AI Fleet project, its own devices, events and policies. Enrol every client’s devices into that client, never into your own organization: that is what keeps each client’s events, alerts and billing separate. While acting as the client, on its Shadow AI page:

Add a device (enrollment token) for one machine, or
Create a rollout token (MDM) for a bulk rollout: it enrols any number of devices into that client for 30 days. Give it to the client’s MDM, and revoke it when the rollout is done

Repeat for each client, with a token minted while acting as that client. A token always enrols into the organization it was minted in, so a rollout token handed to the wrong client’s MDM is the one way to mix two clients’ devices: label each token with the client’s name. Fleet enrollment covers the two ways a device can join, MDM configuration and revoking a device.

4. Set and lock the policy for each client

Policy belongs to a project, and a project to one organization, so each client’s policy is its own. While acting as the client:

Open Projects → Shadow AI Fleet → Guardrails (and the same on any gateway project the client has). Pick a strictness level on Built-in Detectors, and add your own rules on the Policies tab. The security admin path walks through each lever. Custom rules need custom policies on your Plan, which the client runs on
To stop the client’s own people changing what you set, open Settings → Security and turn on Only admins can edit policies in the Policy editing card. From then on only an Admin can create, edit or delete a policy there. Your Admin grant counts as Admin, so you keep editing. An Owner or Admin at the client can turn the lock off again: it protects your policy from the client’s staff, not from the client

Copying a policy to another client

There is no copy between clients: no dashboard action or API route moves a policy from one organization to another. To keep one baseline across clients, hold it in your own version control and apply it to each client through the dashboard API, naming the client in X-Organization-Id:

# Built-in detector levels for one of the client's projects
curl -X PUT "https://api.promptguard.co/dashboard/projects/CLIENT_PROJECT_ID/guardrails" \
  -b jar.txt -H "X-CSRF-Token: $CSRF" \
  -H "X-Organization-Id: CLIENT_ORG_ID" \
  -H "Content-Type: application/json" \
  -d '{"guardrails": {"prompt_injection": {"level": "strict"}, "pii_detection": {"level": "strict", "mode": "redact"}}}'

# One custom rule on the same project
curl -X POST "https://api.promptguard.co/dashboard/policies" \
  -b jar.txt -H "X-CSRF-Token: $CSRF" \
  -H "X-Organization-Id: CLIENT_ORG_ID" \
  -H "Content-Type: application/json" \
  -d '{"name": "Block internal codenames", "policy_type": "input_filter", "project_id": "CLIENT_PROJECT_ID", "rules": [{"condition": "contains_text_any", "value": "Project Falcon|Project Osprey", "action": "block"}]}'

Run it once per client, with that client’s organization and project ids. The PUT replaces the project’s whole detector configuration, and any check you leave out goes back to its default, so send your complete baseline every time. GET /dashboard/policies?project_id=CLIENT_PROJECT_ID lists what a client already has, so a script can update rather than duplicate. The lock in step 2 applies to these calls as it does to the dashboard. The rule format is in Custom rules. The CLI’s promptguard policy apply (Policy-as-code) is not the route for this. It authenticates with an API key and sends no organization, so it reaches only projects owned by the person who created the key, never a client project through your grant.

5. Send alerts from every client to your SIEM

Alerts are delivered per project. While acting as a client, open its Shadow AI Fleet project’s Settings → Alert delivery and add your SIEM as a destination. Do this once per client: one SIEM can take all of them. Every delivery is the same SIEM event, and names the client it came from in organization_id and organization_name, with a dashboard_url that opens the event acting as that client. Key your SIEM’s routing on organization_id. Generate a signing secret on the project’s Delivery security card to have deliveries signed (verifying a delivery).

6. Triage in the Client Alerts queue

Without a SIEM, or alongside one, Dashboard → Clients → Client alerts (also Client Alerts in the sidebar) lists the alerts raised in every client you hold an Admin grant over, newest first. Filter by client, severity and triage status. Open as client opens the event acting as that client. A client whose grant ends drops off the queue at its next refresh. The API behind it:

curl "https://api.promptguard.co/dashboard/organizations/clients/alerts?severity=critical&days=7" \
  -H "Authorization: Bearer YOUR_SESSION_TOKEN" \
  -H "X-Organization-Id: YOUR_PROVIDER_ORG_ID"

client_id narrows it to one client, and status to one triage status.

7. Reconcile client billing

Dashboard → Clients is the roster: one row per client you hold a live grant over, including clients with nothing enrolled yet. For each client it shows:

Live endpoints: the devices deployed now, over a rolling window
Counted and Billed: what the last closed billing period counted for that client, and what was invoiced, side by side, so a disagreement is about one visible number

Expand a client to see its earlier billed periods. Clients you no longer manage but were billed for are listed apart, with the periods billed to you for them. The same data is at GET /dashboard/organizations/clients/endpoint-usage and, per client, GET /dashboard/organizations/clients/{client_id}/billed-periods. On a contract that pools scans across your clients, GET /dashboard/organizations/clients/scan-allowance returns each closed month: the endpoints billed, the scans they made, the allowance, and the scans above it.

8. Know each client’s capacity

API keys in a client organization you created spend their own per-minute rate-limit budget, at your Plan’s limit, so one busy client cannot use up the minute of your other clients or of your own keys (Rate limits). Scans from enrolled Shadow AI devices are not rate limited at all. Once a client has an owner of its own, its keys spend that owner’s budget.

9. End access to a client

From Dashboard → Clients:

End date sets the last day of your access. For a client you created you can set, move or remove it; for a client that approved your access you can only bring it earlier. From the end of that day (UTC) your organization can do nothing in the client (details)
End ends your access now (DELETE /dashboard/organizations/clients/{client_id}/grant). You lose access at once and stop paying for the client

The client keeps its devices, events and history either way. Ending a grant does not revoke the enrolment tokens or API keys created in the client while you had access: revoke them first, acting as the client, if they should stop working. If nobody at the client was ever invited, nobody can sign in to it once your access ends, so invite the client’s owner before you hand it over.

What your clients see

PromptGuard does not offer white-labelling. There is no setting for your own name, logo, domain or email sender, so a client sees PromptGuard:

The dashboard is PromptGuard’s, at app.promptguard.co, if you invite people at the client to sign in to it
Emails, such as the owner invitation from step 1, come from PromptGuard’s own address
On each device, the Shadow AI agent and its menu-bar shield are PromptGuard’s
Alerts you forward from your SIEM carry PromptGuard’s event format, with a dashboard_url that opens PromptGuard’s dashboard

If your clients should see only you, keep them out of the dashboard: triage in the Client Alerts queue or your SIEM, and report to them in your own tooling.

Next steps

Evaluate as an MSP

Two test clients, isolation, per-client alerts and ending a grant, with pass/fail criteria

Fleet enrollment

Enrol devices with per-device credentials, by hand or through MDM

SIEM export

The event format, signing, Splunk and Sentinel

Organizations & Teams

Grants from the client’s side: approving and ending a provider’s access

Rate limits

Per-minute budgets and monthly quotas

Get Started

Paths

Core Concepts

Gateway

Integrations

Shadow AI

SDKs

Developer tools

Cookbooks

Platform

Going to Production

Resources

Roadmap / Preview

Managed Service Providers

Before you start

1. Create a client organization

2. Act as the client

3. Roll out Shadow AI, one fleet per client

4. Set and lock the policy for each client

Copying a policy to another client

5. Send alerts from every client to your SIEM

6. Triage in the Client Alerts queue

7. Reconcile client billing

8. Know each client’s capacity

9. End access to a client

What your clients see

Next steps

Evaluate as an MSP

Fleet enrollment

SIEM export

Organizations & Teams

Rate limits

​Before you start

​1. Create a client organization

​2. Act as the client

​3. Roll out Shadow AI, one fleet per client

​4. Set and lock the policy for each client

​Copying a policy to another client

​5. Send alerts from every client to your SIEM

​6. Triage in the Client Alerts queue

​7. Reconcile client billing

​8. Know each client’s capacity

​9. End access to a client

​What your clients see

​Next steps

Evaluate as an MSP

Fleet enrollment

SIEM export

Organizations & Teams

Rate limits

Before you start

1. Create a client organization

2. Act as the client

3. Roll out Shadow AI, one fleet per client

4. Set and lock the policy for each client

Copying a policy to another client

5. Send alerts from every client to your SIEM

6. Triage in the Client Alerts queue

7. Reconcile client billing

8. Know each client’s capacity

9. End access to a client

What your clients see

Next steps