Your Zero Trust Application Policy Stops Where Work Begins

Key Takeaways

• Zero trust application access typically decides who can open an app, but much of the data risk lives in what users do afterward.
• Least privilege should govern in-session actions like copy and paste, downloads, printing, screen capture, and AI prompts, not only which apps a user reaches.
• When evaluating zero trust application access platforms, ask where policy is enforced, because that sets how much of the session each approach can see.
• Contractors and unmanaged devices are the honest test of any zero trust application design, because they strip away controls that depend on owning the endpoint.

Zero trust application access was built to answer who gets in

On the roadmap, the zero trust program looks finished: applications sit behind identity, device checks, and conditional access. Yet when a contractor opens the CRM and exports a customer list, many security teams still can't say where that data went next. Most zero trust roadmaps have a checkbox for the front door, and far fewer have one for the room behind it.

The tools aren't the problem here, since ZTNA and identity-aware access solved the defining problem of their era. A VPN placed a verified user on the whole network and trusted them from there. Moving to per-application access was the right correction, and it narrowed what a stolen credential could reach.

Those tools were designed around the access decision, and the standards reflect it. NIST SP 800-207, foundational guidance from August 2020, describes zero trust as moving defenses "from static, network-based perimeters to focus on users, assets, and resources." In that model, authentication and authorization happen before a session to an enterprise resource is established.

Adoption is broad, and coverage is partial. A Gartner survey published April 22, 2024 found 63% of organizations worldwide have fully or partially implemented a zero trust strategy. Gartner also found a strategy typically addresses half or less of an organization's environment.

Gartner doesn't say which half goes uncovered, and teams reasonably started with the door because it was the most visible risk. In our view, one of the largest remaining gaps is the session itself, where zero trust application access hands off and the actual work begins.

After the session opens, data moves through actions access policy doesn't see

A contractor on a personal laptop signs in to the finance app, passes the identity and device checks, and gets to work. What follows is ordinary work, and ordinary work is where data tends to leave. A common pattern we see is data loss that looks less like a break-in and more like a copy and paste. Even the NSA's Data Pillar guidance, published in April 2024, lists the insider who might "accidentally leak sensitive data by using it in an AI tool" among its examples.

Typical access policy approves the session and then steps back from actions like these:

• Copying a revenue table into a personal document
• Downloading a full customer export to the local drive
• Printing a report on a home printer
• Capturing or sharing the screen during a video call
• Uploading a file to a personal cloud or webmail account
• Pasting account details into a public AI tool

Each of these is a legitimate action somewhere, which is why blanket blocking rarely sticks. The real question is whether policy can tell a sanctioned export from one headed somewhere it shouldn't go.

Unmanaged devices widen the gap, because the endpoint controls teams normally lean on aren't there. CISA's Zero Trust Maturity Model v2.0, published in April 2023, says agencies with BYOD policies likely have "fewer options to maintain visibility and control."

GenAI has made the paste box hard to ignore. In a Gartner survey of 302 cybersecurity leaders published November 19, 2025, 69% of organizations suspected or had evidence of employees using prohibited public GenAI. The data in those prompts can start inside an approved, authenticated session.

The gap reflects design scope more than a missing tool. Access decisions were built to govern entry, and the actions that move data happen after entry is granted.

Least privilege has to govern what users do, not just which apps they open

You already decide which apps each person can reach. The next step is deciding what they can do once they're there, with the same rigor and the same live context.

Government guidance already points in this direction. The same NSA Data Pillar guidance argues DLP has to work beyond the perimeter. In its words, "DLP tools deployed only at a system boundary are inadequate to address corruption of data throughout the system."

The same guidance describes digital rights management (DRM) tools that can stop a user from forwarding, editing, saving, or printing data. CISA's maturity model goes further at its Optimal level, describing continuous application authorization and DLP that dynamically blocks suspected exfiltration.

The NSA's Application and Workload Pillar guidance, published in May 2024, frames app access the same way. It calls for "strong continuous authentication and granular access decisions… as a precondition for the use of the applications and workloads." That's a deliberate break from the traditional model, where "once authorization was granted it remained in place until it was revoked."

Neither agency prescribes specific browser controls, and the app guidance addresses access authorization rather than in-session actions. Both still point the same way, toward decisions that keep running after login and govern data while it's in use.

In practice, action-level least privilege can look like this:

• Read-only access by default for sensitive apps on unmanaged devices
• Copy and paste allowed between corporate apps and blocked to personal destinations
• Downloads permitted only to managed locations or encrypted storage
• Printing and screen capture governed per app and per data label
• Watermarking or on-screen data masking on sensitive views
• AI prompts inspected for sensitive data before they leave

Context also stays live, so identity, device posture, network, and the data on screen can change policy mid-session instead of only at login. A contractor whose laptop drops out of compliance can keep reading while losing the ability to download.

Back in the finance app, the same contractor can still reconcile accounts, run reports, and finish the job. The export simply can't land in a personal webmail account, and the attempt shows up in the log. Done this way, least privilege feels less like a lockdown and more like a well-run office where people move freely and filing cabinets stay put.

The enforcement point decides how much of the session a platform can see

If you're comparing zero trust application access platforms, the shortlists start to look alike: identity, posture, segmentation, and SSO. In our experience, many comparison guides score how well each platform verifies at the door. The more useful question is where each approach enforces policy, because that determines what it can see after the door opens.

Where policy lives matters because of where work happens. Gartner made the point in a press release on April 29, 2025: "Web browsers are the primary access method for most modern corporate applications." That makes the browser a natural enforcement point for application sessions.

Three architectural approaches show up on most shortlists, and each sees a different slice of the session:

1. Enterprise browser with built-in controls: Policy sits where users interact, so it sees the page, clipboard, files, and prompts, including on unmanaged devices.
2. Extension-only approaches on consumer browsers: They add useful visibility and controls within host-browser limits and work best as a complement.
3. Network and proxy enforcement: It's strong for routing and access decisions, and it sees connections rather than interaction inside the rendered page.

Network-centric enforcement was the right answer when work flowed through the corporate network, and it still handles routing well. Work has since moved into the browser tab, and the enforcement point is following it. Many teams will keep all three in the mix, so the real decision is which one carries in-session policy.

The difference shows up in a single upload, where a proxy sees the request, its size, and the domain it's headed to. The browser can see which tab started it, which data label the file carries, and whether the destination is a corporate or personal account. It can also connect the upload to what the user copied from the finance app a moment earlier.

Island's Enterprise Browser takes the first approach and puts access and in-session control under one policy. Island Private Access, part of Island Network Services, provides zero trust network access to private apps without a VPN. The same policy covers copy and paste, download, print, and screenshot controls, plus granular DLP and AI data protection from Island Enterprise AI.

In Island's design, ZTNA policy, DLP, and session monitoring share one policy engine and one management console. A reviewer can follow an access decision and a blocked export in the same place instead of reconciling separate tools.

For teams on consumer browsers, the Island Extension works alongside the Enterprise Browser to extend the same policy. Security is built in, not bolted on, so users get a familiar browser while security teams see the session. Island builds in the first category, so weigh this hierarchy accordingly and run the test below on Island's zero trust approach too.

Feature matrices tend to hide the difference, so ask each vendor to demo the same contractor session three ways. Run it on a managed laptop, on an unmanaged personal laptop, and with an AI assistant open in another tab. Then ask what's blocked, logged, or allowed in each, because that single session shows where each platform's policy stops.

Contractors and unmanaged devices are the honest test of your design

Most teams test zero trust application access with the users who are easiest to control. That population is the least likely to reveal a gap, and a pilot built only on managed laptops mostly proves managed laptops are managed. Unmanaged devices remove the controls that assume you own the endpoint.

The UK NCSC's zero trust design principles acknowledge "you may not be able to fully achieve all your monitoring goals" on such devices. Their advice is to trust those devices less than managed ones. In practice, that means policy has to travel with the session rather than the hardware.

For exactly this reason, contractors are a strong place to start your pilot. Some organizations still route contractors through VDI or shipped laptops, a setup we often see run heavier than the work requires. Gartner's April 2025 analysis of enterprise browsers notes they can complement or reduce reliance on VPNs, VDI, and desktop as a service for organizations prioritizing remote or third-party work.

The use case offers the clearest before-and-after and the most visible friction to remove. It also produces numbers leadership understands, such as days to a first productive session, help desk tickets per user, and devices shipped.

Before the pilot, a new contractor might wait days for a shipped laptop or VDI image, then work in a session that lags. After it, the same contractor signs in from a personal laptop on day one, opens the two apps the engagement needs, and starts working. Exports stay inside corporate destinations, and the security team can see what was copied, printed, or uploaded along the way.

Measure friction as a security metric, because people route around controls that slow them down. In February 2023, Help Net Security reported a Gartner finding that 69% of employees had bypassed cybersecurity guidance in the prior 12 months. Gartner's survey of 1,310 employees ran in 2022, and the lesson still holds: a control users avoid protects very little.

Bring these four questions to any zero trust application access design review, ideally before a feature matrix sets the agenda:

1. What can an authorized user on an unmanaged device do with data after the session opens?
2. Which in-session actions are governed by policy, and which are only logged?
3. Does policy change mid-session when context changes, or only at login?
4. What does the user experience look like for a contractor on day one?

If the answers stop at login, your zero trust application policy probably stops there too.

Your zero trust application policy can follow the work into the session

Access decides who gets in, and the session is where policy earns its keep. If you'd like to pressure-test that idea against your own contractor and BYOD sessions, schedule a walkthrough.

FAQs

What is zero trust application access?

It's per-application access granted only after identity, device, and context are verified, which replaces broad network access with a much narrower door. The strongest designs keep evaluating policy during the session, as described in the least privilege section above.

How is zero trust application access different from ZTNA?

ZTNA typically brokers network-level connectivity to private apps, while zero trust application access focuses on the application itself. Ideally, it also governs what happens inside the application once the connection is made.

Does zero trust stop data from leaving after a user logs in?

It can, when policy governs in-session actions such as copying, downloading, printing, and AI prompts. An access decision on its own approves the session and then steps aside.

How do you apply zero trust to contractors and unmanaged devices?

Enforce policy at the point of interaction in the browser, so controls don't depend on owning the device. The contractors section above explains why this group makes the most revealing pilot.

What should you look for in a zero trust application access platform?

Look at where it enforces policy, which in-session actions it governs, and whether it works for unmanaged users without adding friction. A single live contractor session usually reveals more than a feature matrix.