Confluence data classification without Guard: Sentinel Vault 6 levels from Assets
Gabriela Perdum
Author
8 min readOctober 3, 2026
Key takeaways
Creating classification levels in Atlassian Administration lists Atlassian Guard Premium under Who can do this?, and Guard Premium was $8.18 per user per month on 2 October 2026. A Confluence Premium site without Guard has no data classification at all.
Sentinel Vault 6 shows Confluence's own levels when your site has published ones, and uses its own levels (Public, Internal, Confidential, Restricted by default, up to 8) when it doesn't. A site admin can also import the levels from an object type in Jira Service Management Assets.
Classification is off until a site admin turns it on. On Sentinel Vault's own levels, raising a page's level is one pick and lowering it needs a reason, which is kept in the page's activity.
The level is a label and an audit trail, not a policy. Guard Premium can control what people do based on the level; Sentinel Vault doesn't.
On sites that use Confluence's own levels, the reason prompt currently checks the order the wrong way round. Until that's fixed, treat the reason rule as a feature of Sentinel Vault's own levels.
Sentinel Vault is a Confluence Cloud app that seals files and page sections, and version 6 gives every page a data classification level whether or not you pay for Atlassian Guard Premium. In January 2025 an admin called Adam asked the Atlassian Community a very reasonable question. He'd found Atlassian's article on setting a default classification level for a space, gone to his space settings, and the setting simply wasn't there. The answer he accepted: Confluence data classification requires an Atlassian Guard Premium subscription.
Guard Premium was $8.18 per user per month when I checked Atlassian's pricing page on 2 October 2026. Sentinel Vault is free for up to 10 users and $1,000 a year at 100 users on its Marketplace listing. Those two prices don't buy the same thing, though, and I'll be honest about the difference further down. The version on the Marketplace today is 6.6.0.
Where is data classification? It needs Atlassian Guard Premium
Adam isn't the only one who hit this. A few months earlier John asked why "Data Classification isn't an option in the side bar under Security". He was an org admin on Confluence Premium. No Guard. An Atlassian team member replied that data classification "is an feature that is exclusive to our Guard Premium offering" (typo theirs, and fair enough).
It's an easy trap because the Confluence pages that show you how to classify content, or set a space default, don't name a plan at all. You have to go to Atlassian's page on creating a classification level. Its "Who can do this?" box says Organization admin and Atlassian Guard Premium. Those levels are org-wide too: you get up to 10, shared by Confluence, Jira and Jira Service Management.
So if you're on Confluence Standard or Premium without Guard, there's no classification to switch on. That's the gap Sentinel Vault fills.
Here's the rule it follows. Every time it loads, the app asks Confluence for its published classification levels. If it gets some back, it uses them. If it gets none, it uses its own. You don't pick a mode, and nobody has to tell it which plan you're on. It also means that if your organisation publishes Guard levels later, Sentinel Vault moves to them by itself.
The app's own scheme starts with four levels: Public, Internal, Confidential and Restricted. You can rename them, recolour them, or go up to eight. They're stored by the app and set as a content property on each page.
Whichever scheme you're on, classification is off until a site admin turns it on. Go to Confluence administration, open Sentinel Vault — Site settings, pick the Classification tab, and flip the switch at the top.
Create classification levels from Jira Service Management Assets
This is the bit that arrived with 6.0.0 on 19 September. Lots of organisations already keep their information classification policy somewhere, and if your somewhere is Jira Service Management Assets, you can import the levels from it instead of typing them in again.
It lives on that same Classification tab. Only a site admin sees the section, and it shows up when the app is using its own scheme. The steps go like this:
Select Choose an Assets object type… in the section called Levels from JSM Assets.
Pick the object schema, then the object type that holds your levels.
Map the attributes for Rank, Colour and Description. The app guesses them from the attribute names, so check its guess.
Select Preview the levels and read the list.
Select the Import button. It names how many levels it read and warns that it replaces the current list.
The object's label becomes the level's name. After that it's static. Nothing syncs on a schedule; when your Assets objects change, you press Re-import now. Unlink keeps the levels you already have.
Two things I'd want to know before trying it. First, it's read-only: the console says "nothing runs in the background and nothing is written to Assets", and every call runs as you, the site admin, from that screen. Second, the app has to be installed on your site's Jira as well as Confluence, because that's where Assets lives. If it isn't, the first step fails instead of listing your schemas, with an error that doesn't say why. That's your cue to install it on Jira.
Assets now comes with Service Collection Standard, Premium and Enterprise. Standard includes 5,000 objects, according to Atlassian's Service Collection pricing page, so a short list of classification levels fits easily. If the app's own message about a missing Assets workspace names a different plan, go by Atlassian's page. That wording is ours, it's out of date, and I've passed it to Mihai.
No screenshot of this one, sorry. Both of our demo sites have Guard levels published, and when a site does, the Assets section is hidden on purpose. More on that below.
Set a default classification level for each space
Any page you don't classify by hand takes its space's default, so that's where most of the work happens. A page's own level wins, then the space default, then nothing, which shows as "Unclassified".
There are two places to set it. In Site settings, Classification, the Space defaults table lists every space; you can select several and set them in one go, and pages that already have their own level keep it. Or a space admin can open the Sentinel Vault page in the space and pick a "Default level for this space". On Sentinel Vault's own levels it saves as soon as you pick, unless you're lowering it, which asks for a reason.
One catch that isn't obvious. A site admin can always set space defaults. A space admin can do it only while the site setting "Allow space admins to force-unseal" is on. It's on by default, but if your site turned it off, the space defaults are back with the site admins.
A space can also opt out of classification. It can't opt in while the site has it switched off.
Classify content: raise a level in one action, lower it with a reason
Once it's on, every page shows its level in two places: a chip under the title, and a banner at the top. Click the chip and you get the page details, where anyone who can edit the page can change the level.
Version 6.4.0, on 30 September, made raising and lowering behave differently. On Sentinel Vault's own levels, raising a page from Internal to Confidential saves on the pick. Lowering it, clearing it, or switching to a lower space default asks you why first. (If your site uses Guard levels, read the Guard section further down before you rely on this.) The prompt says the reason "is kept in the page's activity". The server enforces it too, so a script can't skip the reason.
Space admins can read those changes in the Activity tab on the space's Sentinel Vault page, filter them, and export them as CSV. The records don't expire. For an audit, I find that more useful than the level itself: you can see who decided a page was less sensitive, when, and what they said.
Now the honest part. The level is a label and a record. It doesn't stop anyone viewing, exporting or copying a page. Guard Premium is different there: Atlassian's pricing page says admins can set policies "to control user interaction based on data classification level". If that's what your auditors are asking for, you need Guard. If they're asking whether every page carries a classification and who changed it, Sentinel Vault answers that.
Lock attachments in Confluence Cloud with a seal and an authenticator code
Classification tells people how careful to be. Sealing is what actually protects a file.
In the page's ⋯ menu there's Seal attachments…. Once a file is sealed, someone else's overwrite is restored to the sealed version, and a trashed file comes back. We wrote up why it restores instead of blocking back in August. You can also seal part of a page with the Sentinel Vault Sealed Section macro.
For anything that changes a seal, you can ask for a second factor. Turn on "Sign seal actions with an authenticator code" and sealing, releasing, extending, force release, and approving, declining, giving or revoking edit access all ask for the current code from an authenticator app. People set that up on their My work page, and until they do, the app refuses those actions for them. Five wrong codes lock that person's signing for 15 minutes.
The Protection card on 6.6.0. Notice that the authenticator switch is on here but its effective default is Off, so you choose it. Captured on our demo site's production install.
Two paths aren't signed yet: a section sealed by inserting the macro in the editor and publishing, and jobs that come in through the REST API. If you rely on signing for an audit, keep that in mind.
With Atlassian Guard: Sentinel Vault reads Confluence's own levels
If your organisation does have Guard Premium and published levels, Sentinel Vault doesn't compete with them. It shows them read-only, and its own level editor and the Assets import go away. Levels on those sites are managed where Atlassian manages them, in Atlassian Administration.
Our demo site has Guard levels published, so the scheme reads NATIVE and the levels are read-only. Classification is still off until a site admin flips the switch. Captured on 6.6.0, production install.
That screenshot shows two things. The switch is off, because classification starts off everywhere. That includes sites that had classification before the switch existed: the update turned it off there too, and every level they'd set is kept until a site admin turns it back on. And look at the ranks. Atlassian numbers its levels from 1, Highly restricted, to 4, Public.
That numbering is where I have to own a mistake. Sentinel Vault's own levels count the other way, 1 for the least sensitive. On sites that use Confluence's levels, the reason prompt reads the ranks as if they were ours, so it asks for a reason when you raise a page and not when you lower it. We found it while checking the code for this post, and I've passed it to Mihai, who built the app. Until the fix is out, treat the reason rule as a feature of Sentinel Vault's own levels.
Who should install it
If you're on Confluence without Guard and someone has asked you to classify pages, Sentinel Vault gets you there with levels you define, or the ones already sitting in Assets, plus a record of every change. If you need classification to enforce something, it won't. That's Guard's job.
The newest release, 6.6.0 from 2 October, is about something else again: your settings, seals and classification survive an uninstall through backup, restore, export and import. The Marketplace listing has the 6.6.0 notes under Version information. And if you're still working out which Guard features you'd actually use, I went through what Atlassian's data security policies need Guard for last week.
