index

The old model of security (build a wall around your stuff and hope no one gets in) isn’t cutting it anymore. Today’s environment is messy: distributed teams, cloud sprawl, constant pressure to move fast, and attackers who don’t play by the rules. Zero Trust (ZT) has stepped in as a modern security approach to handle this complexity.

Zero Trust implementation differs from company to company, and in many cases is centered on how granular the resources are. If we think about Zero Trust for data, then we need to move past the surface-level thinking about databases or data lakes as resources and start getting serious about how we define and control access at a more granular level.

What is Zero Trust?

At its core, Zero Trust is about shifting from a network-first mindset to a protection-of-individual-assets mindset—data and systems over segments. It operates on the principle that no entity or asset is implicitly trusted. It assumes that bad actors might already be inside your network—or that the network itself doesn’t matter as much as it used to. In fact, Zero Trust assumes a hostile environment and that a breach has already occurred or will occur.

Instead of asking, “Is this user on the VPN?”, with Zero Trust we ask:

• Who is this user?
• What device are they using?
• What are they trying to access?
• Should they have access to that exact thing—right now?
• From what location or network is the request originating?

That’s a lot of context to track, which is why Zero Trust architectures are built around components like Policy Decision Points (PDPs), Policy Enforcement Points (PEPs), and real-time signals from identity, device status, user behavior, and other contextual data. This is what powers intelligent, real-time access decisions.

Let’s Talk Granularity: Rows and Columns as a Resource

Most traditional access control models are too coarse. A user either gets access to a database, or they don’t. But in reality, one record might mix someone’s contact info, with sensitive financial or health data - accessing the entire record will imply a very specific context, while we could think about different scenarios where we only want access to a small portion of that record.

For example, if a customer reports a missing pharmacy order to a support bot, the bot shouldn’t access the diagnosis just because it’s saved on the same row. But the insurance bot should. Treating the entire dataset as one “resource” is a security shortcut—and not a good one.

Instead, define your resources at a granular level—like individual rows. That allows for true least-privilege access, where a user can see only the specific data they need, nothing more. It also drastically limits the blast radius if something goes wrong.

Ephemeral Access in Secure Data Enclaves

Once you’ve defined resources at a granular level, the next step is controlling how people access them. That’s where the concept of resource enclaves comes in: secure, isolated environments where sensitive data can be accessed under tightly controlled conditions.

Why Enclaves Matter

Zero Trust mandates micro-segmentation, where environments are carved into smaller, isolated zones to limit the blast radius of any compromise. But we can—and should—go further.

With data enclaves, data access can be segmented at a very fine-grained level, determining which columns of a record need to be accessed for that specific context. The data enclaves provision an environment where all the data that can be accessed is safe for that context and has been properly authorized.

Enforced Separation: The Security Mantrap

To better protect the underlying systems, enclaves can introduce an additional layer of isolation between the data being accessed and the systems where that data lives—similar to how jewelry store entryways (mantraps) work:

• First Door: A user must fully authenticate and get verified.
• Second Door: Only after the first door closes can the next open, giving access to a temporary working copy of the requested data.
• Result: The requester never touches the actual source system directly. This buffer shields core infrastructure from exposure.

Add Ephemerality to the Mix

Even with all these controls, access shouldn’t last longer than necessary:

• Just-in-time (JIT) access is granted only when needed.
• Just-enough-access means the user gets only the data required for the task.
• Time-bound sessions ensure access is automatically revoked after the task is completed—whether that’s 20 minutes or once a specific report is generated.

Example: A support engineer might get access to 3 customer records for a 20-minute troubleshooting session. Once done, access closes itself.

Role of PAM: Controlling Elevated Access

This model pairs naturally with Privileged Access Management (PAM):

• PAM scopes and monitors elevated access.
• Even admins only get what they need, when they need it—and lose access when they don’t.
• Every access is logged, auditable, and revocable by policy.

You Can’t Scale This Without Automation

Managing row-level, time-boxed, context-aware access manually is impossible. That’s where automation and dynamic policy definitions come into play.

The Policy Decision Point (PDP) evaluates access requests using real-time inputs from across the environment—users, devices, behavior, metadata, and more. These decisions aren’t static. They’re driven by rich, contextual insight. Automation and orchestration handle the complexity and ensure consistency at scale.

Example:

Let’s say a payment engineer investigating a transaction failure requests access to customer logs. The system automatically grants access to transaction IDs, timestamps, and error codes. But when the same engineer realizes they need account numbers to trace the payment flow, the system triggers additional verification—perhaps requiring manager approval or MFA step-up—because account numbers are PII with higher sensitivity. Same user, same context, but different data sensitivity drives different access controls.

The Payoff: Speed, Security, and Audit-Readiness

When you combine Zero Trust with row-level granularity, ephemeral access, and automation, the benefits are significant:

• Attack surface shrinks — access is scoped and time-limited.
• Lateral movement is blocked — every access attempt is authenticated and tightly authorized.
• Ops move faster — legitimate users get what they need without waiting for manual approvals.
• Access is smarter — decisions are made in context, not based on static roles or rules.
• Audit trails are clean — compliance teams get clear, provable records of who accessed what, when, and why.
• Breach impact is limited — even if credentials are compromised, the exposure is small and short-lived.

Wrapping Up

Zero Trust isn’t a checkbox. It’s a mindset—and it only works when it’s applied all the way down to the data. Defining resources at the row level, delivering access through ephemeral enclaves, and automating everything with policy engines and rich context—that’s how you build a security posture that’s resilient and ready for anything.