Cerbos Synapse makes Trino policy decisions portable across systems

At a glance

What this is: Cerbos Synapse is a policy orchestration layer that lets Trino and other non-native systems consume Cerbos authorization decisions, with row filtering and column masking driven by identity attributes.

Why it matters: For IAM teams, it shows how policy translation can extend centralized governance into data platforms without rewriting each system's native authorization model.

👉 Read Cerbos' walkthrough of Synapse for Trino policy orchestration

Context

Policy translation is the core problem here: many systems can enforce authorization, but they do not speak the same request and response language. In Trino's case, that means access control, row filtering, and column masking have to be expressed through a protocol bridge before the policy engine can evaluate them. For identity teams, this is a governance problem because the decision point is now detached from the application that consumes it.

Cerbos Synapse addresses a familiar NHI pattern as well as a data-governance pattern. It enriches a request with user attributes from an identity provider, evaluates policy centrally, and returns the result in the native format the calling system expects. That makes the identity context more complete at decision time, but it also means policy quality depends on the freshness and integrity of the attributes being attached.

Key questions

Q: How should security teams govern authorization when applications do not speak the same policy protocol?

A: Use a central policy model with protocol adapters, but assign explicit ownership for the translation layer, the policy store, and the identity attributes feeding decisions. The control only works when each consuming system can be audited back to one policy source and one set of trusted inputs. That is how teams keep governance consistent across heterogeneous platforms.

Q: Why do identity attributes matter so much in row-level security and column masking?

A: Because the policy engine often needs more context than the application request contains. Department, role, and clearance can determine which rows are visible and how sensitive columns are rendered. If those attributes are stale or incomplete, the policy can produce the wrong result even though the enforcement path itself is functioning as designed.

Q: What do teams get wrong when they centralise policy for analytics platforms?

A: They often focus on the policy syntax and ignore the lifecycle around it. Versioning, testing, review, attribute stewardship, and audit logging are what turn centralisation into governance. Without those controls, a shared policy plane can spread mistakes across every connected system instead of reducing risk.

Q: How do you know whether query-time masking is actually protecting sensitive data?

A: You need evidence from the full decision path, not just the final query result. Review what rows were filtered, what column expressions were returned, which attributes were used, and whether the policy state was logged for later inspection. If you cannot reconstruct those four elements, the control is not fully observable.

Technical breakdown

Protocol translation for non-native authorization

Trino, Kafka, Kubernetes, and Envoy each expose different authorization interfaces, so a single policy engine cannot talk to them directly without adaptation. Synapse sits between the calling system and Cerbos PDP, translating one protocol into another and then mapping the result back into the response shape the caller expects. In practice, that means a Trino OPA-style request becomes a Cerbos CheckResources call, and the answer is reformatted into allow or deny, row filters, or column masks. The important architectural point is that policy logic remains centralized while protocol handling stays system-specific.

Practical implication: separate policy logic from protocol adapters so authorization can be governed consistently across systems that do not natively share one model.

Attribute-enriched decisions for row-level security and masking

Row filtering and column masking are not just access checks with finer granularity. They require policy outputs that shape the data returned to the caller, often using SQL expressions or filter clauses. Synapse enriches the principal with attributes from the identity provider, such as department or clearance, because Trino's request alone is too sparse to support those decisions. The policy engine then evaluates the request with that extra context and returns row or column transformations instead of a simple boolean. This is a classic identity-to-data authorization pattern.

Practical implication: ensure attribute sources are current and trustworthy before relying on policy-driven filtering or masking for sensitive analytics data.

Live policy distribution and auditability across query paths

The article also shows the operational model behind centralized authorization. Policies live in Cerbos Hub, are versioned, and are distributed to Synapse instances without requiring application restarts or config pushes. Every decision, filter, and mask can be logged for later review, which matters when compliance teams need to reconstruct who saw what and under which policy state. That turns authorization from a local implementation detail into a centrally governed control plane for analytics access. The architecture is closer to policy operations than one-off app logic.

Practical implication: treat authorization policies as versioned controls with audit trails, testing, and change review rather than embedded application logic.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy translation is becoming part of identity governance, not just application plumbing. Once authorization spans multiple protocols, the governance problem moves above the application and into the orchestration layer. That matters because policy drift can now occur in the adapter, in the attribute source, or in the policy itself, even when the calling system remains unchanged. Practitioners should treat protocol mediation as a governed control surface, not an implementation convenience.

Attribute-enriched authorisation is only as strong as the identity data feeding it. Synapse works because it can attach department, role, and clearance to a request that originally arrived with little more than a username. That pattern is useful for NHI governance because the same principle applies to service accounts and workload identities that need richer context than the native request provides. The implication is that access decisions are no longer just about policy syntax, but about identity data quality and freshness.

Centralising query-time control strengthens auditability but also centralises failure. A single policy plane makes it easier to prove what was allowed, filtered, or masked at a given point in time. It also means a defect in policy logic, attribute resolution, or protocol translation can affect many consuming systems at once. IAM and data-governance teams should therefore evaluate resilience, segregation, and change control together rather than as separate disciplines.

Row-level filtering and column masking are now standard governance patterns for data platforms that expose identity-aware decisions. The important shift is not that Trino can do them, but that policy outputs are being used to shape data visibility at runtime. That brings NHI-style access logic into analytics environments where static table permissions are too coarse. Practitioners should expect more authorisation tooling to converge on the same attribute-driven model.

One policy language across heterogeneous systems reduces operational fragmentation, but it does not remove governance complexity. It moves that complexity into policy lifecycle management, test coverage, and attribute stewardship. Teams that already struggle with review cycles for NHI secrets and service accounts should recognise the same governance pattern here: centralised control only works if the inputs, change process, and audit trail are disciplined. The practitioner takeaway is to manage the control plane as carefully as the data plane.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• For a broader NHI control baseline, see the Ultimate Guide to NHIs for visibility, rotation, and offboarding patterns.

What this signals

As more platforms externalise authorization, the governance burden shifts from individual applications to the policy orchestration layer. That means IAM teams need tighter change control, clearer ownership, and better attribute stewardship, because a single defect can now influence several systems at once.

Policy-plane sprawl: the more systems that depend on translated authorization, the more important it becomes to treat protocol bridges as first-class controls. Teams should pair central policy with test coverage, audit logging, and identity-data validation rather than assuming the adapter layer is automatically safe.

For practitioners looking to anchor this model in a formal baseline, the NIST Cybersecurity Framework 2.0 is a useful way to map governance, protection, detection, and recovery responsibilities across shared authorization services.

For practitioners

• Map every protocol bridge to a governance owner Document which team owns the translation layer, the policy source, and the attribute source for each system that consumes external authorization decisions. This prevents gaps where no one can explain why a decision was made or who can change it.
• Validate identity attributes before using them in policy Check that department, role, clearance, and similar attributes are sourced from a trusted identity provider and refreshed at decision time. Stale attributes can produce incorrect row filters and masking outcomes even when the policy itself is correct.
• Test all three authorization outcomes separately Create test cases for allow or deny decisions, row filters, and column masks so each output is validated independently before deployment. A policy that passes table access tests can still leak data if filtering or masking rules are wrong.
• Keep policy changes under code review and version control Treat access rules as governed changes with pull requests, review sign-off, and rollback plans rather than as ad hoc admin edits. That is especially important when one policy file now governs multiple systems through a shared orchestration layer.

Key takeaways

• Cerbos Synapse shows how policy orchestration can extend identity-aware authorization into systems that do not share a native control model.
• The operational risk moves with the architecture: if attributes, translation logic, or policy review are weak, the same control plane can mis-shape access at scale.
• IAM and data-governance teams should manage authorization adapters as governed infrastructure, with tested policies, trusted attributes, and complete auditability.

Key terms

• Policy Orchestration Layer: A policy orchestration layer translates authorization requests between systems that use different protocols, request shapes, and response formats. It centralises policy decisions while handling the plumbing needed to make those decisions usable by each application or platform.
• Row-Level Security: Row-level security limits which records a user can see within a table based on policy and identity context. Instead of allowing or denying the whole table, the system returns only the rows that match the current principal's attributes and access conditions.
• Column Masking: Column masking changes how sensitive values are displayed without necessarily hiding the entire row. The policy can return partial values, redactions, or transformed expressions so the caller sees only the data that its role and attributes permit.
• Attribute-Enriched Principal: An attribute-enriched principal is a request identity that has been supplemented with additional context from an identity provider or directory. That extra context can include department, clearance, or role, which gives the policy engine enough information to make a more precise decision.

Deepen your knowledge

Trino authorization, row-level filtering, and column masking are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into analytics platforms, it is worth exploring.

This post draws on content published by Cerbos: Synapse orchestration for Trino authorization, row filtering, and column masking. Read the original.