Platform / Dynamic Policy Enforcement
Dynamic Policy Enforcement
Access decided at the moment of decryption.
XQ checks every access request against live attributes — who is asking and their role, what data they want and how it is labeled, what they want to do with it, and the device, location and time — before it releases a key. The policy travels with the data, so it applies anywhere the data goes, and access can be revoked without moving or deleting anything.
Built for Security teams enforcing Zero Trust at the data layer · Organizations with data residency or export-control rules · Programs sharing data with partners, contractors or coalitions
At a glance
ModelsABAC and RBAC
AttributesSubject, data object, action and environment
IdentityOIDC and SAML, including Entra, Okta and Ping
RevocationInstant, without moving the data
Works with Microsoft Entra ID · Okta · Ping / PingFederate · SAML 2.0 · OIDC · Microsoft Purview
Policy that travels
Rules apply to the data itself, on any network, cloud or device.
Decisions on live conditions
A user who changes location, device or status is re-evaluated at the next access.
Revoke after sharing
Withdraw access to data that has already left your environment.
Why network-time checks aren’t enough
Network access controls verify a user once, at the edge of a session. After that, a file can be copied, forwarded or synced anywhere and the original rules no longer apply. XQ evaluates policy every time the data itself is opened, against conditions as they are at that moment.
What XQ evaluates before releasing a key
| Attribute | Example policy |
|---|---|
| Subject — who is asking | User attributes from your identity provider (OIDC / SAML) such as department, clearance, citizenship or contractor status — or the identity of an application or AI agent |
| Role (RBAC) | “Must be a member of the Legal group” |
| Object — the data itself | Its classification label and governed tags, such as CUI, PHI, ITAR-controlled, project or customer |
| Action | View, edit, download, share, forward or print — each allowed or denied on its own |
| Environment — location | “Must be in the USA” — geofenced key release |
| Environment — device and network | Keys issued only to validated, compliant devices on approved networks |
| Environment — time | Access only within an approved window, or until a set expiry |
A policy is a rule across these attributes, evaluated at the moment of access — for example: people whose clearance is Secret or higher may view, but not download, data labeled ITAR-controlled, from inside the United States, on a managed device.
If a condition changes — a user leaves a group, a device falls out of compliance, someone travels outside an approved region — the next request is denied, and access to existing copies can be revoked.
See your access rules enforced on the data itself.
Why ABAC, not just roles
Role-based access control grants access by static job title, so every new mix of team, project, region and sensitivity needs another role — the “role explosion” that makes RBAC hard to keep accurate. Attribute-based access control evaluates the attributes of the subject, the object, the action and the environment against policy every time access is requested, so it stays fine-grained and context-aware as people and data change.
- Policy follows the data’s attributes. A rule written for a label or tag — such as PII or CUI — applies automatically to every new object that carries it, with no object-by-object setup.
- Roles still count. RBAC remains one input; ABAC adds the data, the action and the context around the request.
- Decided on live conditions. Attributes are evaluated in real time, so a change in clearance, label, location or device takes effect at the next access.
What it enables
- Data sovereignty enforcement, with data readable only in approved regions.
- Coalition data isolation on shared infrastructure.
- Containment of mission data on personal and unmanaged devices.
- Alignment with the DoD Zero Trust data pillar.
Every decision is recorded
Each access request, decision and decryption is written to an immutable audit log. See provenance and audit trail.
Related resources and articles
FAQ
Dynamic policy enforcement, answered directly.
When does XQ check access policy?
Every time protected data is opened. The local agent sends the request to XQ, which evaluates it against the data owner’s active policy before releasing a one-time key.
What conditions can a policy use?
Attributes of the subject (a user, application or AI agent, including identity-provider attributes such as clearance or department), of the data object (its classification label and tags), of the action (view, edit, download, share, forward or print) and of the environment (location, network, device posture and time) — plus roles (RBAC).
Which identity providers does XQ support?
Any identity provider that uses OIDC or SAML 2.0, including Microsoft Entra ID, Okta and Ping / PingFederate.
Can we revoke access to data that has already been shared?
Yes. Because every access requires a key from XQ, withdrawing access makes every copy unreadable — without moving or deleting it.
Can we suspend access temporarily instead of revoking it?
Yes. Suspension blocks key release just as revocation does, but it is reversible, so security teams can respond to an anomaly without making a permanent decision. Revocation can target a single recipient or delete the key material entirely.
Enforce policy wherever your data goes.
See how XQ decides access at the moment of decryption.