Skip to main content

​
What are Security Policies?

Security policies are guardrails that protect sensitive data flowing through AI tools in your organization. They automatically detect, redact, or block content like personally identifiable information (PII), API keys, passwords, and restricted terms before it reaches an LLM. Dashboard: gateway.getunbound.ai/policies/security-policies

​
Available Guardrails

​
PII Detection

Detects personally identifiable information across 40+ identifier types — names, email addresses, and phone numbers, plus international identity documents such as passports, national ID cards, driver’s licenses, and tax numbers spanning the US, UK, EU, India, and Australia. Set an action for detected PII:
  • Block — Reject the request entirely
  • Audit — Log the detection but allow the request
Per-entity policy configuration is rolling out one type at a time — Credit Card Number is available to configure today, with more to follow.

​
Secrets Detection

Automatically identifies credentials — API keys, database connection strings, and cryptographic keys — in prompts and responses. Prevents accidental exposure of sensitive credentials to LLM providers.

​
Setting Up Security Policies

  1. Go to Security Policies in the Unbound dashboard
  2. Click Create Policy
  3. Enable the guardrails you want (PII, Secrets) and set an action for each
  4. Optionally scope the policy to specific user groups
  5. Save your configuration
Security policies are evaluated on each request as it’s made. When a guardrail is set to Block, the request is stopped before its content reaches the LLM provider.

​
Applying to Users

By default, a security policy with no user groups applies to everyone in your organization. To restrict a policy to specific teams, assign it to one or more user groups during creation or editing.

​
Managing via CLI

List and manage security policies from the terminal:

CLI Policy Management

Create and manage security policies from the terminal

Analytics

Review guardrail hits and security events in the dashboard

​
Account Access

Developers sign into Claude Code, Codex and Cursor with their own accounts. Your organization buys seats and signs terms against those plans, but the account a developer authenticates with is theirs to choose — and a personal account runs the same tool under consumer terms you never negotiated. An Account Access policy closes that gap: you name the accounts you sanction, and a session signed in with anything else is refused. Dashboard: Policies → Data → Account Access

​
What you restrict

Switch on each tool you want to gate, then give up to three allow-lists: Three rules govern how those lists behave, and all three catch people out:
  • An empty list places no restriction on that axis. Leave Plans empty and the policy doesn’t care which plan the account is on.
  • Organization IDs and email domains are alternatives — an account is accepted when either matches.
  • Ticking every named plan is not the same as leaving Plans empty. An account that reports no plan at all is still refused unless the list is empty.
A tool switched on with all three lists empty accepts every account. That’s a valid state, and the editor flags it with an Accepts every account badge so it doesn’t read as enforcing.

​
When more than one policy applies

  • A tool is gated if any applicable policy switches it on.
  • The account must satisfy every applicable policy. One refusal refuses the request, whatever another policy would have allowed.
  • A policy that restricts nothing permits everyone and never causes a refusal.
Leave user groups empty to apply org-wide, or scope the policy to specific groups.
Claude Cowork follows Claude Code. Cowork is the desktop surface of Claude Code and has no switch of its own — it is governed by whatever you set for Claude Code, so gating Claude Code gates Cowork too.

​
Blocked attempts

Every refusal is recorded, so a developer who is stopped is visible to you rather than silent. Review them org-wide under Analytics → Data → Account Access, or on a single policy’s own page. Each row carries when it happened, the tool, the Unbound user whose key was used, the account that was refused — its organization ID, email, email domain and plan — the device, and the reason. Reasons are: Organization not approved, Domain not allowed, Plan not allowed, Policy from another org, and Policy check failed.
Blocked-attempt records contain personal data — a work email address and, where the tool reports it, a hardware serial number. They are kept for as long as your organization exists; there is no automatic cleanup and no configurable retention window today.
Account Access is in Beta and may not be enabled for your organization. Admins create and change these policies; Analytics Viewers can read them and their blocked attempts. There is no webhook, Slack alert or export for a blocked attempt — the dashboard is the only place they appear.