Policies overview

Overview

Govern → Policies & rules → Policies is one scrolling page. It shows everything Shield360 can enforce, in four sections:

1. Sensitive data: what happens when a prompt, file or tool call holds sensitive data.
2. AI tools: which AI tools people may use, your own AI sites, and approved models.
3. Coding agents: what the coding-agent hooks enforce, including prompt injection.
4. Sequence policies: rules over the order of what agents do, such as reading a secret and then sending data out.

Violations, the record of every decision these policies made, has its own page: select Violations at the top of the Policies page (see Violations). Older links to ?tab=violations and the other tabs still work and take you to the right place.

This page follows the in-app page section by section. Each policy has a stable heading you can link to.

How the page works

What can block right now

The strip at the top lists every saved setting whose effective mode is Block, across all four sections, for the scope you are editing. Select an item to jump to it. When nothing blocks, the strip says Nothing blocks — everything warns. Use it before a rollout to check what developers and employees could be stopped by.

One set of modes

Every setting uses the same words:

Mode	Meaning
Off	Not checked, or allowed. An allowed AI tool reads as Off.
Warn	The action goes ahead. Shield360 records it, and where it can, shows a notice.
Mask	The sensitive value is replaced before it is sent. Only the browser and the AI proxy can mask. Coding agents treat Mask as Block.
Block	The action is stopped before it happens, where the tool lets Shield360 stop it.

Each row shows its effective mode: the value that applies after inheritance and defaults. At the environment scope, a row also says whether it is Inherited from the organization or Overridden here.

One Save

Changes on the page are drafts until you select Save…. Shield360 then shows a summary of every change, for example Sequence: Secret read, then data sent out → Warn, and saves each section through its own API. If one section fails, the others are still saved, and the failed section keeps its changes so you can try again. Permissions, change control and the audit log work exactly as before. Custom sequence policies are created and edited in their own editor, which saves on its own (see Create a custom sequence policy).

Organization default and environment overrides

The Editing switch chooses whether you edit the organization’s default or the current environment’s overrides of it. It applies to the Sensitive data, AI tools and Coding agents sections (see Enforcement policy). Sequence policies and allowed destinations always apply to the current project and environment.

Sensitive data

Purpose. Checks prompts, uploaded files and coding-agent tool calls for kinds of sensitive data: API keys, private keys, passwords, connection strings, Social Security numbers, payment cards, access tokens, cloud credentials, email addresses, phone numbers, IBANs and IP addresses. Set a default and per-kind actions for all channels, and override them per channel (browser, AI proxy, coding agents).

Modes. Off ignores the data. Warn lets it through and records it. Mask replaces the value (browser and AI proxy). Block stops the prompt or call.

Examples. Someone pastes a customer’s card number into an AI chat. An agent runs a command with a database password in it.

False positives and tuning. Test card numbers, sample keys in documentation and long random IDs can match. Start with Warn, look at the violations, then block the kinds that matter. Coding agents default to Off for email, phone, IBAN and IP address, because code is full of them.

What people see. A notice in the browser, an error from the proxy, or a refusal in the coding agent. Each names the kind of data, never the value.

Your own kinds of data

Purpose. Adds kinds of sensitive data the built-in list does not cover: a project codename, an employee or customer ID format, a list of client names. Each kind you add becomes a row of the table above, with the same actions per channel as a built-in kind. Add, edit and remove them under Your own kinds of data, below the table.

Matching. A kind matches by keywords or by formats:

• Keywords are whole words or phrases, matched in either case. Falcon matches falcon but not falconry. Up to 200 per kind.
• Formats describe a fixed shape, one character per position: # is any digit, @ any letter, * any letter or digit, and any other character stands for itself (put \ before #, @, * or \ to mean that character). EMP-###### matches EMP-004211. A format needs at least three of #, @ or *, and one made only of them needs at least six. Up to 20 per kind.

A match never starts or ends inside a longer word or number, so EMP-###### does not match EMP-0042117. There are no free-form regular expressions: every client checks prompts as they are typed, and a pattern that backtracks can freeze a browser tab.

Examples. Employee ID by the format EMP-######, warned in the browser and blocked for coding agents. Client names by keywords, masked in the browser and the AI proxy.

False positives and tuning. Keywords that are also ordinary words, and short formats that fit other numbers. Use Try it in the editor: paste sample text and see what the kind finds before you save. Up to 50 kinds per organisation; an environment can replace the whole list as an override.

How. Under Your own kinds of data, enter a Name, choose Match by Keywords or Formats, enter the values one per line, check them with Try it, and select Add kind. The kind is a draft until you save the page with Save…. Then set what each channel does with it in its row of the table. See Add your own kind of data for every rule a name, keyword and format must follow.

What people see. The kind’s name in the notice or refusal, never the value.

Send anyway

Purpose. Lets a person who was warned send anyway after giving a reason. Applies to the browser and the AI proxy. On shows a Send anyway button with a reason field; Off makes the warning final. The reason is recorded with the violation.

Fail closed

Purpose. Decides what happens when a browser, proxy or computer cannot load the policy. On blocks sensitive actions until the policy loads. Off lets them through and records that the policy was unavailable. A short network outage can block work while this is on, so turn it on only where blocking matters more than availability.

File uploads

Purpose. Checks the text of files uploaded to AI sites with the browser’s sensitive-data actions, and decides what happens to a file the browser cannot read (an encrypted archive or a scanned PDF): Off lets it through, Warn records it, Block stops the upload. Images and scans that hold nothing sensitive are the usual false alarms for Block.

AI tools

Purpose. Decides which AI tools people may open or call, per tool, with a default for every other AI tool. The browser extension and the AI proxy enforce it. Tools Shield360 cannot enforce on are still reported (shadow AI).

Modes. Off allows the tool, and it is still reported. Warn shows a notice and records the visit. Block stops the page or the request.

Examples. Block a consumer AI chat and allow the approved one.

False positives and tuning. Sites that embed an AI widget, and tools approved for only one team. Use environment overrides for team-specific rules.

What people see. A page from the browser extension, or an error from the AI proxy, saying the tool is not allowed.

Your own AI sites

Purpose. Adds your own AI sites (internal portals and unlisted public sites) to what the browser extension covers. Each site gets its own Off, Warn or Block. A host that also serves non-AI pages can cause false alarms; list the most specific host name. See Add your own AI site for the steps and what an entry may be.

Company AI accounts only

Purpose. Decides what happens when ChatGPT, Claude, consumer Copilot, Claude Code or Codex is signed in to a personal account or another organisation’s instead of the company’s. Off allows any account, Warn shows a notice and records it, and Block stops the prompt and adds the vendor’s tenant restriction header for your approved Claude organisations and ChatGPT workspaces. A company Team workspace nobody has added to Settings → Data collection → AI account settings is the usual false alarm. See Enforcement policy.

Approved models

Purpose. Decides what the AI proxy does with a model or provider outside the environment’s approved list. Off lets every model through, Warn records it, and Block refuses the request. Model aliases and dated versions missing from the list are the usual false alarms; add them to the approved list.

Coding agents

Purpose. Controls what the Shield360 hooks in Claude Code, Cursor, Codex, GitHub Copilot, Gemini CLI, Windsurf and OpenCode enforce beyond sensitive data. Each setting below has its own mode.

Secret files

Purpose. Also checks files a coding agent reads, not only its prompts and commands, with the coding-agent sensitive-data actions. On checks file reads; Off checks prompts and commands only. Test fixtures and sample data are the usual false alarms.

Expensive patterns

Purpose. Flags edits that add patterns known to raise AI costs, such as a model call inside a loop. Off ignores them, Warn records them, and Block refuses the edit. Batch jobs that are meant to call the model per item can trip it; keep it on Warn there.

Edit rules

Purpose. Lists paths a coding agent may not change, or is warned about, optionally only when edits are auto-accepted. Each rule is Warn or Block and carries a reason the agent is shown. Broad patterns can also match generated files; keep rules specific.

Prompt injection in coding agents

Purpose. Looks for prompt injection in what coding agents read: prompts, tool results and files. Off ignores it. Warn records it and tells the agent to treat the text as data. Block refuses the call that carried it. Security documentation and test files that quote injection examples are the usual false alarms. See Prompt-injection protection.

Prompt injection in the MCP gateway

Purpose. Looks for prompt injection in tool results that pass through the MCP gateway. Off ignores it. Warn records it. Block withholds the result from the agent, which gets an error instead.

Model check for prompt injection

Purpose. Asks a model about borderline content the pattern checks were unsure of. On sends borderline text for a second opinion, which lowers false alarms and adds a little latency. Off uses the patterns only.

Sequence policies

Purpose. Rules over the order of what agents do. A single step is usually harmless; the sequence is the risk. They run live in coding-agent hooks and the MCP gateway, and in an after-the-fact scan. See Sequence policies for the policy language and coverage.

Modes. Off ignores the rule. Warn lets the call go ahead and records a violation. Block refuses the call before it runs. Every blocked attempt is recorded.

Secret then egress

Purpose. Stops data going to an outside destination after an agent reads a secret: .env, SSH keys, cloud credentials, *.pem, a keychain, or a credential command such as gh auth token.

Modes. Block refuses the first call to an outside destination after the read, and every retry, until the developer approves or 20 more events pass. Warn records it.

Example. An agent reads ~/.aws/credentials, then posts to an unknown webhook.

False positives and tuning. Pushes and API calls to your own sites. Add them to allowed destinations, with a path for shared hosts (github.com/your-org). Test fixtures (test/, testdata/, fixtures/, *.test.*) are not secrets, but home-directory credentials always are. Claude Code subagents are tracked separately, so one subagent’s read does not hold back the others.

What the developer sees. Data was sent to an outside destination after reading .env.local in services/api, with a note that replying “go ahead” allows the call. The message names the file or command, never its content.

Destructive without confirmation

Purpose. Catches destructive commands (rm -rf, force push, DROP TABLE, terraform destroy, kubectl delete) that nobody asked for or confirmed in the six events before.

Modes. Block refuses the command; a reply such as “yes” or “go ahead” lets the agent run it. Warn records it.

False positives and tuning. A clean-up the developer asked for long before the command ran. Ask again, or confirm, right before it.

Taint to external

Purpose. Follows data from one tool’s result into a later call to an outside destination, by keyed fingerprint, never by content.

False positives and tuning. Common lines, such as license headers copied into an issue. Allow the destinations your agents are meant to write to.

Excessive writes

Purpose. Notices an agent making more than 25 changes without a user turn. Block refuses further writes until the developer replies. Large refactors the developer asked for are the usual false alarm; a reply resets the count.

Privilege change

Purpose. Flags privilege changes: sudo, chmod 777, IAM and role bindings, adding collaborators or members. Where agents legitimately use sudo, keep it on Warn.

Injection then sensitive

Purpose. Stops a sensitive call (sending data, deleting, changing privileges, reading a secret) after prompt injection was found in something the agent read. Pages that discuss prompt injection, followed by unrelated work, are the usual false alarm.

Custom sequence policies

Purpose. Your own rules in the policy language, tested against fixtures before they are saved. Start every new rule on Warn and watch the violations before you block.

How. Under Your policies, select New policy, write the rule and its test fixtures, select Test, then Save. The editor saves on its own, not with the page’s Save…. For the full walkthrough, a worked example and the API, see Create a custom sequence policy. The language itself is described in Sequence policies.

Allowed destinations

Purpose. Where data may go without counting as leaving, for the sequence policies. One entry per line:

• example.com covers the domain and its subdomains.
• github.com/your-org covers only that organization’s repositories on GitHub, not the rest of GitHub or gists.
• mcp:<server> covers an MCP server or gateway service.

A typical organization adds its GitHub organization and its own application, for example github.com/your-org and app.your-company.com. Avoid all of github.com: it also allows gists and anyone else’s repositories.

Getting unblocked

This section is for developers whose coding agent or browser was stopped by a policy.

What the block message means

A block message names the policy and what triggered it, for example:

Shield360 blocked this tool call: it breaks your organisation’s policy “Secret read, then data sent out” (Data was sent to an outside destination after reading .env.local in services/api).

• The policy name tells you which section of this page applies.
• The part in parentheses says what triggered it: a file name and folder, a command, or a kind of sensitive data. It never shows the secret or the data itself.

Approve it in the chat

Some policies end when you approve the action in your reply to the agent: Secret then egress and Destructive without confirmation. If you expect the call, reply “go ahead”, “yes” or “try again”, and the agent can retry. The block message says so when this applies.

Ask an admin

If the block is wrong for your work (your own GitHub organization, your own application, a test fixture that is flagged), ask an admin to:

1. Add the destination to allowed destinations, or
2. Set the policy to Warn for your environment, or
3. Adjust the specific setting, using the row’s Learn more notes on false alarms.

Admins can see the exact event on the Violations page, linked from Govern → Policies & rules → Policies.

The per-machine override

SHIELD360_AGENT_SEQUENCE=off|warn|block overrides the mode of every sequence policy on one computer. Use it to unblock yourself while an admin fixes the policy, for example:

export SHIELD360_AGENT_SEQUENCE=warn

Violations are still recorded in Warn. Your organization may treat a machine running with off as out of policy, so tell your admin when you use it, and remove it once the policy is fixed.

Next steps

• Create custom policies and rules: every kind of rule you can write, with walkthroughs.
• Enforcement policy: organization defaults, environment overrides and the API.
• Sequence policies: the built-ins in detail and the policy language.
• Prompt-injection protection: how detection works.
• Violations: every decision, in one feed.