Skip to main content
A policy is a piece of your organisation’s security guidance that Oplane applies when a change is relevant to it, such as how your teams must encrypt data. For information Oplane should consider in every analysis, see Security Context.
You need the Org Admin role to create, edit, enable, disable, or delete policies. See Roles and permissions.

​
How policies are applied

Policies are organisation-wide. An enabled policy applies to every threat model Oplane generates in your organisation, across every workspace: reviews of pull requests and merge requests, repository scans, and threat models created from your coding agent with MCP. A policy is only used when it matches. Before generating a threat model, Oplane writes a description of the change, and a policy matches when any of its trigger keywords appears in that description. Keywords aren’t case-sensitive and match anywhere in a word, so token also matches tokenisation, and a short keyword like id matches almost everything. Pick words someone would use to describe the change, such as upload or password reset, rather than function or variable names. When a policy matches, Oplane takes its rule text into account when it generates security requirements. Oplane still raises findings outside your policies when a change calls for them.
A policy without trigger keywords never applies, even when it shows as enabled. Add at least one keyword to every policy.

​
Examples

A good policy covers one standard, names your own libraries and services, and doesn’t contradict your other policies or your Security Context. Replace the details with your own.
Title: Use the shared crypto libraryCategory: encryptionTrigger keywords: encrypt, decrypt, cipher, crypto, KMSRule text:
Encrypt and decrypt data only through the internal acme-crypto library. Don’t call cryptographic primitives directly. Keys come from AWS KMS and must never be hard-coded, logged, or stored in configuration files.
Why it’s written this way: encrypt also matches encryption and encrypted, so you don’t need every form of the word. The rule text names your own library, which Oplane can’t know without you.
Title: Verify incoming webhooksCategory: authenticationTrigger keywords: webhook, callback, inbound eventRule text:
Every endpoint that receives webhooks must verify the sender’s signature with the shared secret before parsing the payload, reject requests older than five minutes, and return the same error for every failed check.
Why it’s written this way: the rule text lists concrete checks that a change either does or doesn’t do.
Title: File upload handlingCategory: input_validationTrigger keywords: upload, attachment, multipartRule text:
Uploaded files go to the quarantine bucket and are scanned before any service reads them. Check the file type from its content, not its name. Limit uploads to 25 MB and never serve uploaded files from the application’s own domain.
Why it’s written this way: the policy covers one standard, so it only applies to changes that handle files. A policy that also covered logging would apply to many changes that don’t need it.

​
Write policies with your coding agent

The fastest way to write good policies is to ask your coding agent, if it’s connected to Oplane through MCP and you’re an Org Admin. Your agent already knows how your team works from your repositories, project instructions such as CLAUDE.md or AGENTS.md, its memory of earlier sessions, and documents you point it to. That makes it good at choosing the words your team uses to describe changes, which are the words that make trigger keywords match. You can ask it to turn an existing standard into one policy per rule, suggest keywords for a policy, or review your policies for overlaps, contradictions, and keywords that are too broad. For example:
Through MCP, a policy can also hold suggested vulnerability types, such as CWE-89, and a link to the document it comes from. The Policies tab doesn’t show these fields. See the policy tools in the MCP tool reference.
Policies apply to every review in your organisation, so read your agent’s drafts before you let it create them.

​
Create a policy in Org Settings

  1. Open the organisation switcher in the top-right corner, click Org Settings, and open the Policies tab.
  2. Click New policy, or Create your first policy if your organisation has none yet.
  3. Fill in Title, Category, Trigger keywords (press Enter after each, up to 20), and Rule text (up to 2,000 characters).
  4. Click Create policy. New policies are enabled.
To change a policy, open its menu and click Edit, Disable (or Enable), or Delete. A disabled policy stays in the list with a Disabled label and stops applying. Deleting can’t be undone. Changes apply to the next analysis, so existing threat models don’t change until they’re generated again, for example when a pull request gets new commits.

​
Organisations that share a repository

If workspaces in more than one Oplane organisation connect the same repository, reviews of that repository don’t use policies or Security Context from any of those organisations. The review still runs, without organisation-specific settings. To make sure your policies always apply to your repositories, ask Oplane to claim your GitHub organisation or GitLab group for your Oplane organisation. Claims are set up by Oplane, so contact your Oplane representative or support@oplane.io. See Namespace claims.