Confluence DLP: What Atlassian Guard Covers, and What It Misses
What “DLP” actually means
NIST’s Computer Security Resource Center defines data loss prevention as “a system’s ability to identify, monitor, and protect data in use, data in motion, and data at rest” — in plain terms, technology that watches sensitive content wherever it lives and applies controls (alerting, blocking, redaction, access restriction) to stop it from leaving where it’s supposed to stay. For a team asking “do we need DLP for Confluence,” the honest first answer is: Confluence doesn’t have it built in. Atlassian Guard does — and Guard is a separate product.
A separate product, a separate bill
Atlassian Guard ships in two tiers. Guard Standard covers single sign-on, user provisioning, and basic data security policies. Guard Premium is documented as “an add-on for Atlassian Guard Standard,” adding data classification, sensitive data detection, threat detection, and extended audit logs — and Atlassian states plainly that “Guard is billed differently compared to your existing app subscriptions.” If your organization hasn’t specifically purchased Guard Premium, there’s no native content scanning running against your Confluence or Jira content at all.
What the native scan actually looks for
Atlassian’s own support documentation describes content scanning in three buckets: it monitors for “credentials, financial data, and identity data” being added to Confluence pages and Jira issues. Independent analysis of the feature puts a finer point on it: roughly ten specific out-of-the-box detectors — Atlassian API tokens, AWS access keys, passwords, SSNs, credit card numbers, bank account numbers, JSON web tokens, and bitcoin addresses. That’s a real, working baseline. It’s also a fraction of the credential formats an active engineering org actually generates — Stripe keys, database connection strings, private keys, GCP service account JSON, provider-specific tokens for dozens of SaaS tools, none of which appear in that list.
| Content surface | Guard Premium (native) | Dedicated scanner |
|---|---|---|
| Confluence pages | Covered | Covered |
| Confluence comments | Not covered | Covered |
| Jira issues | Not covered | Covered |
| Jira comments | Not covered | Covered |
Source: Atlassian’s own documentation + independent analysis, 2026.
The gap that matters most: where it actually looks
Detector count is one axis. Content surface is the more consequential one. The same independent analysis states that Guard’s content scanning “is limited to Confluence page and blog post bodies and titles,” and that “comments and collaborative discussions, space descriptions and labels, and most of Jira’s content environment” fall outside it. That’s not a small gap — comments are where a lot of real leaks happen in practice, because they’re where people paste a connection string while debugging, or a token while asking a teammate for help, in the middle of an unplanned conversation rather than a written page. A scanner that only watches the polished, authored content and misses the conversational content around it is watching the wrong half of the surface.
When native Guard is genuinely enough
To be fair to it: if what you need is organization-wide data classification — labeling content Public, Internal, Confidential, Restricted and building governance policy on top of those labels — Guard Premium is a real, purpose-built tool for that, and if you’re already paying for it, it’s a legitimate baseline layer. The gap specifically opens up around credential-shaped content in comments, Jira issues, and formats outside its built-in list — not around classification and governance broadly.
Closing the gap
Secret Sentinel is scoped specifically to the surface Guard’s native scan documents as out of range: it scans Confluence pages and comments, and Jira issues and comments, for 50+ specific credential types — built on the open-source secretlint engine rather than a fixed ten-pattern list — and redacts what it finds in place. It doesn’t require a Guard Premium subscription and runs entirely on Atlassian Forge, so nothing leaves your instance either way. The two aren’t competing for the same job: Guard Premium governs and classifies; a dedicated scanner watches the specific surface — comments, issue descriptions, the unplanned conversation — where credentials actually end up.
Frequently asked questions
Does Confluence have DLP built in?
Not by default. Sensitive-data scanning and classification live in Atlassian Guard Premium — a separate product with its own subscription, billed differently from your Confluence or Jira plan, not a feature included in Confluence itself.
What does Atlassian Guard's native content scanning actually detect?
Atlassian's own documentation groups detections into three categories — credentials, financial data, and identity data. Independent analysis of the feature counts roughly ten specific out-of-the-box detectors within those categories, covering things like Atlassian API tokens, AWS access keys, passwords, SSNs, credit card numbers, and JWTs.
What's the biggest coverage gap in native Guard scanning?
Content scope. Guard's content scanning covers Confluence page and blog post bodies and titles. Comments, space descriptions and labels, and most of Jira's content are outside that scan — which matters because a large share of real credential leaks happen in comments and issue descriptions, not page bodies.
Do I need a dedicated scanner if I already pay for Atlassian Guard Premium?
It depends what you need it for. Guard Premium is a real baseline for organization-wide data classification and governance policy. If your risk specifically involves credentials landing in comments, Jira issues, or beyond roughly ten built-in patterns, that's outside its documented scope and needs a purpose-built scanner alongside it.