IDQL and Hexa aim to unify policy across fragmented cloud estates

At a glance

What this is: This is a Strata Identity explanation of IDQL and Hexa, a policy orchestration approach intended to unify access policy across cloud platforms, identity layers, data layers, and network layers.

Why it matters: It matters because IAM teams trying to govern multi-cloud estates need policy portability and consistent visibility, not one more isolated control plane that deepens fragmentation.

Context

Cloud policy fragmentation is a governance problem before it is a tooling problem. When each cloud platform, identity layer, application layer, data layer, and network layer expresses policy differently, teams lose the ability to answer a basic question: what policy is actually in force across the estate?

IDQL and Hexa are presented as a way to standardise the expression of policy and translate it into target-system formats. For IAM, IGA, and cloud security teams, the practical issue is whether policy can be managed as a portable governance layer without replacing existing runtime enforcement in every platform.

Key questions

Q: What breaks when access policies stay static in a dynamic cloud environment?

A: Static roles and permissions quickly drift away from actual business and technical conditions. Standing privilege, excessive access, and unused entitlements become easier to exploit, especially after changes in workload, location, or risk level. Security teams should use continuous access evaluation and context-aware decisions so permissions reflect current reality, not yesterday’s assumptions.

Q: Why does fragmented metadata and policy enforcement increase risk in multi-cloud data environments?

A: Fragmented governance makes it harder to know what data exists, who can use it, and whether protection rules are being applied consistently. As environments spread across systems, teams lose visibility into context, sensitivity, and lineage. That raises the odds of misclassification, access errors, and weak auditability, especially when data moves between operational, analytics, and AI use cases.

Q: How do teams know whether policy orchestration is actually helping?

A: It is helping when the organisation can show fewer manual policy translations, fewer cloud-specific exceptions, and clearer lineage from written policy to deployed enforcement. If policy still has to be re-keyed platform by platform, the orchestration layer has not solved the governance problem.

Q: What is the difference between policy orchestration and runtime enforcement?

A: Policy orchestration coordinates how policy is discovered, translated, and distributed across systems. Runtime enforcement is the target platform’s actual decision-making at the moment access is requested. Orchestration improves consistency, but it does not replace the local authorisation engine that makes the final access decision.

Technical breakdown

Identity query language for portable policy expression

IDQL is described as a declarative policy language, which means the policy intent is written once and then translated into the native format used by each target system. That matters because cloud estates often combine proprietary policy syntax with bespoke application rules, making direct comparison and central oversight difficult. Declarative policy changes the governance model from system-by-system authoring to a common representation that can be distributed across environments. The control challenge is not only syntax translation, but preserving semantics when a policy moves between platforms with different decision models.

Practical implication: treat policy expressiveness and translation fidelity as governance requirements, not just integration features.

Policy discovery, translation, and orchestration across cloud platforms

Hexa is positioned as the operational layer that discovers existing policies, translates them into IDQL, and orchestrates them back into target systems. This is important because many organisations do not have a reliable inventory of where policy exists, how it differs, or which role definitions are duplicated across clouds. The architecture is agentless and proxyless, using public APIs rather than inserting a new enforcement point. That makes the model suitable for coordination, but it also means the value depends on connector coverage and on whether the source and target policy models can be mapped without losing intent.

Practical implication: validate discovery coverage and translation boundaries before assuming central policy management will be complete.

Policy-as-code for zero trust governance

The article frames IDQL and Hexa as a way to make access policy portable enough to support Zero Trust Architecture. In practice, that means policy becomes versionable, reviewable, and reusable across systems instead of being trapped in cloud-specific consoles. The governance gain is not only operational speed. It is also the ability to understand who has access to what, where policy diverges, and which exceptions have accumulated over time. For large environments, that improves auditability and reduces the risk that policy drift hides in isolated enforcement points.

Practical implication: use policy-as-code to make access rules reviewable and drift-resistant across cloud estates.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy fragmentation has become the hidden control plane problem in multi-cloud IAM. Enterprises do not mainly lack more enforcement points. They lack a durable way to express one policy intent across platforms that each insist on their own syntax, scope, and runtime model. That creates governance gaps in visibility, review, and change control, especially when identity, application, data, and network policies diverge. The practitioner conclusion is that policy portability has become a core identity control requirement, not an architecture preference.

IDQL represents a shift from system-native administration to intent-native governance. When policy is expressed once and translated for execution, the real value is not the language itself. It is the ability to separate policy authorship from enforcement detail without losing auditability. That separation matters for IAM, IGA, and cloud security teams that need a common policy vocabulary across heterogeneous estates. The practitioner conclusion is that governance teams should judge policy standards by translation fidelity and inventory completeness.

Hexa shows that orchestration can extend policy reach without replacing runtime enforcement. That distinction is important because many identity programmes fail when they try to collapse governance and enforcement into the same layer. Here, orchestration coordinates policy distribution, while target systems still make the runtime decisions. The practitioner conclusion is that teams should evaluate orchestration as a control-plane harmoniser, not as a substitute for local authorisation engines.

Policy lock-in is now an identity risk, not just a cloud procurement issue. When policy lives only in vendor-specific formats, enterprises inherit hidden migration cost, inconsistent exception handling, and fragmented compliance evidence. A named concept fits here: policy portability debt. That debt accumulates whenever teams cannot move or reconcile policy without manual re-authoring. The practitioner conclusion is that identity governance programmes should measure policy portability alongside access coverage.

Standardised policy only matters if governance can prove what changed and where it applied. Multi-cloud environments need more than a common syntax. They need traceability from policy intent to translated enforcement so audit teams can see the lineage of each decision. The practical conclusion is that identity leaders should treat policy standards as part of their evidence model, not just their integration stack.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: Identity Security Programme Guide

What this signals

Policy portability debt: multi-cloud programmes accumulate hidden risk whenever policy must be re-authored for each platform, because every manual translation creates a new opportunity for drift and audit inconsistency.

The most useful governance test is whether a written policy can be traced from intent to translated enforcement without human re-interpretation. If that lineage is weak, the organisation has orchestration in name but fragmentation in practice.

For practitioners

• Define a portable policy model Document the access rules that must survive translation across clouds, applications, and network controls before introducing orchestration.
• Inventory policy sources and drift Map where policy is authored today, where it is enforced, and where equivalent rules diverge across platforms and business units.
• Test translation fidelity before scale-out Pilot a small set of high-value rules and verify that the translated policy preserves intent in each target system.
• Measure exception sprawl Track how many cloud-specific overrides exist and whether they can be expressed as governed policy rather than one-off console changes.
• Treat policy as code for auditability Version policy definitions, review changes through normal governance workflows, and retain lineage between source intent and deployed enforcement.

Key takeaways

• Multi-cloud policy fragmentation is a governance problem because access rules are authored, translated, and enforced differently across systems.
• Only 44% of developers are reported to follow security best practices for secrets management, showing how often policy discipline fails at the operational edge.
• Policy orchestration matters when it improves portability, auditability, and drift control without adding another silo of enforcement.

Key terms

• Policy Orchestration: Policy orchestration is the coordination layer that ensures identity rules are applied consistently across different platforms and control planes. It matters when each cloud or system uses different primitives, because the challenge becomes preserving policy meaning during translation and enforcement, not just storing the rule centrally.
• Declarative Policy: A declarative policy states the conditions under which access is allowed instead of embedding decision logic inside each application path. It keeps authorization rules in one place, which makes them easier to audit, test, and change without creating hidden differences between endpoints.
• Control Portability: Control portability is the ability of a governance control to keep working when the application architecture changes. In clean core programmes, portable controls survive release cycles, integrations, and cleanup of custom code, which makes them more reliable than controls that only exist inside legacy extensions.
• Scope drift: Scope drift is the gradual mismatch between what an integration was meant to do and what its credentials still allow it to do. It happens when permissions are not revalidated as business needs change, creating hidden over-privilege across SaaS and API-connected systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.