Drop rules (admin)

Drop rules let an account administrator stop JupiterOne from ingesting specific entities that the account considers noise — for example, AWS default VPCs, default subnets, or AWS-managed IAM policies. A drop rule is a simple filter: any entity that matches an enabled rule is skipped at ingest and never written to your graph.

Drop rules are a controlled feature. JupiterOne enables them per account, and there is no default rule set — nothing is ever dropped unless you author a rule yourself.

Shared responsibility

danger

You own every drop rule and its consequences. JupiterOne provides the mechanism; you decide what to remove. If a rule drops entities that a dashboard, alert, compliance mapping, or saved query depends on, those things will break — and that is your responsibility, not a defect. Author rules deliberately and review their effect.

The model is intentionally simple and one-directional:

• You are in control. JupiterOne never decides what to exclude. Completeness is the default; a drop only ever happens because your account authored a rule that names it.
• You own the outcome. Dropped entities are absent from the graph. Anything that relies on them — queries, alerts, compliance evidence, reports — sees them as gone. That trade-off is yours to make and to monitor.
• Fail-open, never fail-closed. A missing, disabled, or invalid rule set drops nothing. The failure direction is always "we kept data you meant to skip," never "we silently lost data you wanted."
• Reversible, but not instant. Disabling or deleting a rule stops the drop, and the affected entities are re-ingested on the next full sync of each integration. They are not restored the moment you change the rule.

warning

Drop rules are the wrong tool for most exclusions. If your goal maps to a single integration step or data source, turn that off with Data Sources instead. Use drop rules only for cross-cutting noise that Data Sources cannot express.

Prerequisites

• You must have the account Administrator role. Every drop-rules operation requires the accessAdmin permission and is rejected otherwise.
• Drop rules must be enabled for your account by JupiterOne.

What drop rules apply to

Drop rules are evaluated only during integration sync ingest, at the point where an entity would be created or updated. This has deliberate boundaries:

• Integration-managed data only. Rules apply to entities ingested by an integration sync. They are scoped to the integration-managed source and evaluated per sync job.
• Entities only. Rules match entities, never relationships or tags. When an entity is dropped, any relationship or tag that pointed at it is skipped automatically, so no dangling nodes are created.
• Reversible through normal sync. On the next sync, matching entities stop being re-ingested and any copies already in the graph are removed by the standard stale-delete pass.

What drop rules do not cover

Drop rules are narrowly scoped by design. They do not apply to:

• Mapper and MRR entities. Entities created through the mapper or mapped-relationship (MRR) path are not affected by drop rules. A rule that matches a noisy asset will not suppress a mapper-created copy of it. This is a known, deliberate boundary.
• Direct API writes and mutations. Entities you create or update directly through the API (including :OVERRIDE claims) are never dropped. A drop rule cannot silently discard a deliberate write.
• System-managed data. JupiterOne-authored nodes (for example, rule, compliance, and lifecycle data) are excluded from drop-rule evaluation.

note

If you need mapper-created or API-created entities excluded, drop rules will not do it today. Raise the use case with JupiterOne rather than assuming a rule covers it.

Rule shape

A rule set is an array of rules. A rule matches an entity when its optional _type and _class match and all of its conditions match. An entity is dropped if it matches any enabled rule.

{
  "id": "aws-default-subnets",
  "enabled": true,
  "_type": "aws_subnet",
  "_class": "Network",
  "conditions": [
    { "property": "defaultForAz", "op": "eq", "value": true }
  ]
}

Field	Required	Description
id	Yes	Stable identifier for the rule. Used for per-rule reporting and for per-rule updates.
enabled	No (default true)	Set to false to keep a rule without applying it.
_type	No	Match only entities of this type.
_class	No	Match only entities of this class.
conditions	No (default [])	Property conditions, combined with logical AND.

Each condition is { property, op, value }. The supported operators are:

Operator	Meaning
eq	Property equals value.
neq	Property is present and does not equal value.
in	Property equals one of the values in the value array.
exists	Property is present.
startsWith	String property begins with value (case-sensitive; mirrors the J1QL ^= operator).

Conditions match integration-supplied properties only

A condition can only reference a property that the integration itself puts on the entity — the value must be present in the source data at the moment of ingest. Drop rules are evaluated on the raw entity before JupiterOne enriches it, so anything JupiterOne adds after ingest is invisible to a rule and cannot be matched.

Tags are the clearest example:

• A tag set by the integration is part of the entity the integration delivers, so you can filter on it.
• A tag applied by a JupiterOne tagging rule is added after ingest. That value is not present when the drop rule runs, so you cannot filter on it.

The same limitation applies to any JupiterOne-derived data — for example, properties added by mapping, tagging rules, or other post-ingest processing. Write conditions only against properties that originate from the integration.

Limits

Rule sets are bounded to keep ingest predictable. A rule set that exceeds any limit is rejected as invalid, and — consistent with fail-open — an invalid configuration drops nothing.

Limit	Maximum
Rules per account	50
Conditions per rule	10
Values in a single in condition	20

Managing rules through the API

Manage drop rules through the JupiterOne GraphQL API, authenticated as a user with the account Administrator role. Every field below requires admin access; a non-admin caller receives a FORBIDDEN error and no change is made.

Read the current configuration

query {
  dropRulesConfigBeta {
    enabled
    version
    ruleCount
    rules {
      id
      _type
      _class
      conditions { property op value }
    }
  }
}

The query returns null when no configuration exists. The version field is used for safe concurrent updates (see Concurrent updates).

Save the entire rule set

Use saveDropRulesConfigBeta to replace the whole configuration. This is the safest way to make bulk changes.

mutation {
  saveDropRulesConfigBeta(
    input: {
      enabled: true
      rules: [
        {
          id: "aws-default-subnets"
          _type: "aws_subnet"
          conditions: [{ property: "defaultForAz", op: eq, value: true }]
        }
        {
          id: "aws-managed-iam-policies"
          _type: "aws_iam_policy"
          conditions: [{ property: "arn", op: startsWith, value: "arn:aws:iam::aws:policy/" }]
        }
      ]
    }
  ) {
    created
    config { version ruleCount }
  }
}

created is true when this call created the configuration for the first time.

Add, replace, or remove a single rule

# Add or replace a rule by id
mutation {
  saveDropRuleBeta(
    rule: {
      id: "aws-service-linked-roles"
      _type: "aws_iam_role"
      conditions: [{ property: "path", op: startsWith, value: "/aws-service-role/" }]
    }
  ) {
    created
    config { ruleCount }
  }
}

# Remove a rule by id
mutation {
  deleteDropRuleBeta(id: "aws-service-linked-roles") {
    deleted
    config { ruleCount }
  }
}

Turn drop rules off

To stop all dropping without losing your rules, save the configuration with enabled: false. Once the change takes effect (see When changes take effect), syncs re-ingest everything the rules had been dropping.

mutation {
  saveDropRulesConfigBeta(input: { enabled: false, rules: [] }) {
    config { enabled }
  }
}

Concurrent updates

The configuration carries a version that increases on every write. To update safely when more than one administrator (or tool) might be editing, pass the version you last read as ifVersion:

mutation {
  saveDropRulesConfigBeta(
    input: { enabled: true, ifVersion: 4, rules: [ /* ... */ ] }
  ) {
    config { version }
  }
}

If the stored version no longer matches, the mutation fails with a CONFLICT error instead of overwriting the newer change. Read the configuration again, reapply your change, and retry. Omit ifVersion for a last-writer-wins save.

When changes take effect

Drop rule changes are not applied instantly. Each replication worker caches the rule configuration in memory for up to 30 minutes, so a rule you add, change, remove, or disable can take up to that long to take effect across in-progress and future syncs. This happens automatically — there is nothing to trigger or restart.

Two consequences worth knowing:

• After you save a change, entities a new rule matches may keep ingesting — or, for a removed rule, keep being dropped — for a short period until the cache refreshes.
• If the configuration temporarily cannot be read (for example, while the database is under heavy load), workers keep applying the last successfully-loaded configuration for up to 24 hours rather than dropping the filter, so your rules stay in force through a transient outage.

Drop rules are meant for stable, rarely-changing filters, so this delay is not normally noticeable.

Validation errors

• A rule set that violates a limit or uses a malformed condition is rejected with a BAD_USER_INPUT error that describes the problem. Nothing is written.
• Because a rejected configuration is never stored, a validation error cannot leave your account in a state where the wrong data is dropped.

Related topics

• Data retention