2026.3.0

2026.3.0 extends the external system permissions to Apache Pulsar, Apache Solr, ClickHouse, PostgreSQL and OpenSearch. The Pulsar and Solr agents decide every request inside the system; the ClickHouse, PostgreSQL and OpenSearch agents run beside the system and keep its own access control in step with the policies, so the system checks every request itself. The complete list of changes is in the GitHub comparison.

Apache Pulsar

• A Pulsar service plug-in: tenants, namespaces, topics, the subscriptions below a topic, and clusters, with Pulsar's produce, consume, functions, sources, sinks and packages and the administration of topics, namespaces and tenants; it signs in with a token, a password, OAuth 2.0 client credentials or a TLS client certificate; see Apache Pulsar.
• A broker authorization provider that decides each check at the tenant, namespace, topic and subscription in turn, with client-address conditions; admin on a cluster makes a role a Pulsar superuser, and granting through Pulsar itself is refused; see the Pulsar agent.
• Integration tests cover Pulsar 3.0.17, 3.3.9, 4.0.14 and 4.2.5.

Apache Solr

• A Solr service plug-in: collections, the request paths within them such as /select or /export, so that a policy can allow a collection and deny one handler, and the cluster; it signs in with basic authentication or a JSON web token; see Apache Solr.
• An authorization plugin of the nodes that classifies requests as Solr's rule-based plugin does and decides each one at its collection and request path; Collections API requests need admin_collection on every collection they name, and a JSON web token's verified roles count as groups; see the Solr agent.
• Integration tests cover SolrCloud nodes of Solr 9.8.1, 9.10.1, 9.11.0 and 10.0.0, under Solr 9's security manager.

ClickHouse

• A ClickHouse service plug-in: databases, tables, columns and the server; reading and writing are decided by column, and table, database and server operations by their own access types, none of which is a privilege group, so a policy never gives more than it names; see ClickHouse.
• An agent beside the servers that keeps one role per user holding exactly what the policies give, and one row policy per row filter; an access type allowed on a whole database with nothing below it restricted is granted on the database, so new tables have it at once; see the ClickHouse agent.
• Accesses are reported from system.query_log; grants made outside GrantForge that give what a policy denies are reported. Integration tests cover ClickHouse 24.8, 25.3, 25.8, 26.3 and 26.8.

PostgreSQL

• A PostgreSQL service plug-in: databases, schemas, tables and views, and columns, with PostgreSQL's privileges at the level where PostgreSQL grants them; it signs in with a password or a TLS client certificate, with libpq's TLS modes; see PostgreSQL.
• An agent beside the servers that keeps one role per user in every database, down to columns, with the CONNECT, schema USAGE and serial sequences it needs, changing each database in one transaction; row filters become restrictive row security policies, so they only narrow; see the PostgreSQL agent.
• Accesses are reported from the server log written with pgaudit. Integration tests cover PostgreSQL 15, 16, 17 and 18.

OpenSearch

• An OpenSearch service plug-in: indices and data streams, their fields, and the cluster; each access type is an action group of the security plugin; masks become its masked fields and row filters its document level security; see OpenSearch.
• An agent beside the cluster that keeps one role per user, mapped to that user alone, written as JSON patches the security plugin applies across the cluster; index patterns stay patterns wherever every policy decides the same across them, so indices created later are reachable at once; see the OpenSearch agent.
• Accesses are reported from the security plugin's audit log; roles outside GrantForge that give what a policy denies are reported. Integration tests cover OpenSearch 2.19, 3.3, 3.6 and 3.9.

Policy engine and agents

• The policy engine tells whether anything below a resource could be decided otherwise for a user and an access, so agents that grant in a system's own terms may grant a container as a whole, such as every table of a database.
• Agent snapshots show their masking and row filtering policies and the users they name, besides their access policies.

Documentation and release

• The Pulsar, Solr, ClickHouse, PostgreSQL and OpenSearch plug-ins and agents are documented in all eleven languages, and every README lists them with the versions the integration tests verify.
• The documentation's scrollbars follow the site's palette in light and dark themes.
• GitHub releases are titled by their version tag.

Fixes

• The Pulsar plug-in names a broker that refuses connections as unreachable.
• The Solr agent is built against Solr 9.10.1, which fixes advisories of earlier releases.
• The PostgreSQL agent reads zone abbreviations such as CEST in server log times.
• The OpenSearch agent keeps SLF4J inside its jar, so a server that bundles it keeps its own logging.
• The console, the SDK and the documentation site update vite, vitest, undici and dompurify to releases that fix npm advisories.