Identity Is Not Enough: Why Zero Trust Needs On-Device Context

Short answer: ZTNA verifies who you are and, sometimes, the posture of your device, then grants access to an app. That's a big improvement over trusting the network. But identity alone doesn't tell you which application made a request, whether the login is a corporate tenant or a personal one, or what's inside the traffic. On-device enforcement sees all of that, because it runs at the operating system's networking layer. Zero trust gets sharper when the decision has more than identity to work with.

Identity answered one question well

'Who is this user, and should they reach this app?' ZTNA answers that better than a VPN ever did. Tie access to identity, check device posture, scope it per app. For controlling the front door to a private application, identity plus posture is a reasonable gate.

The problem is that the front door isn't where most modern risk lives. The risk lives in what happens after access is granted, and in all the SaaS and AI destinations that were never behind your door to begin with. Identity gets a verified user into a room. It says nothing about what they do once they're in it, or about the rooms that were never yours to gate.

Zero trust as a principle is bigger than access. 'Never trust, always verify' applies to the request, the content, and the behavior, not just the login. Identity-centric ZTNA implements the login part well and mostly stops there. The rest of the principle needs signals identity can't provide.

What identity can't see

A broker checks identity and waves the session through a tunnel. It generally cannot tell you:

• Which application generated the request. A browser tab, a desktop AI app, an IDE assistant, and a Python script can all reach the same endpoint. Identity is the same for all four. The risk is not.
• Corporate tenant vs. personal account. The same authenticated user can log into an approved enterprise workspace or a personal one at the same domain. Identity says 'it's them.' It doesn't say which account.
• What's in the request. A gated app session can still carry a prompt full of source code or an upload full of PII. Access control doesn't read content.
• How the behavior compares to normal. A verified user exfiltrating at 2 a.m. from a new process looks identical, at the identity layer, to the same user doing their job at noon.

Each of these blind spots maps directly to a real incident pattern. Over-permissioned access, personal-account data leakage, prompt-based exfiltration, and compromised-but-authenticated sessions all pass an identity check cleanly. Verifying the user was necessary. It was never sufficient.

Where on-device context comes from

Because Fly Direct enforces at the operating system's networking layer, it can combine signals a broker never sees in one decision: the user and device (identity), the originating process (browser vs. desktop client vs. script), the destination and full URL, the account or tenant in use, and the content of the request itself.

That's the difference between 'this authenticated user opened a tunnel' and 'this finance user, in a personal AI workspace, from a desktop client, is uploading a document with non-public numbers.' The first is a yes. The second is a specific, defensible no. Same user, same identity, completely different decision, and only the endpoint had the context to tell them apart.

Process-level attribution is the clearest example. A network broker often has to infer the application from the traffic, because all it sees is a flow to a destination. An on-device agent reads the originating process straight from the operating system. It knows a request came from chatgpt.exe versus chrome.exe versus python.exe, even when all three reach the same API endpoint. Our complete AI governance guide shows why that context is the foundation of real control.

The layers of context, stacked

It helps to see the signals as a stack, each adding resolution the layer below can't:

Identity tells you the person. Device posture tells you the machine's health. Application context tells you which program made the request. Account context tells you whether it's a sanctioned tenant or a personal login. Network context tells you the exact destination and path. Content context tells you what's actually being sent.

ZTNA typically reads the first two, at connection time. On-device enforcement reads all six, continuously. Every additional layer narrows the set of situations where a bad action looks identical to a good one. That narrowing is what 'sharper zero trust' actually means in practice.

Context turns access control into governance

Once the decision has identity plus application plus account plus content, you can do things access control can't: allow the enterprise ChatGPT tenant while blocking personal logins, permit an app but stop a specific sensitive upload, or treat a script hitting an API differently from a human in a browser.

That's the jump from gating access to actually governing behavior. Access control is binary and one-time: in or out, at the door. Governance is contextual and continuous: this action, by this process, with this content, right now, is or isn't allowed. dope.security delivers it through Cloud Application Control and on-device Dopamine DLP, covered in how to see and control generative AI.

The governance framing also matches how regulators and boards now think. They don't ask 'did you verify the user.' They ask 'can you demonstrate control over what leaves.' Answering that requires content and context, not just an access log.

The honest scope

Identity-centric ZTNA isn't wrong. It's incomplete for the traffic that matters most now. Verifying the user is table stakes, and ZTNA does it well for private-app access. The next layer, and the one that stops today's data loss, is context the endpoint can see and a broker can't.

Zero trust should use every signal available, and the richest set of signals lives on the device. That's not an argument against identity. It's an argument for adding the five layers of context that identity alone leaves on the table.

A worked example

Walk one request through both models. A developer opens an AI coding assistant and pastes in a block that happens to include an internal API key and a customer identifier. Identity check: it's a verified employee on a healthy, enrolled device. A ZTNA broker, if this traffic even reached it, sees an authenticated user and a session. The decision is allow, and nothing about the login was wrong.

On-device, the same request carries five more signals. The process is a desktop AI client, not the corporate browser. The account is a personal workspace, not the enterprise tenant. The destination is a public model endpoint. The content contains a secret and a customer identifier. Now the decision writes itself: block the upload, or strip and warn, because a personal-account desktop client is about to send a secret to a public model. Same user, same identity, opposite outcome. The only thing that changed is how much the enforcement point could see, and the endpoint could see all of it.

Frequently asked questions

Doesn't ZTNA already check device posture? Many do, at connection time. That's identity plus a posture snapshot. It still doesn't include the originating process, the specific account in use, or the content of each request, which on-device enforcement evaluates continuously.

Why does the originating process matter? Because a browser, a desktop AI app, an IDE assistant, and a script can hit the same destination with very different risk. Knowing which one made the request changes the right decision.

Can on-device enforcement tell a personal account from a corporate one? Yes. Cloud Application Control distinguishes approved enterprise tenants from personal logins at the same service and enforces enterprise-only access.

What's the difference between access control and governance? Access control decides who gets in, once, at the door. Governance decides whether a specific action with specific content is allowed, continuously. Governance needs context beyond identity.

Does more context mean more false positives? Used well, more context reduces them. A decision that knows the process, account, and content can allow benign cases that a blunt rule would block, and block risky ones a blunt rule would miss.

Is identity still important in this model? Yes. Identity is the foundation. On-device enforcement adds application, account, network, and content context on top of it, rather than replacing it.

Give zero trust more to work with

See what a decision looks like with full endpoint context. Book a 20-minute demo or start an instant trial with your corporate email.

Further reading: AI visibility: see every AI app your employees use and the CASB Neural product overview.