> ## Documentation Index
> Fetch the complete documentation index at: https://docs.promptguard.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Managed Service Providers

> Run PromptGuard for several client organizations from one place: create a client, act in it, roll out Shadow AI per client, triage every client's alerts, and reconcile what each client was billed.

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](https://docs.promptguard.co/platform/organizations.md#managed-service-providers).

To try all of this on two test clients first, with pass/fail criteria, follow [Evaluate as an MSP](https://docs.promptguard.co/guides/evaluate-msp.md).

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](mailto:sales@promptguard.co). 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](https://docs.promptguard.co/pricing.md)).

## 1. Create a client organization

1. Go to **Dashboard → Clients** and click **Add client**
2. Enter the **Client name**
3. 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
4. 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](https://docs.promptguard.co/platform/organizations.md#invite-members): 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:

> [!NOTE]
>
> **`/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](https://docs.promptguard.co/api-reference/introduction.md)).
>
> 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.
>
> ```bash theme={"system"}
> # 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`.

```bash theme={"system"}
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](https://docs.promptguard.co/platform/audit-logs.md) 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](https://docs.promptguard.co/shadow-ai/fleet-enrollment.md) 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:

1. 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](https://docs.promptguard.co/guides/security-admin.md#3-author-the-policy) walks through each lever. Custom rules need custom policies on your Plan, which the client runs on
2. 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`:

```bash theme={"system"}
# 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](https://docs.promptguard.co/security/custom-rules.md).

The CLI's `promptguard policy apply` ([Policy-as-code](https://docs.promptguard.co/security/policy-as-code.md)) 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](https://docs.promptguard.co/integrations/siem-export.md#the-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](https://docs.promptguard.co/integrations/siem-export.md#verify-that-a-delivery-came-from-promptguard)).

## 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:

```bash theme={"system"}
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](https://docs.promptguard.co/production/rate-limits.md#rate-limiting)). 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](https://docs.promptguard.co/platform/organizations.md#set-when-a-client-loses-access-for-providers))
* **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](#6-triage-in-the-client-alerts-queue) or your SIEM, and report to them in your own tooling.

## Next steps

> [card] [Evaluate as an MSP](https://docs.promptguard.co/guides/evaluate-msp.md)
>
> Two test clients, isolation, per-client alerts and ending a grant, with pass/fail criteria

> [card] [Fleet enrollment](https://docs.promptguard.co/shadow-ai/fleet-enrollment.md)
>
> Enrol devices with per-device credentials, by hand or through MDM

> [card] [SIEM export](https://docs.promptguard.co/integrations/siem-export.md)
>
> The event format, signing, Splunk and Sentinel

> [card] [Organizations & Teams](https://docs.promptguard.co/platform/organizations.md#managed-service-providers)
>
> Grants from the client's side: approving and ending a provider's access

> [card] [Rate limits](https://docs.promptguard.co/production/rate-limits.md)
>
> Per-minute budgets and monthly quotas


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.