Security Admin Path

You need the Owner or Admin role in the organization. Some steps need a plan that includes the feature; each says which feature, and Pricing says which plans have it. Managing client organizations as a provider? Start with the MSP guide; the steps below then apply inside each client.

​

1. Connect sign-in to your identity provider

Settings → SSO.

1. Configure SSO opens a hosted portal where you connect Okta, Microsoft Entra ID, Google Workspace or another SAML or OIDC provider, and set the email domains allowed to sign in.
2. Configure Directory Sync connects SCIM, so people you add or remove in your directory are added to or removed from PromptGuard. Removal ends access at once.
3. Sign in once with a test account from your identity provider.

Needs SSO on your plan. Detail: Single sign-on, Directory Sync.

​

2. Give people the least role they need

Organization → Team. Invite people, or let Directory Sync add them as Members, then set each role: Owner, Admin, Member or Viewer. Members can change policies and keys; Viewers can only look.

• One project only: add the person as a Viewer, then give them a higher role in that project’s Settings → Access. A project role can raise access, never lower it.
• Only admins edit policies: on Settings → Security, turn on Only admins can edit policies in the Policy editing card. Everyone can still read them.
• Restrict where people sign in from: the IP Allowlist card on the same page (needs IP allowlisting on your plan).

Detail: Organizations and teams, project-level access, who can change policies.

​

3. Author the policy

Policy belongs to a project: each application, and your Shadow AI fleet, is one. Open the project, then Guardrails. Lightest change first:

1. Built-in Detectors tab: pick a strictness level (Strict, Moderate, Permissive), then switch single checks on or off and choose which kinds of PII to catch. Policy presets.
2. Warn before you block: give Prompt Injection or Toxicity a warn threshold below its block threshold. Scores in between are allowed and recorded as flagged. Warn and block thresholds.
3. Policies tab → Create policy for your own rules: a word list, a codename, an identifier, each with an action of block, redact, flag or allow. Custom rules.
4. A boundary you can only describe (“nothing about unreleased products”): a policy of type LLM Guard or Topic Filter, with the rule written as a sentence. It adds time and cost to every scan, so use a rule from step 3 when one will do. LLM Guard.
5. One false positive: open the event and create a Suppression for that rule. Suppressions.

Steps 3 and 4 need custom policies on your plan. A saved change applies to the next scan, and reaches every Shadow AI device within about a minute (When a policy change takes effect). Protect → Policies lists every rule across all projects in one view. Your engineers can keep the same policies in version control instead (Policy-as-code); that route needs code, this one does not.

​

4. Decide what is kept

• Organization-wide retention: Settings → Data Retention sets how many days request logs and security events are kept (needs custom retention on your plan; otherwise your plan’s default applies).
• Per project: Zero retention in the project’s Settings → Data stores no content preview at all for that project.

Detail: Data handling, Shadow AI retention.

​

5. Route alerts

An alert is a request that was blocked or flagged, or detected with high confidence (which events alert).

• Email: Settings → Notifications. Choose All Alerts, Critical Only or Disabled, and turn Threat Alerts on. This is per person: each admin sets their own.
• Slack, PagerDuty, Datadog, Splunk or any HTTPS endpoint: open the project → Settings → Alert delivery, and add a destination on the Alert destinations card, choosing its format. Each project routes its own alerts, so add destinations to every project that matters, including your Shadow AI fleet project. Every attempt is in the project’s delivery log.
• In the dashboard: Monitor → Alerts lists anomalies across all projects.

Webhook destinations need webhook alerts on your plan. Detail: Webhooks, SIEM export.

​

6. Send events to your SIEM

Two routes carry the same record; use both if you can.

• Push: an alert destination from step 5 in the Splunk HEC or generic JSON format, or a Microsoft Sentinel Logic App URL. Your SIEM verifies each delivery’s signature.
• Pull: Connect → API Keys → create a key and choose the kind SIEM export: read-only. Only admins are offered it. Your collector uses it to read every event, or only alerts, across the organization, and to backfill anything a push missed. Your SIEM team configures the collector; you only make the key.

Detail: SIEM export (Splunk, Sentinel, the event fields, and pulling with an export key).

​

7. Review the audit log

Organization → Audit Log records who changed what and when: sign-ins, member and role changes, API keys created, deleted or rate-limited, Suppressions, and other configuration changes. Filter by category, action, severity, actor and date, and export it for an auditor. Admins see every event in the organization; other members see only their own. What each request was decided is a different record: the project’s Interactions page, and Monitor → Activity across projects. Needs audit logs on your plan. Detail: Audit logs, including how to verify the log’s integrity chain.

​

Prove it works

Before you sign off, run the evaluation for what you are protecting. Each has pass/fail criteria and ends with a production-readiness checklist.

​

Next steps