Evaluate as an MSP

​

Before you start

• Your organization already manages a client. The first client relationship is set up with us (contact sales); until then, creating a client is refused with 403.
• A Plan with fleet management (a Shadow AI plan, see Pricing). Your test clients run on your Plan. For step 3 your Plan must also include custom policies (Pricing).
• Two test devices (virtual machines will do) you can install software on. Supported platforms lists the operating systems.
• A place to receive alerts: your SIEM, or any HTTPS endpoint whose requests you can read.
• The Admin role in your own organization.

​

Step 1: Create two test clients

​

Step 2: Enroll one device into each client

1. On Client A’s row, click Act as. The dashboard switches to Client A and opens its Shadow AI page.
2. Click Add a device (enrollment token), and enroll the first test device with it (Fleet enrollment).
3. Switch back to your organization with the organization selector, click Act as on Client B, and enroll the second device with a token minted there.

​

Step 3: Give one client a policy the other does not have

1. Acting as Client A, open Projects → Shadow AI Fleet → Guardrails → Policies → Create policy: Policy Name Block codename (PoC), Policy Type Input Filter, one rule with Condition Contains Text (exact), value Project Falcon, Action Block.
2. Still acting as Client A, open Settings → Security and turn on Only admins can edit policies.
3. On each device, send Write the Project Falcon launch announcement. in claude.ai.

​

Step 4: Confirm events stay in their client

1. On each device, send the test prompt with the example AWS key AKIAIOSFODNN7EXAMPLE from Test it yourself (Step 4). It is AWS’s published documentation example and opens nothing.
2. Acting as Client A, open Projects → Shadow AI Fleet → Interactions. Then do the same acting as Client B.
3. Back in your own organization, open Dashboard → Clients → Client alerts and filter by each client in turn.

​

Step 5: Route alerts to your SIEM, tagged by client

1. Acting as Client A, open Projects → Shadow AI Fleet → Settings → Alert delivery and add your SIEM or endpoint as a destination. Do the same acting as Client B, with the same destination.
2. Send the AWS-key prompt again on each device. A block always raises an alert (which events alert).

​

Step 6: See each client on the billing roster

​

Step 7: End one client’s access and confirm it stops

1. Acting as Client B, revoke its device on the Shadow AI page and revoke its enrollment token. Ending a grant does not revoke them, and nobody can sign in to Client B afterwards to do it, because nobody there was invited.
2. Back in your own organization, on Client B’s row in Dashboard → Clients, click End.
3. Try to act as Client B through the API:

curl "https://api.promptguard.co/dashboard/fleet/devices" \
  -H "Authorization: Bearer YOUR_SESSION_TOKEN" \
  -H "X-Organization-Id: CLIENT_B_ORG_ID"

​

Success criteria

​

Before production

• Capacity per client understood. API keys in a client you created spend that client’s own per-minute budget at your Plan’s limit, so one busy client cannot use up another’s; once a client has an owner of its own, its keys spend that owner’s budget. Device scans are never rate limited (Rate limits). On a contract that pools scans across clients, watch GET /dashboard/organizations/clients/scan-allowance (Reconcile client billing).
• A policy baseline per client. Set each client’s policy and turn on Only admins can edit policies in each. There is no copy between clients, so keep your baseline in version control and apply it per client through the API (Copying a policy to another client).
• Rollout tokens per client, named. One rollout token per client, minted while acting as it and named after it, given only to that client’s MDM and revoked when the rollout is done (Roll out Shadow AI).
• Alert routing in place for every client. Each client’s Shadow AI Fleet project delivers to your SIEM, with a signing secret, and your SIEM routes on organization_id. Someone owns the Client Alerts queue for clients without a SIEM route (SIEM export).
• Device fail mode decided per client. What a device does when it cannot reach the engine, and alerts for devices sending prompts unchecked (Device fail-open alerts).
• Clients told what they will see. PromptGuard does not offer white-labelling: the dashboard, emails and the device agent are PromptGuard-branded (What your clients see).
• Billing reconciled monthly. Compare Counted and Billed for each client on the roster after each period closes.
• Offboarding written down. Before you end a grant: invite the client’s owner if they are to keep the environment, and revoke the enrollment tokens, devices and API keys that should stop working. Use End date for a planned handover, End for an immediate one (End access to a client).
• Proof-of-concept leftovers removed. Client A’s device and token are revoked, and its grant ended.

​

Next steps