v1.42.0

From now on, Enterprise OPA does not need an extra license when talking to Styra DAS!

This release also includes various dependency bumps, and updates the embedded OPA version to v1.6.0.

Automatic Licensing with Styra DAS

Enterprise OPA now automatically enters licensed mode when connected to a Styra DAS instance.
This should allow for easier setup and deployment of Enterprise OPA for Styra customers.

If Styra DAS is not available, Enterprise OPA will fall back to its existing license key system.

v1.41.1

This bugfix release updates the embedded OPA version to v1.5.1.
It's only relevant to users explicitly selecting the rego target (i.e. OPA's evaluation engine) in eopa eval, or using fallback mode.

v1.41.0

This release includes various dependency bumps, and updates the embedded OPA version to v1.5.0.

v1.40.0

This release contains a security fix, addressing CVE-2025-46569.
The release also updates the embedded OPA version to v1.4.0,
and the embedded Regal version to v0.33.1.

For details on the security content of this release, please see the OPA v1.4.0 release notes, and the associated Security Advisory.

v1.39.1

This release fixes a bug related to using Rego v0 bundles with the Compile API.

Also, referencing mask rules in annotations has been simplified: rules defined in the same package can now be referenced without the full prefix:

package filters

# METADATA
# scope: document
# custom:
#   unknowns: ["input.tickets"]
#   mask_rule: masks # <-------- here
default include := true         #|
# v-------------------------------
masks.tickets.description.replace.value := "<description>"

Starting from this release, our Windows binaries feature a Styra icon.

v1.39.0

This releases introduces Column Masking in Data Filters and a small change to the Compile API. It also features various dependency bumps.

Column Masking in Data Filters

In certain data filtering use cases, a row might be returned from the database that has a sensitive column present. We still want the application to be able to display everything it can to the user, but ideally hiding or modifying the sensitive values before display.

This is now supported by defining mask rules in your data filter policies, for example:

package filters

# METADATA
# scope: document
# description: Return all rows, for sake of the example.
# custom:
#   unknowns: ["input.tickets"]
#   mask_rule: data.filters.masks
default include := true

# Mask all ticket descriptions by default.
default masks.tickets.description.replace.value := "<description>"

# Allow viewing the description if the user is an admin.
masks.tickets.description.replace.value := {} if {
  "admin" in data.roles[input.tenant][input.user]
}

See the docs for all details.

Column masks are also returned by rego.compile(), and supported in filter.helper().

/v1/compile/{path}

The Compile API in Enterprise OPA now mirrors the Data API more closely: The rule to be used for translation into SQL clauses or UCAST expressions is part of the request path.

See the Data Filters Compilation API docs for all details. Users of our TypeScript SDK don't need to adapt anything, the changes have been made in the latest releases.

v1.38.0

This release includes various dependency bumps, and updates the embedded OPA version to v1.3.0, and the embedded Regal version to v0.32.0.

v1.37.0

This release includes an SQLite target for data filters generated by the Compile API, along with bugfixes and dependency bumps.

This release also includes Windows Authenticode signing and timestamping for the Windows EOPA binary.
This means fewer security pop-ups on Windows, and easier deployments in enterprise contexts!

v1.36.2

This release fixes a bug where parameterized tests were not properly evaluated in Enterprise OPA.

There is also a small change to the filter.helper() arguments: The mandatory tables argument is now a positional argument:

Before:

filtered := filter.helper(
  "data.filters.include",
  "SELECT fruits.name, users.name as owner FROM fruits LEFT JOIN users ON fruits.owner_id = users.id",
  {
    "tables": {
      "fruits": fruits_table,
      "users": users_table,
    },
    "debug": true,
  })

After:

filtered := filter.helper(
  "data.filters.include",
  "SELECT fruits.name, users.name as owner FROM fruits LEFT JOIN users ON fruits.owner_id = users.id",
  {
    "fruits": fruits_table,
    "users": users_table,
  },
  {
    "debug": true,
  })

Also, the filter.helper() now accepts a SQL query (second argument) that already contains a WHERE clause.

v1.36.1

This release includes a bug fix for ref heads and an overeager planner optimization (see upstream issue and fix).
It also features performance improvements to the gRPC API plugin.