Skip to content
redactsure
Book a demo

Explore.

Guide · By Chris Sowa · Published
Last updated

How to Reduce Shadow AI Agents Across Your Enterprise: Why Bans Fail and What Replaces Them

Replace the ban with a sanctioned path that clears the queue faster, with one named person per agent; 62% of organizations are experimenting with agents and 23% scaling them.

Scattered browser windows converge on a gated workspace and ordered activity ledger.

62% experimenting · 23% scaling · 1 named person

McKinsey's State of AI survey finds 62% of organizations experimenting with AI agents and 23% scaling them (CX Today, 2026). The 39 points between those numbers is where shadow agents hide. Staff in that gap have a queue and an agent that clears it, and you have no name and no record.

You probably answered with a block on the vendor domains. That is the Roman answer to a river: an edict against the water, which finds another channel. An agent with its own cloud computer never crosses your perimeter, and an agent in a personal browser reads the screen regardless. A ban produces invisibility, not safety.

Shadow agents shrink when the sanctioned path is faster than the shadow one, and that path is a governed environment where a named person owns each agent, the model receives the task's fields with identifiers as tokens, and every consequential action waits for that person on the record.

The person who ran the shadow agent keeps the same screens and login. The organization gains a name on the agent, a record in its SIEM, and one standing rule: no agent operates without a named person accountable for it.

A firewall block never reaches an OpenAI dot's own cloud computer

OpenAI's dots are always-on agents, each with "its own cloud computer and browser," connecting to more than 4,000 apps through plugins (The Next Web, 2026). A domain block changes nothing about where that computer runs or what it reads.

What the model receives on a dot is the page: webpage text and document content within connected apps (OpenAI, 2026). Custom Rules set what a dot may do alone and what needs approval, and Auto-review checks planned actions before execution (OpenAI, 2026). Both govern acts. Neither governs what the model saw on the way to the act.

So the block catches the staff who would have asked anyway. The rest carry on, with one more reason not to tell you, and your network logs show vendor domains and nothing about what the agent saw. The fix is not a longer blocklist. It is a path where you own the computer, the policy and the record.

3 places an agent can run, and only 1 changes what the model receives

Claude in Chrome screenshots the active tab, and "all visible information, including personal data" becomes part of the context; its default approves actions automatically with a pause on risky ones (Claude Help Center, 2026). A dot works on its own cloud computer (OpenAI, 2026). Muse for Small Business connects to Shopify, Stripe, QuickBooks and Slack, free with usage limits (TechCrunch, 2026).

Property Agent in the employee's own browser Agent on a vendor cloud computer Agent in a customer-owned governed environment
Where it runs The employee's device The vendor's infrastructure A secure virtual machine you own
What the model receives The visible screen in full The page and connected documents in full The task's fields with identifiers as tokens
Who approves consequential actions The user, often automatically by default The user, per rules the user set A named person, on the record
Where the record lives The vendor's activity view The vendor's activity view Your SIEM
Who holds the keys The vendor The vendor Your organization

Only the third column changes the read itself. That is Least Exposure: the principle that for each piece of work, the AI receives exactly the data the task requires and nothing more, enforced before any model reads the screen. Permissions do not move; what changes is what the AI can see.

Gartner's May 2026 finding: one policy for every agent ends in failure

Gartner's May 26, 2026 release says applying uniform governance across AI agents will lead to enterprise AI agent failure (Gartner, 2026). One policy loose enough for a memo drafter is far too loose for an agent that moves a payment; one tight enough for the payment agent sends the memo drafter back into the shadows.

The unit of governance is the task, not the agent and not the vendor. Each sanctioned workflow gets a per-task exposure policy: which values reach the model as tokens, which stay in clear, which actions wait for a person. On a benefits screen the model sees SSN_001 and ACCT_001 while amounts and dates stay in clear. On a student record it sees STUDENT_001.

A planner writes that policy from the screens the workflow touches, and a named person confirms it before the first run. The shadow agent started this morning; the sanctioned path has to be ready this week.

The NIST Govern function asks for one accountable name per AI system

The NIST AI Risk Management Framework's Govern function asks the organization to assign accountability for each AI system (NIST, 2023). OMB M-24-10 requires human oversight for rights- and safety-impacting uses (OMB, 2024). A shadow agent fails both the same way: ask "who is the named person" and nobody answers.

The replacement is Supervised Delegation: a named person grants the access, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every consequential action, on the record. That person's agent is a tethered agent: an agent that works only inside the governed environment a named person connected it to, on the applications that person chose.

Microsoft's AI Red Team catalogs failure modes that arise from an agent's own reasoning and tool use (Microsoft, 2025), and Anthropic's agentic misalignment work shows models acting as insider threats under pressure (Anthropic, 2025). The tether and the approval line hold whichever model is behind the agent.

4 responses to shadow AI compared, and only 1 restores the inventory

Property Ban vendor domains Permit agents in the browser Enterprise model contract Governed environment with a named person
Reaches a vendor cloud computer No No No Not needed; the agent runs in your environment
Changes what the model receives No No No Yes, identifiers as tokens
Puts a person before consequential actions No Only if the user sets it No Yes, by policy
Record in your SIEM No No No Yes
Effect on shadow use Pushes it out of sight Visible, not safe Governs where data may go, not what is seen Replaces it

An enterprise contract governs where data may go. It does not decide what the model receives from a screen or put a name in front of a payment. Those decisions belong in an environment you own, under separation of model and control: the principle that the environment deciding what an AI agent sees and who approves what it does is owned by the customer and independent of whichever model performs the work. The vendor that is the model should not also be the judge of the model.

The ban's worst cost is that you stop learning what agents do. The fourth column restores that through an AI Control Record: the record of every screen the agent saw as tokens, every action, every approval with a name, exported to the customer's own monitoring. The control record lands in your SIEM and becomes the inventory.

Greshake showed in 2023 that the page itself can give the agent orders

0.08% reported attack success · 2 classifiers · 1 page received in full

Greshake and colleagues showed that an LLM-integrated application can be hijacked by instructions planted in the content it reads (Greshake et al., 2023). OWASP lists prompt injection first and sensitive information disclosure second among its 2025 risks (OWASP, 2025; OWASP, 2025).

Anthropic reports attack success under 0.08% in internal testing for Claude in Chrome, with one classifier screening content and another evaluating each action (Claude Help Center, 2026). They still describe a model that received the whole screen. Whatever the classifier misses held the real Social Security number.

Render-layer tokenization changes what a successful injection can collect: replacing sensitive values with consistent stand-in tokens at the point where a screen is rendered, before any AI model reads it, so the model works with SSN_001 and ACCT_001 and real values resolve only at approved destinations at the moment of action. An injected page collects tokens, and the action it tries still stops at the named person.

This also dissolves the PII Wall: the point in an AI program where the valuable workflow turns out to run on data the security team will not let a model see, and the project shrinks or stops.

6 Rules for replacing shadow agents with a sanctioned path

Find the work before you find the tools

Ask the people doing the work which queues an agent is clearing for them, and make the answer safe to give. Nobody confesses to a blocklist; people do answer "which queue should we make faster?" List each workflow, its applications and the person who runs it.

Before: Network logs show a list of vendor domains and no workflows. After: A list of workflows, each with a system list and one name.

Rank workflows by the identifiers on the screen, not by the vendor

Open the screen the shadow agent works and write down what is on it. The vendor matters less than whether the screen carries the values that become SSN_001, PATIENT_001 or CARD_001 on the sanctioned path.

Test: Name the identifiers on your top three workflows' screens from memory. If you cannot, you have not ranked them.

Stand up the governed environment before you announce the policy

Deploy a customer-owned secure virtual machine with keys your organization holds, a render layer that tokenizes each screen before any model reads it, a planner for per-task policy, and an export to your SIEM. The agent works the screens the person already works, with no integration.

Ready Not ready
Your organization holds the keys The vendor holds the keys
The model's stream shows SSN_001 on a test screen The stream shows the real number

Name the person before the first run

One name per workflow, on the policy confirmation. That person connects the agent to the environment, chooses its applications and confirms what is tokenized.

Test: Pick any sanctioned agent and ask "who is the named person." The answer is a name.

Make every consequential action wait

Payment, submission, record change, message, key: each waits for the named person, who watches the same tokenized stream and can pause or take over. "Always allow" is the setting that made the shadow agent a shadow.

Before (illustration): Payments ran on a rule the clerk set for herself, with no named approval. After: Every payment has an approval line with a name on it.

Measure the path the way staff measure it, then write the rule

Did the queue clear at least as fast as with the shadow agent? If not, staff go back. Then write the standing rule into policy.

Policy clause Evidence that it holds
One named person per agent Each confirmed policy carries a name
Consequential actions wait Each has an approval line in the SIEM
Model receives tokens Screens in the record show SSN_001, not numbers

How to choose the sanctioned path for a workflow

  • If the screen carries no identifiers and the agent takes no consequential action, an agent in the employee's browser is acceptable, with a named person.
  • If the screen carries an SSN, card, patient or student identifier, the workflow runs only in the governed environment with those values as tokens.
  • If the agent pays, submits, changes a record or sends a message, each action waits for the named person.
  • If staff already run the workflow on a vendor cloud computer, move the agent and keep the work.
  • If the work is rights- or safety-impacting under OMB M-24-10, require the human oversight record before the first run.
  • If you hold an enterprise model contract, keep it for data handling and add the governed environment for exposure and approval.

The checklist

Check Pass Fail
Workflow inventory Each workflow lists systems and a name A list of vendor domains
Screen reads The model's stream shows SSN_001 where the screen shows a number The model receives the screen in full
Named person Every sanctioned agent answers "who" with a name "The team" or "the vendor"
Approval lines Each consequential action has a named approval line in the SIEM Approvals exist only in the vendor console
Key custody Your organization holds the environment's keys The vendor holds them
Injection test A planted instruction collected only tokens and its action stopped at the person The action ran or real values left
Speed The path clears the queue at least as fast as the shadow agent Staff report it is slower
Retirement The unregistered agent is no longer used for that workflow Both paths run side by side

Questions

Does blocking ChatGPT and Claude at the firewall reduce shadow agents?

It reduces the ones that would have asked permission. A dot runs on OpenAI's infrastructure with its own cloud computer (The Next Web, 2026), so a network block changes nothing about where it runs. The block produces invisibility, not safety. What reduces shadow agents is a sanctioned path that works the same screens faster, with a named person per agent and a record in your SIEM.

How do we find the agents already running?

Ask the people doing the work, and make the answer safe to give. Staff set up an agent to clear a queue, not to break a rule. Offer a governed environment for that queue with no integration wait and the answers become candid. Network logs show vendor domains, not what the agent saw. After that, the AI Control Record is the inventory.

Who is accountable for an agent an employee set up alone?

Nobody, in a form you can act on, which is the gap NIST's Govern function names (NIST, 2023). The fix is the rule: no agent operates without a named person accountable for it. That person grants the access, chooses the applications, confirms what is tokenized and approves every consequential action, on the record. An agent with no such person is out of policy, whichever vendor built it.

Does an enterprise contract with one model vendor solve it?

No. A contract governs where data may go and what the vendor may do with it. It does not decide what the model receives from a screen or put a named person in front of each consequential action. Keep the contract for data handling and add a customer-owned environment for exposure and approval, so the model can be any vendor's and the controls stay yours.

Should staff keep the agents they already set up?

Keep the work, move the agent. A governed environment can run a capable agent of any vendor inside it, including Claude Code or Claude Cowork for operational tasks. What changes is where it runs, what the model receives and who approves. The person keeps the same screens and login; you gain a name on the agent and a record in your SIEM.

Do a dot's Custom Rules and Auto-review make it safe to allow?

They govern acts: OpenAI describes them as checks on planned actions against the user's rules before execution (OpenAI, 2026). They do not change what the model received, which is the page in full, and the rules are the user's, not yours. A sanctioned path adds what they lack: tokens before the model reads, and an organizational approver on the record.

Is a free small-business agent a shadow agent in a school or clinic?

Yes, if nobody at the organization is named for it. Muse for Small Business connects to Shopify, Stripe, QuickBooks and Slack and is free with usage limits (TechCrunch, 2026), which lets one office adopt it without telling IT. The test is the same as for any agent: who is the named person, what did the model receive, where is the record.

Methodology

What this page rests on. Vendor documentation from OpenAI (the dots safety post, September 29, 2026) and Anthropic (the Claude in Chrome safety guidance), read as of October 9, 2026. Research cited for the finding each is known for: Greshake et al. (2023, preprint), the Microsoft AI Red Team taxonomy (2025) and Anthropic's agentic misalignment report (2025). Figures from CX Today, Gartner, NIST, OMB and OWASP.

What was not tested. No hands-on testing of the named products was performed for this page. Product behavior comes from each vendor's published documentation, which changes with releases; this page carries its date. No specific organization is described; the before and after figures in the rules are illustrations.

Whose determination it is. Whether a workflow is rights- or safety-impacting, whether a tokenized read meets a data-minimization standard, and whether a control record satisfies an auditor are determinations for the organization's counsel, its assessor and its security and compliance officers.

How RedactSure does this

RedactSure runs AI co-workers inside a governed environment the customer owns: a secure virtual machine in the cloud the customer's posture requires, on hardware-encrypted enclaves, with keys the customer holds. It works the organization's existing applications with no per-application integration and no change to user permissions.

Every identifier chosen by policy is replaced by a consistent token at the render layer before any model reads the screen, so the model receives the task's fields with identifiers as tokens. The Planner writes the per-task policy and a named person confirms it before the run, then approves every payment, submission and record change while it runs: Supervised Delegation. Every screen as tokens, every action and every approval with a name lands in the AI Control Record and exports to the customer's SIEM.

The environment is model-agnostic: Claude, GPT, Gemini or an open-weights model, swappable without moving the controls. Prompt injection that succeeds collects tokens, and the consequential action still stops for a named person. Deployments are in pilot.

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.