Zero Trust has meaningfully improved how enterprises decide who can start a session. MFA, conditional access, and device posture checks are now common. But the most consequential trust leak often happens after the session begins, when sensitive data renders in a browser or remote UI and teams try to claw back control using endpoint agents, extensions, or reactive monitoring.

That gap matters more in the agentic era.

Many AI agents work inside the same web and Windows applications employees use, where permissions were designed for people and roles, not precise, step-by-step control. When automation runs inside these sessions, the governance question is no longer “can the agent log in?” It is “what is it allowed to see and send, and can we prove it?”

The shift most teams miss: agents are becoming users

For most organizations, “enterprise AI” started as copilots and isolated proofs of concept. The next wave is different: agents that execute multi-step workflows, operate across multiple applications, and take actions with real operational impact.

One overlooked reality is also the source of most governance pain:

Agents do not only call APIs. Many agents operate through the same interfaces humans use.

That means the control plane for agent risk is not only API gateways and service-to-service authentication. It is increasingly the session boundary, the place where UI content renders and where inputs and outputs cross trust zones.

Why most initiatives fail: approval is the bottleneck

Most initiatives do not fail on capability. They fail on approval.

In agentic programs, three approval blockers show up repeatedly:

1. Unmanaged execution risk (“agents in the wild”)
   When automation runs on endpoints, in unmanaged browsers, or inside toolchains that security cannot reliably constrain, the blast radius is unclear and compensating controls become a patchwork.
2. Policy bypass inside sessions
   Even with strong identity and access at login, agents can still reveal or transmit data the enterprise did not intend to expose once inside the app.
3. Evidence gaps
   When a regulator, auditor, or incident response team asks “what happened?”, basic logs are rarely enough. If you cannot produce durable evidence with integrity guarantees, you do not have governance.

Where Zero Trust still leaks trust

Many teams have done the basics: shrinking VPN sprawl, enforcing MFA, adding conditional access, turning on some session logging. And yet, the lived reality persists:

“If you got in, you can probably see it.”

Why? Because a lot of “least privilege” is still least privilege at the door. Identity, posture, timeouts, role assignment. Necessary, but not sufficient. A session is not a permission model. It is a container for activity.

And in many stacks, sensitive content renders on the endpoint first, then controls attempt to prevent copy/paste, screenshots, uploads, or exfiltration. That approach can help, but it begins from a structural disadvantage: once sensitive content renders on an endpoint, you have already handed over a lot of control.

This becomes sharper in agentic workflows because agents are fast and consistent, can replicate mistakes at scale, and many applications were never built for fine-grained visibility controls.

A practical model for the agentic era: Secure Rendering + Bidirectional Session Governance

The architectural move is simple to describe and hard to implement well: Treat rendering as the control point.

Instead of asking only “can the user or agent access the app?”, the policy questions become:

• Can they see this portion of a page?
• Can they download this document type?
• Can they copy data out?
• Can they paste data in?
• Can this interaction be allowed back into the application?

This is what makes Zero Trust real inside the session, not just at login.

Downstream control: what the app is allowed to show

Downstream control is applying policy before content is delivered for rendering.

The key idea is not “hide it later.” It is: restricted content is excluded so it never renders on the endpoint.

What good looks like:

• Field and element level redaction for sensitive UI components (not just whole-app allow/deny)
• Role and context based decisions (identity, task, data classification, workflow state)
• Deterministic enforcement at the rendering boundary rather than best-effort endpoint behavior

Upstream control: what the user or agent is allowed to send back

Upstream control addresses a reality many stacks miss: the risk is not only data leaving. It is also unsafe or noncompliant data entering systems of record.

Bidirectional enforcement turns the session into a governed interface rather than a blanket trust zone.

Why Sonet’s two patents are relevant here

The ideas above can sound abstract until you translate them into one concrete question:

Where, exactly, do you enforce policy?

Most controls enforce at session establishment, then rely on endpoint behavior and monitoring once content is already visible. The two patents described in the white paper focus on enforcement at a different boundary: where interfaces are rendered and where user or agent actions flow back to the system.

• U.S. Patent 12,088,598 (“Secure access via a remote browser”) describes a “policy-controlled web session” where a protective layer evaluates permissions and generates modified instructions. It can exclude unauthorized portions of a page so restricted content never renders locally, and it can apply policy to what is submitted back to the application in the same session.
• U.S. Patent 12,341,782 (“Secure access via a remote client”) extends the model beyond web pages to remote client applications (including desktop apps). It describes enabling interaction through a protective layer and preventing unauthorized exchange back to remote systems by determining permissions for content and actions, then enforcing those permissions.

Taken together, they describe policy-driven, bidirectional session governance across web browsers, desktop applications, and remote systems: controlling what content is rendered and what content or actions are exchanged with systems of record.

Evidence-grade auditability is the production requirement

Security teams do not just need visibility. They need reconstructable evidence.

Evidence-grade auditability means:

• capturing who did what, to which system, when, and under which policy
• trustworthy time (synchronized timestamps)
• integrity protections (tamper-resistant records)
• chain-of-custody from capture through export
• controlled access and separation of duties

If you cannot export an evidence package that reconstructs activity end-to-end, you do not have a production governance posture.

What to require to move from “interesting” to “approvable”

If you are evaluating any agentic automation approach, the white paper recommends three requirements:

1. Controls at the rendering and interaction boundaryPre-render enforcement at meaningful granularity, plus bidirectional governance (what can be shown and what can be sent back), applied consistently to humans and agents.
2. Containment (no unbounded agents)
   Centralized execution, scoped connectivity per workflow or app, and fast revocation with proof it occurred.
3. Evidence you can take to auditExportable evidence packages, integrity guarantees, and privacy-aware retention aligned to workflow risk.

Closing

Zero Trust significantly improved how we decide who can begin a session. But in the agentic era, the biggest failures often happen after login. When sensitive content renders broadly, and when agents can act inside sessions faster than humans can supervise, enterprises need controls that operate at the true control point: rendering and interaction.

The practical model is:

• Secure Rendering (prevent overexposure before content appears)
• Bidirectional Session Governance (control what can be sent back)
• Evidence-grade Auditability (integrity-protected records and chain-of-custody proof)

Download the white paper: Zero Trust Still Leaks Trust: Why Agentic Automation Needs Secure Rendering and Evidence-grade Controls