Boruta 0.12.0 release

Boruta 0.12.0 introduces context-aware request noise detection, a YAML administration CLI, expanded token operations, and tighter OAuth client authentication. It also brings a substantial usability pass to the administration interface.

Open beta

Boruta is currently in an open beta phase. While it is mostly stable and parts of the project have undergone security assessments, it remains a work in progress. We encourage you to test Boruta in your own context and share feedback: production readiness depends on real-world use to uncover bugs and improve usability. Please also review the General Terms and Conditions.

Context-aware noise detection with Phi

The gateway can now train a native Phi model from OpenAPI request contexts. The model combines degree-one terms with sparse degree-two interactions to learn which requests belong together, instead of evaluating every request in isolation.

Phi prediction can use a bounded, recency-decayed memory of earlier requests. This makes it possible to classify a request as contextual noise even when the request would be legal on its own. Unmatched paths are evaluated across the entire gateway, while root-path requests remain valid for every HTTP method.

Upstreams can train and apply noise cancellation from transient OpenAPI uploads. Only the resulting Phi binary needs to be stored after training.

Better token operations

The token dashboard is now a more complete operational view. It adds:

• issuance charts and filtering;
• full-text search;
• token-chain details and claim inspection; and
• revocation controls.

For safer administration, token API responses no longer expose token values or other reusable secrets. The dashboard and API now default to tokens issued since the beginning of the current hour, keeping the initial result set focused and manageable.

Administration from the command line

The boruta and boruta_admin releases now include bin/boruta-cli, a YAML-oriented interface for administration resources. It authenticates using BORUTA_ADMIN_OAUTH_CLIENT_ID and BORUTA_ADMIN_OAUTH_CLIENT_SECRET.

boruta-cli <resource> <action> [resource-id] [response-filter ...] [-- action-parameter ...]

For example:

bin/boruta-cli role index
bin/boruta-cli client show CLIENT_ID id name
bin/boruta-cli upstream update UPSTREAM_ID -- scheme:https port:443
bin/boruta-cli logs index request_id status label -- events_only:true

Arguments before -- filter the YAML response. Parameters after -- are sent to the administration controller using key:value syntax, with colon-separated paths for nested maps and arrays.

OAuth and client security

This release tightens several client authentication boundaries:

• DID public clients are validated against their issuer, registered redirect URIs, and supported grant types.
• Client credentials, agent credentials, and introspection require secret authentication, including for public clients.
• Decentralized public-client grants may proceed without a secret only when the client is non-confidential and bound to the issuer.
• New OAuth clients are confidential by default, with the corresponding database migration included in the release.
• OAuth revocation requests now record their subject in logs.

Administration experience

The administration interface gains selectable Boruta, Gruvbox, and Nord themes. Sidebar sections now follow the operator's authorized scopes and stay expanded across nested dashboard routes. Resource activity refreshes correctly during navigation, upstream links are fixed, and form fields wrap properly on mobile screens.

The release also removes the redundant roles:manage:all scope from new installations and administration scope requests, and clarifies credential-presentation template actions.

Before upgrading

Boruta remains in beta during the 0.x series, so releases may include breaking changes. When moving to 0.12.0:

1. Run the included database migrations, particularly the migration that makes OAuth clients confidential by default.
2. For public clients used in decentralized identity flows, register the flow's redirect URI, enable the required grant types (preauthorized_code for credential issuance and/or vp_token for credential presentation), and set Confidential to false.
3. Review automation using client credentials, agent credentials, or introspection and ensure it supplies client authentication.
4. Remove dependencies on roles:manage:all in newly provisioned administration clients.
5. Set DISABLE_FILE_LOGGING=true if the deployment should emit logs only to the console.

See the Boruta server repository and the complete changelog for the full release details.