Skip to content
redactsure
Book a demo

Explore.

Explainer · By Chris Sowa · Published
Last updated

What Is a Shadow AI Agent and How Can It Access Customer Data Without Security Knowing?

A shadow AI agent is an AI system that an employee has connected to company applications and allowed to act on their behalf, without the security team approving it or knowing it exists. It reaches customer data through the employee's own permissions, so access logs show a person, not an agent, and nothing looks wrong until something is.

A computing module connects enterprise application records to an unapproved boundary crossing.

A shadow AI agent is an AI system that an employee has connected to company applications and allowed to act on their behalf, without the security team approving it or knowing it exists. It reaches customer data through the employee's own permissions, so access logs show a person, not an agent, and nothing looks wrong until something is. The question matters now because the agents on offer in 2026 are built to connect and act, not only to answer: an always-on agent with its own cloud computer and thousands of app plugins, a business agent wired into the accounting stack, a browser extension that reads whatever tab is open. Each is a few clicks from a customer record, and each is invisible to a program that inventories software and watches network exits. The alternative is a tethered agent, one that works only inside the governed environment a named person connected it to, on the applications that person chose. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • OWASP lists Excessive Agency as LLM06 in its 2025 Top 10 for LLM Applications: an LLM-based system given more functionality, permissions or autonomy than the task requires, so that a bad output turns into a damaging action (OWASP, 2025).
  • OpenAI's Dots are always-on agents that each run on their own cloud computer and browser and can connect to more than 4,000 apps through plugins; the first dot is free in Pro and Business Premium plans (The Next Web, 2026).
  • Meta's Muse for Small Business connects to Shopify, Stripe, Intuit QuickBooks, Slack, Asana, Notion, Dropbox, Box and other business systems, with custom connectors, free with usage limits (TechCrunch, 2026).
  • Claude in Chrome takes screenshots of the active tab, and all visible information, including personal data, becomes part of the model's context (Anthropic, 2026).
  • A catalog of 93 machine-learning security threats drawn from MITRE ATLAS, the AI Incident Database and the literature finds prompt injection and data exfiltration among the dominant tactics, concentrated at inference time, the stage at which a shadow agent operates (Foundjem et al., 2026).
  • McKinsey's State of AI 2026 reports 62 percent of organizations experimenting with AI agents and 23 percent scaling them anywhere, which leaves a large population of agents in use before any program governs them (CX Today, 2026).

What separates a shadow AI agent from ordinary shadow AI?

Shadow AI, in the sense most security teams already track, is an employee pasting a customer email into a public chatbot. The data leaves once, through a prompt box, and the exposure ends when the chat does. A shadow AI agent is a different object. It holds a standing connection to one or more company systems, reads from them without a person pasting anything, and writes back: send the message, update the record, file the form, move the money. The exposure is continuous, and the agent's reach is the employee's reach.

Three properties make an agent "shadow" rather than merely unapproved. It is connected: it has a path into an application through a consent screen, an API key, a plugin or a browser session. It acts: it may take steps on its own, with or without a prompt for each one. And it is unrecorded: no inventory entry, no policy about what it may see, and no record of what it did that can be separated from the employee's own activity.

The agents being sold today meet all three by design. OpenAI describes Dots as agents a user assigns work to by chatting through text, Slack and Microsoft Teams, each with its own cloud computer and browser (The Next Web, 2026). Meta describes Muse for Small Business as an agent that knows what a business sells and what customers ask about most (TechCrunch, 2026). These are legitimate products with published safety designs. They become shadow agents the moment an employee connects one to a work account the security team never reviewed. The question is no longer "which AI tools are people using?" but "which systems have people connected an agent to, and what can it do there?"

How does a shadow agent get into company systems?

There are three doors, and none of them requires anyone to defeat a control. Each one uses a mechanism the organization built for legitimate reasons.

Door How the agent gets in What it inherits Why security does not see it
Consent grant The employee approves a third-party app's request for mail, files, calendar or CRM access on the identity provider's consent screen The scopes approved, usually whole mailboxes or drives rather than one task Recorded as one user consent among thousands, with the app name and nothing about what it will do
API connector or plugin The employee pastes an API key or signs in through a vendor's connector to a finance, ticketing or messaging system The permissions of the account whose key or login was used Traffic arrives as that account, from the vendor's cloud, and looks like any other integration
Browser or computer-use agent The employee installs an extension or desktop agent that reads the screen and operates applications through the interface Everything the employee's open sessions can display, with no integration at all No new account, token or network path; the agent's clicks are the employee's clicks

The consent door is the quietest. A consent screen that asks for access to mail and files grants a standing path, and the app's author sets the scopes, not the task; the page on API connectors and Least Exposure works through why those scopes are almost always wider than any one piece of work.

The connector door is the one the new business agents open. Muse for Small Business lists Shopify, Stripe, QuickBooks, Slack, Asana, Notion, Zoom, Dropbox and Box among its connections, plus custom connectors (TechCrunch, 2026). Dots reach more than 4,000 apps through plugins (The Next Web, 2026). The user makes the connection with the user's own credentials, and the agent runs on the vendor's cloud.

The browser door needs no connection at all. Claude in Chrome takes screenshots of the active tab and places all visible information, including personal data, into the model's context (Anthropic, 2026), and ChatGPT Work's Computer Use operates the person's computer across applications (PPC Land, 2026). An employee who installs either and opens a customer record has created a shadow agent with the full reach of their own screen, and the identity system has no event to show for it (should an agent run in the employee's own browser?).

How can it reach customer data without security knowing?

The agent does not reach customer data in spite of the security program. It reaches it through the parts of the program that are working. Three mechanisms explain why.

The first is inheritance. An agent connected through any of the three doors operates with the permissions of the person who connected it. NIST's zero trust architecture frames access as a per-request decision about a subject and a resource (NIST, 2020), and in every one of these cases the subject presenting the request is the employee, authenticated and authorized. The agent is not a new subject the policy engine can evaluate; it is a new consumer of an existing subject's access, and the policy engine cannot tell the difference (does least privilege cover what an AI sees?).

The second is the logging blind spot. Access logs record who opened a record. They do not record that a model read every field on it, summarized it, and carried the summary into the next step. A screen-reading agent is the clearest case: the model receives the whole rendered page, including the fields the task never needed (what an agent sees when it takes a screenshot). The log shows a record view by a named user at a timestamp. It is accurate, and it is useless for the question security needs to ask.

The third is location. For Dots and the Muse agents, the work happens on the vendor's cloud computer, not on a device the organization manages. OpenAI states that the model sees webpage text and document content within connected apps, the page in full, and refers key holder and data location to a system card (OpenAI, 2026). Meta gives each user a dedicated secure VM with a Chromium browser and a Sentinel that approves every network egress, and the agent reads the page in full (Meta AI Research, 2026). Both are serious designs. Neither is visible from inside the customer's security stack, which watches endpoints and exits the organization owns.

Customer data therefore moves from the application, through the employee's permissions, into a model on a third party's computer, and every control in the path reports normal activity. OWASP's LLM02, Sensitive Information Disclosure, names the model as the place where that data is now processed, repeated and carried forward (OWASP, 2025).

Why is an agent that acts more dangerous than one that only reads?

A chatbot that has read a customer record can disclose it. An agent that holds a connection to the CRM, the mailbox and the payment system can also send it, change it or spend against it. OWASP's LLM06 entry describes Excessive Agency as the vulnerability that lets damaging actions follow from unexpected or manipulated model output, with three root causes: excessive functionality, excessive permissions and excessive autonomy (OWASP, 2025). A shadow agent typically has all three, because nobody scoped the plugins, nobody trimmed the consent, and nobody set a rule about what needs a person's approval.

The manipulated-output case is the one to worry about. Greshake and colleagues showed in 2023 that instructions placed in content an LLM-integrated application reads, a web page, an email, a document, can redirect the application without the user typing anything (Greshake et al., 2023). An agent that reads customer email reads attacker-reachable content all day. OWASP ranks that pattern, Prompt Injection, first in the 2025 list (OWASP, 2025). The Foundjem catalog of 93 distinct threats finds prompt injection, data exfiltration and jailbreaking dominant and concentrated at inference, where a deployed agent does its work; it also finds that larger, better-calibrated models can be more vulnerable to certain introspection-driven jailbreaks, which cuts against the hope that a newer model will take care of it (Foundjem et al., 2026). Microsoft's AI Red Team catalogs failure modes particular to agentic systems, including failures that arise from the agent's reach into tools and memory rather than from the model alone (Microsoft AI Red Team, 2025).

The vendors say as much. OpenAI's safety page for Dots describes Custom Rules for what a dot may do on its own, Auto-review of planned actions before execution, and the statement that dots can still make mistakes, so consequential work should always be reviewed (OpenAI, 2026). The user who connected the agent sets those safeguards, not the organization whose customer data it reads. MIT Technology Review's critique of model refusal makes the general point: refusal and classifiers are stacked layers, each with holes, and a consequential action needs a control the model cannot talk its way past (MIT Technology Review, 2026). In a shadow deployment, that control is whatever the employee left switched on.

How are shadow agents found, and what replaces a ban?

Shadow agents are hard to see from the network and easier to see from the places they touched to get in. Each door leaves a trace in a system the organization already owns. Consent and application registrations in the identity provider list every third-party app granted access to mail, files or connected SaaS, with its scopes and the users who approved it; sorting by recency and scope breadth surfaces agent plugins, which tend to ask for read and write access to whole mailboxes. API keys and personal access tokens are the second trace: a key created recently, used around the clock from a cloud provider's address range, and belonging to an individual rather than a service account is the signature of a connector-based agent. Browser extensions and desktop agents are the third, found in endpoint and browser management; the Claude in Chrome permissions guide describes organization-level allowlists and blocklists (Anthropic, 2026), which help only once the extension is known to be present. The pages on tools that discover and secure agents and finding the shadow AI nobody told you about cover the tooling.

What happens after discovery matters more. The reflex is to block the vendors' domains, revoke the consents and remove the extensions. That buys a quiet week. The work that drove the employee to the agent remains, and a ban produces invisibility, not safety (Does Banning AI Tools Work?). Gartner adds a second constraint: uniform governance across AI agents will lead to enterprise AI agent failure (Gartner, 2026), because one rule for every agent is too loose for the one that pays invoices and too tight for the one that drafts replies.

The replacement has four parts: an inventory maintained from the three traces above; a sanctioned path, so an employee who needs an agent gets one the organization governs (How to Reduce Shadow AI Agents Across Your Enterprise); an exposure decision per task, so the agent receives the fields the work needs with identifiers as tokens rather than the whole record; and a record of each run that separates what the agent did from what the person did. The tethered agent makes the sanctioned path safer than the shadow one rather than merely more permitted: a named person connects it, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every consequential action, on the record.

Where does RedactSure sit?

RedactSure supplies the sanctioned path. AI co-workers do real work across an organization's existing applications inside a governed environment, with no per-application integration and no change to user permissions, so there is no consent grant, no API key and no extension on the employee's browser. Every identifier chosen by policy is replaced by a consistent token at the render layer before any model reads the screen; the model receives the task's fields with identifiers as tokens, such as SSN_001 and ACCT_001, rather than the customer record in full. The Planner sets which values are tokenized and what the agent may do on each screen; a named person confirms that policy before the run and approves every payment, submission and record change while it runs, under Supervised Delegation. Real values resolve only at approved destinations at the moment of an approved action.

Every screen as tokens, every action and every approval with a name lands in the AI Control Record and exports to the customer's own SIEM, which answers the discovery question for governed agents before it is asked. The environment runs in the customer's cloud with keys the customer holds and is model agnostic. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page is a definitional synthesis. It rests on the OWASP Top 10 for LLM Applications 2025, entries LLM01, LLM02 and LLM06 (industry standard), NIST SP 800-207 (2020, official guidance) and Gartner's May 2026 press release on agent governance (industry analysis), all read as of October 13, 2026. Vendor statements about OpenAI Dots, ChatGPT Work, Claude in Chrome and Meta Muse come from the vendors' safety and permissions documentation and dated press coverage of their launches. Research findings come from Greshake et al. (2023, preprint), Microsoft's AI Red Team taxonomy (2025, whitepaper) and Foundjem et al. (ACM TOSEM 2026, peer-reviewed). Adoption figures are McKinsey's State of AI 2026 as reported by CX Today (industry analysis).

No product was tested. No agent was connected, no consent log was audited and no extension inventory was run. Statements about each vendor's design are limited to what its cited documentation says, not to capabilities documented elsewhere or added later; vendor features change, and the page carries its date. The consent, API key and browser signals described are general patterns, not findings from any organization. No customer or prospect is described. Statements about RedactSure are limited to the design facts the company publishes about itself.

Whether a given agent connection is permitted under an organization's policies, contracts or regulatory obligations is a determination for its counsel, its assessor and its security and compliance officers, who hold the consent records, the data inventory and the risk tolerance the determination depends on. The frameworks cited set out risks and practices; they do not certify any product or connection.

What the record shows

A shadow AI agent is not a rogue process that slipped past a control. It is a product an employee connected through a consent screen, an API key or a browser extension, running with that employee's permissions, often on a computer the organization does not own. It reaches customer data through the parts of the security program that work, which is why the program does not see it. An agent that can act turns disclosure into transactions, and nobody scoped what it may do. The test: pull the consent grants, personal API keys and browser extension inventory from the last ninety days and ask, for each new entry, what work it does and who approved the connection. The entries without an answer are the shadow agents.

Frequently asked questions

What is the difference between shadow AI and a shadow AI agent?

Shadow AI is unapproved use of an AI tool, usually a person pasting content into a chatbot; the exposure happens once, per prompt. A shadow AI agent holds a standing connection to company systems, reads from them without anyone pasting, and can act in them: send, update, file, pay. The exposure is continuous, and its reach equals the employee's permissions in every connected application.

How does an agent get access without an admin granting it?

Through the employee. A consent screen lets a user grant a third-party app access to their own mail and files; an API key or connector login carries the user's permissions; a browser or computer-use agent reads whatever the user's open sessions display. None requires an administrator, and all leave the access attributed to the user rather than the agent.

Why do access logs not show the agent?

Because the agent is not a separate identity. It presents the employee's credentials, session or key, so the application records the employee. The log also records that a record was opened, not that a model read every field and carried them into the next step. It is accurate about who, and silent about what the model received.

Are products like OpenAI Dots and Meta Muse shadow agents?

Not in themselves. Both vendors publish safety designs: Dots have Custom Rules and Auto-review, and Muse runs each user in a dedicated secure VM with egress approval. They become shadow agents when an employee connects one to work systems the security team never reviewed, because that employee, not the organization, then configures the safeguards.

What is the fastest way to find shadow agents?

Read three inventories the organization already has: third-party application consents in the identity provider, sorted by scope breadth and recency; personal API keys and access tokens in each major application, sorted by last use; and browser extensions and installed agents in endpoint management. Each door leaves an entry in one of these, and each entry can be matched to a person and a task.

Should the organization ban agent products outright?

Bans produce invisibility rather than safety: the work that drove the employee to the agent remains, and the next agent is harder to find. A better response is an inventory, a sanctioned path inside a governed environment a named person connected the agent to, an exposure decision per task, and a record of each run that separates the agent's actions from the person's.

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.