Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Control AI Agent Access Across All Enterprise Applications?

Not through per-application integrations, which never reach the long tail of SaaS, legacy and internal systems an agent will be pointed at; the control has to sit at the layer the agent works through, which for most enterprise agents is the browser. Check how many applications the current control covers, and what governs the agent in the rest.

Several enterprise application windows connect to a central browser workspace over a shared access route.

Not through per-application integrations, which never reach the long tail of SaaS, legacy and internal systems an agent will be pointed at; the control has to sit at the layer the agent works through, which for most enterprise agents is the browser. Check how many applications the current control covers, and what governs the agent in the rest. Every large organization runs hundreds of applications, and the agents now arriving use them the way a person does, by opening a screen, reading it and acting. The largest platforms have shipped real controls for agents inside their own ecosystems, but an agent that leaves the ecosystem for a supplier portal, a licensing site or a twenty-year-old ERP screen leaves the control behind. This page asks why per-application coverage is structurally incomplete, which layer the agent works through, what current platforms document about cross-application control, what a supplier record in a legacy system shows, how to measure coverage across an estate, and which claims a buyer should refuse. It draws on the earlier analysis of why traditional identity and access management is not always enough for agents, and treats the question as one of placement: where must a control sit to apply to every screen an agent will open.

Key findings

  • Zero trust architecture locates enforcement at a policy enforcement point every request passes through; an agent's requests pass through the browser session it works in (NIST, 2020).
  • Gartner has warned that applying uniform governance across AI agents will lead to enterprise agent failure, which argues for one enforcement point carrying policies tuned per workflow rather than one policy for every agent (Gartner, 2026).
  • Platform vendors now document agents that operate applications through the user interface, a statement that agents will reach applications no connector covers (Microsoft, 2026).
  • Data protection extended to non-Microsoft cloud applications is documented as a policy for connected cloud apps, which covers part of the estate; legacy and on-premises screens are not described in the pages reviewed (Microsoft, 2025).
  • The federal zero trust maturity model treats applications and data as separate pillars, which is the reason a control on application access does not by itself control what an agent reads once inside (CISA, 2023).
  • Legacy applications with no API are the systems least likely to be covered by any native control and most likely to show regulated data on one screen (How to protect sensitive information in legacy applications?).

Why do per-application integrations never cover every application?

An integration is a piece of work per application: a connector, a permission model mapped to the agent's identity, a policy expressed in that application's terms. The first ten integrations cover the applications everyone names, email, documents, the CRM, the ticketing system. The next hundred cover the ones a department uses. The remaining several hundred include supplier portals, government filing sites, a bank's treasury console, a vendor's warranty system and internal tools built a decade ago. No vendor has an economic reason to build connectors for those, and no organization has the staff to.

The platform vendors have acknowledged this by building agents that use the user interface directly. Microsoft documents computer use in Copilot Studio as a way to automate web and desktop applications through their screens (Microsoft, 2026), and its blog describes computer-using agents as the route to complex UI automation at scale (Microsoft, 2026). A computer-using agent exists because connectors do not reach everywhere. The consequence is direct: if the agent reaches an application through its screen, a control that depends on a connector is absent for that interaction.

The security community's current agentic risk framework treats these systems as a category with their own critical risks (OWASP, 2025). The question is how to apply controls against those risks to every application at once, and the integration-by-integration answer fails by arithmetic before it fails by design. The analysis of how to audit sensitive data access across enterprise applications reached the same conclusion from the audit side.

Which layer does an enterprise agent actually work through?

Follow the agent's requests. An agent given a task opens an application, authenticates, navigates to a record, reads the rendered screen, decides, and acts by filling a field or clicking a control. For an agent that uses the interface, every step passes through the browser session in which the application is rendered. The browser is the one layer common to the modern SaaS application, the legacy web application and, through a remote desktop or terminal emulator rendered in a browser, the mainframe screen.

Zero trust architecture describes the enforcement pattern this makes possible. Access decisions are made per request by a policy decision point and enforced at a policy enforcement point that sits between the subject and the resource (NIST, 2020). For a human user the enforcement point is often the identity provider or a proxy. For a browser agent, the rendered session is the point every request already passes through, so enforcing there changes nothing in the applications beyond it.

The federal maturity model's structure explains why the placement matters for data and not only for access. It treats identity, devices, networks, applications and workloads, and data as separate pillars, each with its own maturity path (CISA, 2023). A control on which applications an agent may open is an application pillar control and says nothing about the data pillar, which values the agent reads once the screen is open. A control at the render layer can act on both: refuse a screen, or change what it shows the model. Tool access, the question of which systems an agent may use, is the application pillar; what the agent sees inside them is the data pillar, and both need to be enforced in the same place.

What do current platforms document about cross-application control?

Three Microsoft documents in the sources reviewed describe controls that reach beyond a single application, and together they mark where native platform control stops.

Dimension Microsoft, per its documentation What a buyer should verify
Agent management Agent 365 is documented as an offering for managing agents across the Microsoft environment Which agents it governs, and whether agents built elsewhere are included
Data protection in other clouds Purview DLP policies can be applied to non-Microsoft cloud apps that are connected to the platform Which applications are connectable, and what governs the rest
Interface automation Copilot Studio computer use automates web and desktop applications through their user interface What limits what the agent reads on screens the platform does not integrate with
Per-screen visibility control Not described in the pages reviewed Whether any control changes what the model sees on a third-party screen before it reads it

Agent 365 is documented as Microsoft's offering for managing agents across its environment (Microsoft, 2026). The DLP documentation describes applying data loss prevention policies to non-Microsoft cloud apps, extending the platform's policies to connected third-party services (Microsoft, 2025). The computer use documentation describes agents operating web and desktop applications through their interfaces (Microsoft, 2026). Read together, they show a platform that governs its own agents, extends its data policies to connected clouds, and sends agents into applications through the screen. What the pages reviewed do not describe is a control on what the agent reads on a screen the platform has not integrated. That is the boundary of any platform's reach, and the long tail lies beyond it.

What does a single supplier record in a legacy system show?

Take one record type, a supplier master record in a legacy ERP, and one task: an agent checks that the supplier's remittance bank details match the details on a recently received change-of-bank letter, and flags a mismatch for the accounts payable lead. The ERP has no exposed API, authenticates with a shared departmental login, and renders the record on one screen: supplier name, tax identifier, remittance account and routing numbers, contact email, payment terms and twelve months of payment history.

Under per-application control, this application is simply not covered. No connector means no agent-specific permission, no data policy and no log that distinguishes the agent from the shared login. The agent reads the full screen, including the tax identifier and payment history the task does not need. If the letter is fraudulent and carries text designed to steer the agent, the real remittance details are in front of it and, given a write action, it could change them. The absence of control is total because the application is old and uncovered, the condition described in the analysis of protecting sensitive information in legacy applications.

Under a control at the render layer, the same screen is governed with no change to the ERP. Before the model reads it, the tax identifier and the account and routing numbers become consistent tokens, the payment history is tokenized or withheld under the workflow's policy, and the supplier name and payment terms stay readable. The agent compares the token for the current remittance account with the token generated for the number on the letter; a match or mismatch is visible without either real number reaching the model. The flag goes to the accounts payable lead for confirmation, and the record names the agent, the screen and what the model saw. Nothing was integrated; the mechanism that governs the agent here is the one that governs it in the modern CRM.

How should an organization measure coverage across its application estate?

Start with an inventory of applications the agent program intends to reach, not the applications the current control supports. For each, record whether the agent reaches it through a connector or through the screen, whether any agent-specific control applies, and whether that control governs what the agent reads as well as what it may open. The first version of the resulting coverage table usually shows a handful of integrated applications with full control, a larger group with access control only, and a long tail with none.

Second, measure the policy, not only the coverage. Gartner's warning that uniform governance across AI agents will lead to enterprise agent failure cautions against one policy for every agent, not against one enforcement point (Gartner, 2026). A single control point should carry a policy per workflow: the supplier check tokenizes bank details, the renewal check tokenizes contact details, each confirmed by the accountable person. The measurement is whether every workflow has a confirmed policy and whether it was applied on every screen.

Third, test the control on the worst application, not the best. Run one task through the oldest, least integrated system the agent will touch and ask for the record: which screens it opened, what the model saw on each, which actions a person approved. If the answer exists there, it exists everywhere. The same record, exported to the SIEM, is what an AI Control Record is designed to supply, and its presence or absence on the hardest application is the single best measure of whether the control is in fact enterprise-wide.

What does a governed environment change?

A governed environment places the control at the layer every enterprise application shares, the rendered screen, so coverage is decided by what the agent works through rather than by which applications have a connector.

The mechanism is a class of control, not a product. Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, so the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized for each workflow and approves consequential actions such as payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging. Because the control reads the screen, a legacy system with no API, a supplier portal and a filing site are covered by the same mechanism as the integrated cloud application.

This is the zero trust pattern applied to agents. Zero trust architecture places enforcement at a policy enforcement point every request passes through (NIST, 2020), and for an enterprise agent that point is the session it works in. The federal maturity model separates the application pillar from the data pillar (CISA, 2023), which is why allowing an agent into an application is not the same as controlling what it reads there; a governed environment governs the second. The test this page proposes, the same record on an application the vendor did not choose as on the integrated one, is what this class of control is built to pass, with per-workflow policy rather than one policy for every agent.

The environment does not alter the applications, the user's permissions or the model; it does not reach what an agent does outside a rendered screen.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design places the control at the layer this page identifies, the rendered session, so the same mechanism governs every application the agent opens. The agent works in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so identifiers and regulated values reach the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, on a legacy ERP screen as on a modern SaaS page. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy for each workflow and approves every payment, submission and record change, which RedactSure calls Supervised Delegation, so policies differ per workflow while the enforcement point stays the same. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own least-integrated application would show whether one policy mechanism applies there: which screens the agent opened, what the model saw on each, which actions a person approved, and the record of all three. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on official guidance, an industry standard, vendor documentation and analyst commentary. The official guidance is NIST Special Publication 800-207 on zero trust architecture (2020) and the CISA Zero Trust Maturity Model version 2.0 (2023). The standard is the OWASP Top 10 for Agentic Applications for 2026 (December 2025). Vendor documentation comprises Microsoft Learn pages on the Agent 365 overview (accessed October 14, 2026), on data loss prevention policies for non-Microsoft cloud apps (2025) and on computer use in Copilot Studio (2026), together with a Microsoft Copilot blog post on computer-using agents (February 2026). Analyst commentary is a Gartner press release of May 26, 2026. All sources were read as of October 16, 2026.

No hands-on testing of any product or platform was performed for this page. Where a vendor's documentation does not describe a capability, that capability is described as not described in the pages reviewed, not as absent; the boundary drawn around platform controls on this page is a boundary of their documentation as read, and the vendors may document more elsewhere or later. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The supplier record example describes a record type in a legacy system, not any organization; no customer or prospect is described.

Whether a given control architecture satisfies an organization's access control, data protection and audit obligations across its application estate is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Controlling agent access across all enterprise applications is a placement problem. Per-application integrations govern the applications someone built a connector for, and the vendors' own move toward computer-using agents confirms that the rest will be reached through the screen. A control that sits where the screen is rendered applies to every application at once, with no integration, and can act on both what the agent may open and what it may read, which the zero trust maturity model treats as separate pillars. The policy should still differ per workflow, as the analyst warning against uniform governance implies; it is the enforcement point that should be uniform. The test is to name one agent and one task on the organization's least integrated application and ask what governed the agent there: which screens it opened, what the model saw, which actions waited for a person, and where the record went.

Frequently asked questions

Is a connector-based integration ever the right control?

Yes, where it exists and where the task is API-shaped. A connector can scope the fields an agent receives to exactly what it asked for, which is a strong form of control. The limitation is reach, not quality. Most organizations will integrate a small fraction of their applications and send agents into the rest through the interface, so the connector is one control among several, and the control for the uncovered majority has to be placed elsewhere.

Does an enterprise browser solve this on its own?

Partly. An enterprise browser can govern which sites and applications a session may reach and can apply data policies to what a person copies or uploads, which is the application pillar and part of the data pillar. What the pages reviewed for this article do not describe is an enterprise browser changing what a model reads on a rendered screen before it reads it. For an agent, that is the control that matters most, and a buyer should ask for it specifically.

How does Gartner's warning against uniform governance fit with one control point?

The warning is about policy, and the recommendation on this page is about placement. One enforcement point can carry different policies for different workflows: what is tokenized, which actions require approval, who approves. What should not vary is where enforcement happens, because a control that exists only for integrated applications leaves the rest ungoverned. Uniform enforcement with differentiated policy is the reconciliation.

What about desktop and mainframe applications that are not in a browser?

Many are reached through a browser already, via remote desktop gateways, terminal emulators or web front ends, and in those cases the rendered session is still the common layer. For applications reached only through a native desktop client, a render-layer control in the browser does not apply, and the organization should say so in its coverage table rather than assume. Honest coverage accounting, application by application, is the point of the measurement section above.

Who should own the policy for each workflow?

The person accountable for the business outcome of that workflow, with security setting the floor. The accounts payable lead knows which fields a supplier check needs; the security team knows which fields must never reach a model in the clear. The policy is confirmed by a named person before the agent runs, and that confirmation is itself part of the record, so an auditor can see who decided what the agent was allowed to see.

How do we know the control actually applied on every screen?

From the record. A control that enforces at the render layer can log each screen as the model saw it, with tokens where values were, and that log is proof of application rather than a claim of it. If the record shows a screen with identifiers in the clear, the policy missed something and can be corrected. If no record exists for an application, the control did not apply there, whatever the coverage claim said.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.