Skip to main content

​
What are Security Policies?

Security policies are guardrails that protect sensitive data flowing through AI tools in your organization. Two guardrails ship today — PII and Secrets — and they detect personally identifiable information, API keys, passwords, connection strings and cryptographic keys before that content reaches a model. Dashboard: Policies → Data (gateway.getunbound.ai/policies/data-policies)
The Data section is enabled per organization. If you don’t see it under Policies, contact support.

​
Available Guardrails

​
PII Detection

PII detection is switched on per organization. If the create-policy form offers only Secrets, contact support to enable it.
A PII policy acts on Credit Card Number and Email Address. Set an action for the types you select:
  • Block — Reject the request entirely
  • Audit — Log the detection but allow the request
You also set a threshold: the guardrail acts only once N instances of PII are found in one request, chosen from 1 to 10 (1 — act on a single detection — is the default). The editor reads it back to you as “When [N] instance(s) of any PII are found”. Raise it when a single stray email address is not worth stopping a developer for.
Identifier types are being opened up for policy configuration one at a time. Credit Card Number and Email Address are available today, with more to follow — the create-policy form always shows the current set. A policy acts only on the types you select.

​
Secrets Detection

Identifies credentials in prompts across three categories — API Key (including OAuth access tokens and AWS keys), Database Connection String and Cryptographic Key. Unlike PII, Secrets covers all three categories unless you narrow it. Each detection is recorded against the policy, and can be set to block or audit.

​
Enforcement message

A guardrail set to Block carries an Enforcement Message — up to 500 characters, shown to the developer in place of the default wording at the moment they are stopped. It reaches Claude Code, Codex, Cursor, GitHub Copilot and Pi (Beta) when a prompt is submitted, and Augment Code, which has no prompt event, on MCP tool calls where tool-input checking is on for your organization. An Audit guardrail has no message.

​
Setting Up Security Policies

  1. Go to Policies → Data 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.

​
When more than one guardrail policy applies

Security policies merge rather than compete. Every policy that reaches a developer contributes, and for each guardrail the most restrictive action wins — Block beats Audit. So a team policy auditing Secrets and an org-wide policy blocking Secrets resolve to Block for anyone in that team. Audit contributions are kept separately and all of them apply, so a request can be recorded against several audit policies at once.
Priority does not decide which action wins. On a Cost policy it picks the single winner; on a security policy the most restrictive action wins whatever the priority numbers say. It is not ignored entirely, though: where two policies set the same action on the same guardrail, the one with the lower priority number supplies that guardrail’s threshold, selected identifier types and enforcement message, and ties go to the policy created first.

​
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 accounts of their own choosing. Your organization buys seats and signs terms against those plans, but 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 → Usage → Account Access

​
What you restrict

Switch on each tool you want to gate, then give up to three allow-lists: Three rules govern those lists, 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 uses the Claude Code settings, and they may apply to only some Cowork sessions. Sanction Cowork with Organization IDs. A Cowork session reports its organization but no plan or email, so a listed organization is accepted only while Plans is empty — a Plans list refuses an account that reports no plan.

​
Blocked attempts

Every refusal is recorded, so a developer who is stopped is visible to you rather than silent. Open the policy from Policies → Usage → Account Access to review its refusals. 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.

​
Accounts in use

Separately from any policy, Unbound records every account a developer signs a coding tool into, so you can see what is in use before you decide what to sanction. Find it under Analytics → Usage → Account Usage: the email domains in play across your organization, and a searchable table of accounts with a column each for the user, the tool, the account, its plan and when it was first seen.
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. Each blocked attempt also fires the account_access.blocked webhook. There is no Slack alert or export for a blocked attempt.