jira · ingress
JIRA: Deny Sensitive Project Search and View
Keeps issues that belong to a configurable set of "sensitive" JIRA projects out of read access through the JIRA MCP server.
Atlassian bundle
Included policies (3)
jira · ingress
JIRA: Protect Sensitive Projects from Writes
Blocks write operations against issues that belong to a configurable set of "sensitive" JIRA projects.
About this bundle
A curated bundle of policies for Atlassian MCP servers (JIRA today; Confluence and Bitbucket planned). The goal is a sensible default posture for any organization fronting an Atlassian tool through the DTwo gateway: keep PII, credentials, and secrets from leaking out of issue and page content, and keep writes clean.
Included policies
| Policy | App | Direction | Purpose |
|---|---|---|---|
| redact-sensitive-info | jira | egress | Redact PII, credentials, and secrets from JIRA issue-view responses (issues, JQL search, comments, worklogs, remote links). Transform-only — never denies. |
| deny-view-search-sensitive-projects | jira | ingress | Deny direct views and explicit JQL searches of sensitive projects; silently filter generic searches to exclude them. |
| deny-write-sensitive-projects | jira | ingress | Deny write operations (edit/transition/comment/create/move/link, etc.) on issues in sensitive projects. |
Policy bodies live under
apps/. This page only links to them — see the top-level README for the rationale.
How bundle membership works
Bundle membership is declared in each policy's policy.md frontmatter (the policy lists bundles: ["atlassian"]). This page is a human-readable landing page; the generated manifest.json is the machine-readable source of truth. There is intentionally no separate bundle.json artifact — one source of metadata avoids drift.
The bundle's policies are designed to compose cleanly. The redaction policy is transform-only (default allow := true) and scoped narrowly to JIRA issue-view tools, so it never denies a call and never interferes with other policies on the same egress pipeline. The deny-view-search-sensitive-projects and deny-write-sensitive-projects policies run on the ingress pipeline (a separate direction) and only act on JIRA tools — the former on read tools, the latter on write tools — so none of the three collide. Together they give read-path access control, write-path protection for the same project set, and an egress redaction backstop. The two project-restriction policies each carry their own sensitive_projects set; keep them in sync.
What's intentionally not in the bundle
- Project / board allow-deny lists. These are tenant-specific (your project keys aren't ours) and belong in your private policy repo.
- Identity-scoped gates. IdP claims (
org_id,groups, etc.) vary by deployment. Add these as separate policies in your gateway. - Ingress write controls. Blocking secrets from being written into issues is a complementary concern; an ingress companion policy is planned.
Roadmap
- Confluence equivalents (
apps/confluence/redact-sensitive-info, …) once a stable Confluence MCP server lands in the catalog. - Bitbucket equivalents.
- An ingress policy that blocks credentials from being pasted into new JIRA issues and comments.