AI Security Risks for Business: The Shift From What Employees Paste to What Agents Can Do

The AI security risks a business faces have changed category over the past year, and most policies are still written for the old one. The familiar problem was disclosure: an employee pasting customer records or source code into a public chatbot. That has not gone away. It is no longer the thing most likely to cause your worst day. The newer problem is authorization. AI assistants now hold credentials, connect to file stores, ticketing systems, mailboxes, and code repositories, and take actions without a person reviewing each one. Cisco’s State of AI Security 2026 found that under a third of organizations feel prepared to secure agentic deployments, which means most of the rest are running systems they cannot fully monitor. We recommend you treat this as an identity and access problem rather than a content filtering problem, because the control that decides your exposure is what the agent is permitted to do, not what the user typed.

Overview

• Disclosure risk is now the easy half. Data classification and enterprise agreements with no-training terms handle most of it.
• Authorization risk is the harder half. An agent with broad tool access is a privileged account that nobody provisioned or reviewed.
• Prompt injection is a delivery mechanism, not a category. It matters because of what the model is connected to, not because of what it says.
• Shadow AI moved from browser tabs to integrations. Teams now connect tools to production systems without security review.
• You cannot govern an inventory you do not have. Every control below depends on knowing which AI systems exist and what each can reach.

The 5 Why’s

This is written for IT directors, security leads, and CISOs at mid-market and enterprise organizations where AI adoption has already happened, usually faster than governance did. The typical situation is a Microsoft 365 environment with Copilot enabled, developers using AI coding assistants, a handful of departments running their own tools, and no current inventory of any of it.

The pressure differs by sector but arrives at the same place. Healthcare organizations face protected health information flowing into tools whose data handling terms nobody read. Financial services firms carry examiner expectations about third-party risk and model governance. Legal and professional services firms hold client confidentiality obligations that predate any of this technology. Manufacturers and defense suppliers face controlled unclassified information moving into systems that sit outside an assessed boundary, which turns an AI tool choice into a compliance boundary question. Organizations selling into the European market carry obligations under the EU AI Act, where the transparency requirements under Article 50 took effect in August 2026 even though the heavier high-risk obligations were deferred to late 2027 and 2028 by the Digital Omnibus.

The trigger is usually discovery rather than incident: a security questionnaire from a client, an audit request for an AI inventory, or a review that surfaces integrations nobody approved.

The consequence is not primarily a leaked prompt. It is an autonomous system holding standing access to production data with no logging that attributes its actions to an identity you can review.

The AI Security Risk Most Businesses Are Still Measuring Wrong

Most AI security programs we review are measuring content and ignoring capability.

The controls are recognizable: a policy telling staff not to paste confidential data into public tools, a data loss prevention rule or two, maybe blocking a list of consumer AI domains at the firewall. Those controls address a user typing something they should not. They do nothing about an agent that was granted read access to a shared drive and now returns documents to whoever asks, because no permission check sits between the request and the retrieval. Netskope’s 2026 reporting describes exactly this pattern as a rising class of violation, where AI systems surface information the requester had no authorization to see, driven by organizations connecting models directly to internal data stores.

This is the gap we look for first during an IT assessment. The question is not what employees are pasting. It is which AI systems hold credentials, what those credentials can reach, and whether anyone would notice an action taken with them.

The second thing programs miss is that prompt injection is not a separate risk to manage alongside the others. It is the delivery mechanism that makes the authorization question urgent. An injected instruction hidden in a document, an email, or a tool description is only as dangerous as the access the model already has. Give a model read access to one mailbox and injection is a nuisance. Give it write access across your ticketing system and file shares and the same technique becomes lateral movement. OWASP published a Top 10 for Agentic Applications in December 2025 alongside its existing LLM list, and the categories that dominate it are about tool misuse and supply chain rather than about model outputs.

The third is provenance. AI tooling is assembled from third-party components: models, libraries, connectors, and tool servers pulled from public sources. Security research through 2026 has documented poisoned tool metadata, exposed servers running without authentication, and vulnerabilities across widely used integration platforms. That is ordinary software supply chain risk wearing new vocabulary, and it belongs in the same program as the rest of your cybersecurity services.

Is Shadow AI Still the Biggest AI Security Risk?

Shadow AI is still the most widespread risk and no longer the most severe one. What changed is its shape. The original version was an employee with a browser tab. The current version is a team wiring an AI tool into a production system through a connector, without a security review, because the integration took twenty minutes.

Usage has grown fast enough to make the inventory problem real. Netskope’s 2026 report describes the median organization moving from roughly a third of employees using AI weekly to close to sixty percent within a year, with prompt volume more than tripling over the same period. Growth at that rate outpaces any approval process that was not designed for it, and unapproved usage persists even where managed tools exist, usually because the managed tool is worse than the free one for the task at hand.

The picture differs in organizations that got ahead of this by licensing good enterprise tooling early. There the remaining shadow AI is narrower and more deliberate, concentrated in engineering teams using specialist tools and in departments with workflows the enterprise tool does not serve. Those cases usually need an exception process rather than enforcement. Organizations under strict data handling obligations sit differently again, since for controlled unclassified information or protected health information the correct default is denial with a documented approval path, and discovery matters more than policy because you cannot enforce a boundary you cannot see.

What we recommend you do about it:

• Discover before you write policy. Egress logs, single sign-on grants, and expense reports will surface most of what is in use, and the results usually reshape the policy you were about to write.
• Audit OAuth grants and connected applications. Users authorizing an AI tool against your tenant is the quiet path by which third parties gain standing access to corporate data.
• License a tool people will actually choose. Shadow AI is mostly a product problem. The approved option has to be good enough to win on merit.
• Publish a fast exception path. A request process with a stated turnaround prevents most workarounds without a single block rule.
• Classify data for AI use in plain terms. Staff need to know which categories may never leave the environment, stated in language that does not require reading a policy document.

What Happens When AI Agents Get Tool Access?

The agent becomes a privileged account, and in most environments it becomes one that nobody provisioned, reviewed, or logged. That is the whole risk in one sentence, and it is why traditional controls do not catch it.

Existing security tooling evaluates traffic, files, and user behavior. It does not evaluate whether a tool call an agent decided to make was an appropriate thing to do. When an agent connected to a mailbox, a database, and a code repository is asked to handle a routine task, it selects tools and acts, and the security stack sees authenticated, authorized activity. Microsoft’s security research through 2026 has documented attacks that work by poisoning the metadata describing available tools, so that the agent’s own reasoning about which tool to use is what gets manipulated. Nothing in that chain looks like an intrusion.

This changes with deployment maturity. Organizations still in pilot, running assistants that read and summarize without write access anywhere, face a much narrower problem and should focus on data handling rather than on agent governance. The risk profile shifts sharply at the point an agent gains authority to write, send, commit, or approve. Regulated environments also need this scoped differently, since an agent operating inside an assessed compliance boundary becomes part of that boundary and inherits its documentation and review obligations. The Center for Internet Security and the National Security Agency both published guidance on agent tool access during 2026, which is worth reading before you design controls from first principles.

What we recommend you do about it:

• Inventory agents as identities. Every agent, connector, service account, API key, and token that lets an AI system reach a resource belongs in your identity inventory.
• Apply least privilege to agents, not just to people. Scope each agent to the smallest set of tools and data it needs, and separate read from write explicitly.
• Require human approval for consequential actions. Sending external mail, moving money, changing permissions, and merging code should not complete without a person.
• Log every tool invocation with an attributable identity. If you cannot reconstruct which agent did what and on whose behalf, you have no incident response path.
• Treat tool servers and connectors as third-party software. Vet them, track versions, restrict them to approved sources, and confirm they require authentication.
• Enforce authorization at the data layer. Retrieval should respect the requesting user’s permissions rather than the agent’s, or the agent becomes a permissions bypass by design.

What Should an AI Security Policy Actually Contain?

An inventory, an approved tool list with data classifications attached, an exception process, agent authorization standards, logging requirements, and a named owner. Six things. Most AI policies we read contain only the second one and a paragraph of caution.

The inventory is the load-bearing item because everything else references it. It should record each AI system in use, what data it touches, what it is authorized to do, which vendor terms apply, and who owns it. Vendor terms deserve attention: whether prompts and outputs are used for training, where data is processed, what retention applies, and whether the agreement is an enterprise one with those commitments in writing or a consumer signup with none of them.

The regulatory overlay depends on where you operate and who you sell to. Organizations with European market exposure should note that the EU AI Act’s phased obligations moved during 2026: the Digital Omnibus deferred the high-risk requirements for Annex III systems to December 2027 and product-embedded systems to August 2028, while the Article 50 transparency duties, including disclosure that a user is interacting with an AI system, took effect in August 2026 as originally scheduled. Reading the deferral as a general reprieve is a mistake several organizations appear to have made. In the United States the picture is set by sector and by state rather than by one statute, so the practical approach is mapping your existing obligations onto AI use rather than waiting for AI-specific rules. Verify current requirements with counsel rather than from any article, including this one.

What we recommend you do about it:

• Start the inventory this quarter, however incomplete. A partial inventory you maintain beats a complete one you never begin.
• Attach data classifications to the approved tool list. Which tool may handle which category of data is the decision staff actually need made for them.
• Read the vendor terms on training and retention. Enterprise agreements and consumer signups differ substantially, and the difference is contractual rather than technical.
• Write the agent authorization standard before you have many agents. Retrofitting least privilege across a deployed fleet costs far more than scoping it at the start.
• Name one owner for AI governance. Split ownership between security, IT, and legal produces a policy nobody enforces.
• Bring AI systems into existing incident response. Tabletop an agent taking an unauthorized action, and find out whether you could detect, attribute, and revoke it.

Where to Start If You Have No AI Inventory

The AI security risks facing a business right now divide cleanly into two problems with different solutions. Disclosure risk, where data leaves your control through a tool nobody approved, responds to classification, enterprise agreements, and giving people a good tool they will choose voluntarily. Authorization risk, where an AI system holds standing access to production data and can act on it, responds only to identity governance, least privilege, and logging. Most organizations have built something for the first problem and nothing for the second, which is backwards relative to the severity.

Start with discovery, because every control depends on it and because the results reliably change the conversation. Pull single sign-on grants, connected application authorizations, egress logs, and expense records, and assemble a list of what is actually running. Then classify each system by what data it touches and what actions it can take, since those two attributes determine everything you do next. Then scope least privilege for anything with write access, and confirm you can attribute an agent’s actions to an identity. Policy comes after that, because a policy written before discovery describes an organization you do not have.

None of this requires slowing adoption, which is the objection that stops most of these programs before they start. It requires knowing what exists and constraining what it can reach.

If you cannot currently list every AI system with access to your data, that is where to begin. Contact Mindcore to request an AI exposure and access review.