Bonfy's Shady AI Warning Exposes Security's Next Governance Problem

Bonfy CEO Gidi Cohen has identified a troubling governance gap inside approved enterprise AI systems. Legitimate access no longer guarantees an appropriate outcome.

Cohen calls the problem “shady AI.” The term describes approved AI using authorized data in ways that violate business intent, policy, or customer expectations. Unlike shadow AI, the system itself is not hidden from security teams.

The warning reached a wider audience through security coverage and Google News. Yet the important story is not another catchy cybersecurity label. It is the breakdown of a familiar assumption: approved technology operating with valid permissions is governed technology.

That assumption worked better when software followed predictable instructions. An employee opened a record, changed a field, or exported a document. Security teams could connect the action to a person, permission, application, and timestamp.

AI changes that relationship. A system can retrieve thousands of authorized records, infer connections between them, and generate an outcome nobody requested directly. Every individual access may be permitted, while the combined result crosses a boundary.

This conflict places enterprise security teams between two unsatisfying choices. They can slow AI adoption with strict controls, or permit fast deployment without understanding every downstream use of company data.

Neither choice resolves the central problem. Organizations need controls that evaluate why data is being used, not only whether an application can reach it.

Shady AI Moves the Risk Inside Approved Systems

Shady AI turns an approved workflow into a governance problem without requiring a rogue employee, unknown application, or stolen credential.

Cohen introduced the term while discussing how AI distinguishes relevance from appropriateness. His argument focuses on systems that operate inside approved platforms and intentional workflows.

The user may hold the correct role. The application may have passed a security review. The underlying records may all be available through legitimate permissions.

The resulting action can still conflict with policy. An AI assistant might combine customer communications, contract details, and support history to produce an unauthorized risk profile. Each source appears relevant, but their combined use changes the purpose of the data.

Cohen’s distinction matters because security programs usually treat approval as a major control boundary. Once a vendor, application, integration, and identity pass review, monitoring often concentrates on unauthorized access or suspicious behavior.

Bonfy’s account of the concept says an AI system can retrieve permitted information and still produce an outcome that conflicts with customer expectations. The company describes this as approved AI moving beyond intended boundaries in its summary of the shady AI concept.

That remains a vendor-backed framing, not a recognized regulatory category. No independent body has established “shady AI” as a standard term or measurable class of incidents.

Still, the underlying behavior is real enough to examine. Generative systems can synthesize data across repositories, infer sensitive attributes, and initiate actions through connected tools. Those capabilities expand the meaning of authorized access.

Consider a workplace assistant connected to email, documents, calendars, and customer records. A manager asks it to identify accounts likely to cancel within the quarter.

The assistant could infer financial stress from billing disputes. It could extract dissatisfaction from private support conversations. It might also connect those findings with contract renewal dates and employee comments.

Every source could sit within the manager’s technical permissions. However, the organization may never have approved that combined profiling purpose. It may also lack a record of which factors shaped the recommendation.

This is different from ordinary shadow AI. Shadow AI generally refers to employees using unapproved models, personal chatbot accounts, browser extensions, or unsanctioned agents.

The security problem begins with visibility in those cases. Teams must discover which tools are active, determine what data entered them, and decide whether to block or govern their use.

The Hacker News has described another version of that risk inside approved software. AI features can appear in existing help desks, document systems, and customer platforms after the original vendor review.

Its overview of shadow AI risks argues that vetting software previously does not govern every AI feature enabled later. That observation narrows the distance between shadow AI and Cohen’s newer framing.

The two concepts still describe different control failures.

Shadow AI asks whether the organization knows that a tool or feature exists. Shady AI asks whether an approved system’s behavior remains appropriate for a specific user, purpose, and relationship.

Google News may place both stories under the same broad AI security theme. Enterprise defenders cannot afford to treat them as the same operational problem.

Discovery tools can reveal an unknown chatbot. They cannot automatically decide whether an approved assistant should use a sensitive customer conversation to influence a sales decision.

That decision requires context. It also requires policy that software can evaluate before retrieval, generation, or action.

Why Identity and Access Controls Are No Longer Enough

Identity controls answer who can reach data, but shady AI forces organizations to decide which relationships and purposes make that access appropriate.

Traditional access control grants permissions through roles, groups, resource ownership, and policy rules. A customer support manager might read all cases assigned to a region. A finance analyst might review every invoice for a business unit.

Those controls remain essential. They stop many unauthorized users and applications from reaching sensitive systems. They also create records that investigators can examine after an incident.

However, broad permissions often exist because people need flexibility. A senior employee may access thousands of documents while using only a small subset for each task.

Human judgment supplies an informal second layer. Employees usually understand that access to a customer record does not authorize every possible use of its contents.

AI cannot be assumed to share that understanding. A model optimizes its response using available context, instructions, and learned patterns. It does not inherently know an organization’s unwritten boundaries.

This creates a purpose problem. Data collected for customer support may be technically available to a sales assistant. That availability does not necessarily authorize using emotional language from support calls to adjust commercial treatment.

It also creates a relationship problem. A clinician, lawyer, human resources manager, and system administrator may access the same record under different professional duties.

A conventional permission can represent the resource and user. It rarely captures the complete relationship surrounding each inference an AI might make.

Agents raise the stakes further. An AI agent is software that selects and performs actions through connected tools, rather than only producing text.

An approved agent might read email, query a database, update a customer record, and send a message. Its permissions can be valid at every step.

The combined sequence can still be unsafe. An untrusted instruction hidden inside an email could redirect the agent’s behavior. A broad goal could also encourage excessive retrieval or unnecessary action.

OWASP describes prompt injection as instructions that manipulate a model through direct input or content the model later processes. The impact depends heavily on the system’s available tools and authority, according to its prompt injection guidance.

This threat connects security exploits with governance failures. A malicious instruction can cause an inappropriate action, but unclear policy can produce a similar result without an attacker.

OWASP separately warns about excessive agency, where an AI system has more functionality, permissions, or autonomy than it needs. Its example includes a malicious email directing an agent to search an inbox and forward sensitive information.

Least privilege remains part of the answer. An assistant cannot misuse data or functions it cannot access.

Yet reducing permissions alone has limits. Organizations often deploy AI precisely because it can connect information across systems. Removing every cross-system capability can eliminate the business value that justified deployment.

The harder task is making authorization more specific. A decision should consider the requesting identity, business purpose, data relationship, action, destination, and current context.

For example, a customer service assistant might summarize a complaint for the assigned case. The same assistant should not add health information from that complaint to a marketing profile.

Both actions involve the same identity and underlying data. The difference lies in purpose, audience, and expected use.

This is why shady AI is fundamentally a governance challenge. Security teams can define technical boundaries, but legal, privacy, compliance, product, and business owners must define appropriate behavior.

That shared ownership is uncomfortable. Security organizations prefer enforceable rules, while policy teams often write principles that depend on human interpretation.

AI systems expose the gap between those approaches. A policy that says customer data must be used “appropriately” offers little protection unless the organization converts that word into testable controls.

Google News Is Surfacing a Shift From Access to Intent

The wider security discussion is shifting from discovering AI tools toward governing what approved models and agents do with legitimate access.

The appearance of shady AI in Google News reflects a larger change in enterprise security coverage. The first wave of concern centered on employees pasting sensitive data into public chatbots.

That risk has not disappeared. Personal accounts, unapproved applications, and embedded AI features still create visibility and data-loss problems.

However, approved enterprise deployments now present a more complex question. Organizations are connecting assistants and agents to valuable systems because isolated chat interfaces deliver limited operational value.

The connections create context. They also create authority.

A model connected to a company knowledge base can locate internal information. An agent connected to operational software can act on that information. Governance must therefore cover both interpretation and execution.

IBM’s 2025 breach research found a substantial oversight gap around enterprise AI. Its official release said 13 percent of studied organizations reported breaches involving AI models or applications.

Among those organizations, 97 percent lacked proper AI access controls. IBM also said 63 percent of surveyed organizations had no AI governance policies or were still developing them.

These figures come from vendor-sponsored research and should not define every organization’s risk. They still show why AI security has moved beyond hypothetical model attacks.

The IBM breach findings describe adoption outpacing governance. Shady AI identifies one possible result of that imbalance inside sanctioned systems.

Existing frameworks provide useful foundations. The NIST AI framework organizes AI risk management around governing, mapping, measuring, and managing risk.

NIST also released a generative AI profile that adapts the framework to model-specific risks. It emphasizes documented responsibilities, testing, incident processes, and ongoing measurement.

These practices help organizations move beyond one-time approval. They encourage teams to treat deployed AI as a changing system that requires continuous oversight.

Still, a framework cannot supply each company’s business rules. A bank, hospital, software provider, and university will define appropriate data use differently.

Regulation adds another layer. European Union rules place obligations on providers and deployers based on an AI system’s role and risk classification.

The European Commission says general-purpose model obligations began applying on August 2, 2025. These include documentation and transparency requirements, with additional duties for models classified as presenting systemic risk.

Those rules focus heavily on providers and designated use cases. They do not automatically settle every contextual decision made by an enterprise assistant using authorized internal data.

An organization could satisfy vendor documentation requirements and still deploy an assistant with poorly defined internal purposes. Legal compliance and operational appropriateness overlap, but they are not identical.

The same distinction appears in privacy law. Consent or another legal basis can authorize data processing at a high level. A new inference or combined dataset can still create unexpected consequences.

This is where the phrase “relevance is not permission” becomes useful. A piece of information can improve a model’s answer without being appropriate for that decision.

Search engines and Google News tend to reward simple categories, such as shadow AI, AI agents, and data leakage. Shady AI does not fit neatly into one of them.

It sits across access management, privacy, model behavior, data governance, and business process design. That overlap makes it harder to assign ownership and easier to overlook.

The organization under pressure is therefore not only the security operations center. Chief information security officers, privacy leaders, legal teams, data owners, and application managers all inherit part of the problem.

They need one enforceable view of permitted behavior. Without it, each team can believe another group owns the risk.

The Hard Part Is Turning Policy Into Runtime Decisions

A credible response must enforce context during retrieval and action, not merely publish another acceptable-use policy.

Many organizations began AI governance with lists. One list names approved tools. Another identifies prohibited data. A third assigns application owners and review dates.

Those inventories are necessary, especially for discovering shadow AI. They do not fully address an approved system that produces an inappropriate result from permitted resources.

Shady AI demands controls closer to runtime. Runtime means the moment when an AI receives a request, retrieves information, generates output, or invokes a connected tool.

At that moment, the system has more context than a static approval process. It knows the user, request, selected data, intended destination, and proposed action.

A governance layer can evaluate those factors before allowing the workflow to continue. It can deny access, remove sensitive context, require approval, or limit the available action.

The policy must be specific enough to enforce. “Protect customer trust” is an important principle, but software needs a more precise rule.

One rule might prohibit an assistant from using support conversations to determine discounts. Another might restrict employee medical information from summarization outside an authorized benefits workflow.

Organizations also need provenance, which records where an AI response obtained its information. Provenance helps reviewers understand which sources influenced an answer or action.

Logging only the final prompt and response is insufficient for many agentic workflows. Investigators may need the retrieved documents, tool calls, policy evaluations, model version, and approval history.

That record supports audits and incident response. It can also reveal policy rules that block harmless work or permit risky combinations.

Testing must reflect real business relationships. Generic model benchmarks cannot determine whether a particular customer message belongs in a renewal recommendation.

Teams should build scenarios around their own data, roles, workflows, and prohibited outcomes. Tests should include both malicious prompts and ordinary requests with ambiguous purposes.

Human approval can reduce risk for high-impact actions. It is most useful when the reviewer receives the relevant context and an understandable reason for the alert.

A button labeled “approve” does little if the reviewer cannot see which sensitive sources shaped the action. Approval fatigue can also convert a formal control into an automatic click.

Organizations should therefore reserve human review for meaningful boundaries. Lower-risk workflows can use automated restrictions, sampling, and retrospective monitoring.

Data minimization is another practical control. An assistant should receive only the information required for its present task, even when its service account can reach more.

Retrieval systems can enforce that restriction before content enters the model’s context. Tool gateways can similarly limit which operations an agent can perform.

For knowledge workers, local context can reduce unnecessary transfers to broad external services. A well-designed personal knowledge base can preserve clearer boundaries between personal and shared organizational information.

However, architecture alone does not guarantee appropriate use. Local processing can reduce exposure while still producing an unfair, intrusive, or unauthorized inference.

This is an important skeptical point. Security vendors may describe contextual enforcement as a complete answer, but policy interpretation remains difficult.

Natural language is ambiguous. Business relationships change. A rule that works for one department may obstruct another team or miss a subtle misuse.

False positives can drive employees toward workarounds. False negatives can create unjustified confidence in an automated governance layer.

Model behavior also changes after updates. A prompt, retrieval strategy, or policy test that worked with one version may behave differently with another.

Organizations should treat contextual controls as part of a layered program. Identity, least privilege, data classification, retrieval filtering, tool restrictions, evaluation, and human oversight remain necessary.

No single control establishes that every outcome is appropriate. The objective is to make policy violations visible, testable, and harder to execute at machine speed.

Three Signals Will Show Whether Shady AI Becomes a Real Security Category

Shady AI will matter only if organizations can measure it, enforce meaningful controls, and connect failures to accountable owners.

The first signal is whether major security frameworks distinguish inappropriate authorized use from ordinary unauthorized AI. NIST, OWASP, and industry groups already address related pieces.

Prompt injection covers manipulated model behavior. Excessive agency covers dangerous autonomy. Shadow AI covers unknown or unsanctioned systems.

None of those labels perfectly describes an approved system making a contextually unacceptable decision without an attacker. A clearer taxonomy would help teams report incidents consistently.

Watch for new framework guidance that addresses purpose, relationship, and inference. Such guidance would strengthen Cohen’s argument that conventional access controls leave a material gap.

The judgment would weaken if existing categories already capture these incidents without operational confusion. New terminology has little value when it merely renames established failures.

The second signal is the arrival of measurable runtime controls. Vendors will promise contextual governance, but buyers should look for evidence beyond policy dashboards.

Useful evidence includes enforceable purpose restrictions, decision logs, retrieval-level controls, tool-call approvals, and repeatable tests. Products should also explain why a policy allowed or denied an action.

Independent evaluations would be especially valuable. A vendor should not be the only party defining the risk, measuring its product, and declaring the control successful.

Buyers should test realistic scenarios before broad deployment. They should ask whether the system stops inappropriate data combinations, not only known malicious prompts.

They should also examine failure modes. A control that blocks legitimate workflows too often will lose support, even if its security logic appears sound.

The third signal is organizational accountability. Shady AI crosses security, privacy, legal, data, and product responsibilities.

A governance committee can coordinate those teams, but committees often produce guidance without operational ownership. Every deployed system still needs an accountable decision-maker.

That owner should approve intended purposes, acceptable data relationships, prohibited outcomes, and escalation rules. Security teams can then translate those decisions into technical controls and tests.

Incident reporting will reveal whether that model works. Organizations should be able to distinguish an unknown tool, a compromised agent, a permission failure, and an inappropriate authorized action.

Those categories lead to different remedies. Blocking a domain can address an unsanctioned chatbot, but it cannot govern an approved model already embedded in a business application.

Google News exposure will bring more attention to shady AI, yet attention alone will not establish the term. Evidence from deployed systems must show a recurring failure that existing controls consistently miss.

Security leaders should start with a narrow inventory of approved AI workflows that touch sensitive data or consequential decisions. For each workflow, they should ask four questions.

What information can the system retrieve? Which purposes justify that retrieval? What actions can it take? Who can explain and stop an inappropriate result?

If those questions produce vague answers, the governance gap already exists. Teams do not need to wait for a breach, regulation, or new product category to examine it.

The practical next step is to select one high-impact workflow and trace it from request to outcome. Record identities, retrieved data, policies, model decisions, tool calls, and human approvals.

Then test requests that are technically permitted but contextually wrong. That exercise will show whether “approved” truly means governed, or merely connected and trusted.