Skip to main content
Security Context is information about your organisation that Oplane considers in every analysis, such as your tech stack, how identity works across your services, and the compliance obligations you have to meet. For guidance that applies only to some changes, see Policies.
You need the Org Admin role to add, edit, reorder, or delete Security Context items. See Roles and permissions.

​
How Security Context is applied

Security Context is organisation-wide. As soon as you save an item, Oplane uses it in every threat model it 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. Oplane uses every item every time, in the order they’re listed. You can’t limit an item to a workspace or repository.
Everything in Security Context becomes part of what Oplane reads in every analysis, next to the code change itself. The amount Oplane can take in at once is limited, so long or contradictory Security Context makes every review worse.
Keep items short, specific, and true for the whole organisation:
  • Don’t paste whole documents. A full security policy or standards document leaves less room for the change and dilutes the instructions that matter. Use a few sentences per item.
  • Keep items consistent and non-contradicting. If one item says all services use cookie sessions and another says no service may use cookies, findings about sessions become unreliable.
  • Keep facts organisation-wide. If something is only true for some repositories, say which ones in the item, or use a policy instead.
Review the list when your environment changes, so old facts don’t keep shaping reviews.

​
Examples

Each example shows the Title and Content you would enter, and then what the item changes in your reviews. Replace the details with your own.
Title: PlatformContent:
All services run on AWS in containers on EKS. Secrets come from AWS Secrets Manager at runtime and are never stored in environment files or the repository. Public traffic enters only through the API gateway.
What this changes: Oplane knows where your trust boundaries are and how secrets should be handled, so it raises findings when a change reads secrets from a file or exposes a service outside the gateway.
Title: AuthenticationContent:
Users sign in through our identity provider using OIDC. The API gateway validates tokens and passes the user ID to backend services in a signed header. Backend services must not accept user identity from any other source.
What this changes: Oplane flags changes that read the user’s identity from an unsigned header or let a request reach a backend service without going through the gateway.
Title: ComplianceContent:
We process health data of EU residents. Personal data must stay in EU regions. Every access to patient records must be logged with the user ID and purpose.
What this changes: Oplane checks changes against these obligations, for example a new integration that sends personal data to a region outside the EU, or a new endpoint that reads patient records without logging the access.
Title: Data classificationContent:
We classify data as Public, Internal, Confidential, or Restricted. Credentials, health records, and payment card numbers are Restricted. Restricted data must be encrypted at rest with our own keys and must never be written to logs, analytics events, or error messages.
What this changes: Oplane knows which data needs the strictest handling, so it flags changes that log a Restricted field, send it to an analytics tool, or store it without encryption.

​
Draft items with your coding agent

Your coding agent is good at the hardest part of Security Context, which is keeping it short. It 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. Ask it to condense your architecture notes or compliance documents into a few short items, and to check them against each other and against your policies. For example:
If you’re an Org Admin, your agent can read your policies through MCP. It can’t read or change Security Context, so add the drafted items in Org Settings yourself.

​
Add an item in Org Settings

  1. Open the organisation switcher in the top-right corner, click Org Settings, and find Security Context on the General tab.
  2. Click Add item, enter a Title and Content, and click Add.
To change an item, click its edit icon. To remove it, click its delete icon. To change the order, drag an item by its handle. 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 Security Context or policies from any of those organisations. Oplane does this so one organisation’s settings never shape a review that another organisation also sees. The review still runs, without organisation-specific settings. To make sure your settings always apply to your repositories, ask Oplane to claim your GitHub organisation or GitLab group for your Oplane organisation. After a claim, only your organisation’s workspaces can connect its repositories. Claims are set up by Oplane, so contact your Oplane representative or support@oplane.io. See Namespace claims.