Exemptions
An exemption excludes one specific entity from a rule's results. The entity is still in your graph and the query still finds it, but the rule stops counting it: it is left out of the result totals the rule's condition is evaluated against, and it does not trigger any action the rule would otherwise have taken.
Use an exemption when a rule's query is right but keeps returning a result you have already looked at and decided is fine—a bastion host that is deliberately reachable from the internet, or a known test account the query will always match. Exempting it stops the rule alerting on that one entity while it goes on catching everything else, so you do not have to narrow the query or turn the rule off.
Exemptions are rolling out progressively and are not yet enabled for every account. If you do not see the Exempt action on your rule results, contact your JupiterOne account team.
What an exemption does
Exempting an entity has five effects:
- The entity is removed from the rule's results before they are counted, so it is not part of the totals the rule's condition is evaluated against.
- The rule takes no action on it. No alert, no notification, no Jira or ServiceNow ticket, no webhook.
- The entity remains in your graph, unchanged. An exemption is a statement about one rule, not about the asset.
- The exempted entities are kept and shown separately, so the set you excluded is always reviewable and downloadable.
- The change takes effect on the rule's next scheduled evaluation. Nothing re-evaluates at the moment you create the exemption.
Because exemptions apply at evaluation time, a rule that is currently alerting continues to alert until it next runs. To see the effect immediately, trigger the rule on demand.
An exemption applies to the whole rule, not to one query within it. If a rule runs three queries, exempting an entity removes it from all three. You cannot exempt an entity from a rule's finding query while still counting it in a supporting query.
Creating an exemption
You need permission to update the rule. Exempting is a change to the rule, not to the entity, so asset-write permission is not sufficient.
-
Navigate to Alerts and select the Rules tab, then open the rule.
-
Select the Evaluation history tab and choose the evaluation whose results you want to work from.
-
Expand the query whose results contain the entities to exempt.
-
Select the rows you want to exempt, then click Exempt.
-
Complete the exemption:
- Justification: Required. Why these entities do not count. This is the record other people read later, so write it for them.
- Reason: One of Risk accepted, Not applicable, False positive, or Compensating control.
- Expires on: Optional. Leave it empty for an exemption that never expires.
-
Click Exempt entities.
The justification, reason, and expiry apply to the entire selection. Selecting twelve rows and exempting them files one decision covering twelve entities, rather than twelve separate decisions.
A selected row is skipped if it does not name exactly one entity. If some of your selection is skipped for that reason, the dialog tells you how many before you confirm.
A rule can hold at most 100 unexpired exemptions, and you can exempt at most 100 entities at a time. Exempting beyond that is refused, and the message tells you how many the rule already has.
Expired exemptions do not count toward the limit, and re-exempting an entity that is already exempt replaces its existing exemption rather than using up another slot.
If you find yourself near the limit, that is usually a sign the query is matching more than it should. Narrowing the query is a better answer than exempting a hundred entities one by one.
Which rules can accept exemptions
Not every rule can take exemptions, and this is the single most important thing to understand about the feature.
An exemption identifies one individual entity. Some queries do not return individual entities—they return counts, deduplicated values, or a graph—so there is nothing for an exemption to attach to. When a rule runs such a query, the Exempt action appears but is disabled, and hovering it explains why.
This is a property of the query the rule runs. It is not a permission problem, not a licensing limit, and not a defect. Rewriting the query so it returns entities makes the rule exemptable.
Query shapes that cannot accept exemptions
| The rule's query | Why it cannot accept exemptions |
|---|---|
Aggregates its results, with count(), avg(), sum(), or similar | A row is a summary of many entities, so no single entity can be excluded from it. |
Uses FIND UNIQUE | A row stands for every entity sharing that value, not for one of them. |
Uses RETURN TREE | A graph result has no rows. Removing vertices from it would leave relationships pointing at nothing. |
Has a RETURN that names only values, and no entity | The results carry property values, with no entity identity to key an exemption on. |
| Has no query at all | There are no results. |
A rule can also be refused temporarily when JupiterOne cannot determine what its query returns—because the saved question behind it could not be loaded, or the query itself could not be read. The tooltip says which.
A rule can accept exemptions only when every query it runs can. A rule that mixes an entity-returning query with an aggregating one cannot take exemptions, because an exemption would apply to the first query and silently miss the second—leaving a condition that reads the second query's total still counting the entity you exempted.
Entities a query traverses but does not return
An exemption can only target entities the query's RETURN actually names.
Consider FIND Host THAT HAS UserAccount RETURN Host.displayName, Host._id. The query traverses to user accounts in order to select hosts, but only hosts come back in the results. You can exempt a host from this rule. You cannot exempt a user account from it, because no user account appears in the results. To exempt user accounts, the query has to return them.
Reviewing what you exempted
Under each query's results in Evaluation history, an Exempted results section lists the entities that evaluation held back, with a count and its own download. The two halves of the run are recorded together, so you can always see what a rule counted alongside what it did not.
This section reports what happened on that particular run. Revoking an exemption does not rewrite the runs it already applied to, and past evaluations are never edited.
Very large result sets are not rendered in the table. Download the exempted set instead.
The justification, reason, author, and expiry belong to the exemption rather than to any one run, so they are not shown here. They are on the rule's Exemptions tab.
Downloading each set separately
The included results and the exempted results each have their own download, in both CSV and JSON.
Managing a rule's exemptions
The Exemptions tab on the rule detail page, alongside Evaluation history and Relationships, lists everything currently exempt from that rule.
Exemptions are grouped into the decisions that created them, newest first. Each decision shows its reason, justification, who filed it, when, and its expiry, together with what it covers—for example, "2 entities · 1 active, 1 orphaned". Expand a decision to see the individual entities, each with a Status of Active, Expired, or Orphaned.
Expired and orphaned exemptions are listed alongside active ones rather than being hidden. An exemption that quietly disappeared when it stopped applying would leave you to work out for yourself why a rule started alerting again.
Viewing the tab does not require permission to change the rule, so anyone with read access can review what is exempt. Revoking does require permission to update the rule.
A decision is described by what it covers now, not by how many rows were originally selected. Exempting an entity again under a later decision moves it to that newer decision, so revoking the older one can clear fewer entities than its header once showed. The confirmation and the result both tell you the number actually revoked.
Entity names on this tab are the ones recorded when the exemption was filed, and are not refreshed from the graph. A name can therefore lag what the entity is called today. The Status column is what tells you whether the exemption still matches anything: an orphaned exemption names an entity the rule no longer returns.
Expiry
An exemption with an expiry date stops applying after that date, and the entity starts counting again on the next evaluation.
An expired exemption is not deleted. It stays on the rule's Exemptions tab marked as expired, so a rule that starts alerting again is always explainable—you can see which exemption lapsed and when. Exempting again, or extending the expiry, brings it back into effect.
Exemptions take effect as soon as they are created. There is no approval workflow in this release.
Revoking an exemption
Revoking an exemption puts the entity back into the rule's results from the next evaluation onwards.
From the Exemptions tab, click Revoke decision to revoke a whole decision at once, or expand it, select individual entities, and revoke only those. Revoking part of a decision leaves the rest of it in place.
A revoked entity is reported as newly discovered on that next run, because the rule compares each run against the previous run's results.
Revoking always works, even on a rule that has since been edited into a shape that can no longer accept new exemptions. Exemptions never become permanently stuck.
Limitations to plan around
An exemption can be lost if the entity's identity changes
An exemption is keyed to the graph identity of the entity it covers. That identity is derived from the integration instance that ingested the entity together with the entity's key, so anything that changes either one detaches the exemption. A detached exemption stops applying, and the entity starts counting again.
Removing an integration and adding it back breaks every exemption created from entities that integration ingested, all at once. Re-adding an integration creates a new integration instance, which gives every entity it ingests a new identity. The exemptions do not follow.
If you need to reconfigure an integration, edit the existing configuration rather than deleting it and adding it again.
Other cases that detach an exemption:
- An integration version changes the format of its entity keys. Affects every exemption created from that integration's entities.
- A placeholder entity created by a mapper is later ingested by a real integration.
These cases do not affect an exemption:
- The integration runs again and re-ingests the entity.
- The entity is deleted and later re-ingested by the same integration instance.
- The rule is edited, renamed, retagged, or rescheduled. Exemptions attach to the rule itself and survive its edits.
A detached exemption breaks visibly rather than silently: it stops applying, so the entity is counted again and the exemption shows on the exemptions list as orphaned. It never applies to the wrong entity.
Exemptions are not durable on unified devices and identities
Do not rely on exemptions against UnifiedDevice or UnifiedIdentity entities.
A unified entity is rebuilt whenever a new correlation arrives: JupiterOne creates a new combined entity and discards the previous one. That is routine operation, not an unusual event, so an exemption on a unified device or identity detaches on its own schedule and the entity starts counting again.
The exemption is not silently misapplied—it stops applying and shows as orphaned—but it will need re-creating, and you will not be told when. Nothing prevents you from creating one, so treat it as temporary rather than as a standing decision.
Where a rule can be written against the underlying Host, Device, or User entities instead, exempting those is durable, because their identity comes from the integration that ingested them rather than from correlation.
UnifiedVulnerability entities are not affected. Their identity is derived from the CVE, so it is stable.
One machine can need several exemptions
A query written against an entity class returns one row for every source that reported the asset, not one row per real-world thing.
FIND Host WITH diskEncryption != true returns a separate row for each system that reported that host. A single laptop known to your cloud provider, your CMDB, and your endpoint agent appears as three rows, and all three need exempting for the laptop to stop counting.
This is not new behavior—that query already returns three rows and the rule already counts three—but exempting is usually the moment it becomes visible. Select all the rows for that asset and exempt them together, which files them as one decision.
Managing exemptions through the API
Everything above is available on the public GraphQL API: creating exemptions in bulk, revoking them, reading a rule's exemptions, checking whether a set of results can be exempted, and downloading either result set. See Exemptions in the alert rules API reference.
The JupiterOne Terraform provider does not manage exemptions.