Three AI Security Mistakes Put Enterprises at Risk

Google News surfaced an InfoWorld warning with three conflicts that enterprises can no longer treat as theoretical AI risks. Trusted models can process hostile instructions, agents can inherit excessive permissions, and human approval screens can conceal the action being authorized.

The headline matters because companies are moving from conversational assistants to systems that read files, call applications, modify code, and trigger business processes. That transition changes a mistaken answer into a potential security event. The central contest is now clear: rapid AI deployment versus enforceable limits on what each system can see and do.

The problem is not that every model suddenly became malicious. It is that familiar controls often lose their meaning when probabilistic software sits between data, users, credentials, and tools. Recent incidents involving Microsoft, Google, Amazon, Anthropic, Cursor, and other vendors show how quickly that gap can become operational.

The Google News Warning Is About Control, Not Intelligence

The most dangerous enterprise mistake is treating model behavior as the primary security boundary.

The Google News listing points to an InfoWorld headline about three security mistakes haunting enterprises. The larger signal is more important than the seasonal framing. Companies are connecting language models to valuable systems before redefining the boundaries around those connections.

A chatbot once produced text for a person to review. An AI agent can now decide which tool to call, assemble arguments, use stored credentials, and continue across several steps. That expanded reach turns model mistakes into application security problems.

Organizations often respond by placing more instructions in the system prompt. They tell the model not to disclose confidential information, follow untrusted commands, or perform dangerous actions. Those instructions can improve behavior, but they do not create an enforceable authorization boundary.

Prompt injection explains why. A prompt injection is malicious or misleading content that causes a model to follow unintended instructions. An indirect injection arrives through material the model retrieves, such as an email, webpage, document, issue, or repository.

The model must interpret both trusted instructions and untrusted content through the same natural-language interface. It can recognize a sentence as data in one context, then treat similar text as a command elsewhere. No prompt can change the permissions granted by the surrounding application.

The OWASP risk list places prompt injection first among its 2025 risks for large language model applications. It separately identifies sensitive information disclosure, supply-chain weaknesses, improper output handling, and excessive agency.

That separation offers a useful lesson. Prompt injection is often the trigger, but surrounding architecture determines the consequence. An injected assistant with no secrets and no write access has a limited blast radius. The same input becomes serious when an agent can read mail, query private data, execute code, or alter cloud resources.

This is why better model reasoning does not automatically create better security. A more capable model can follow legitimate plans more reliably. It can also navigate connected systems more effectively after an attacker redirects its plan.

Enterprises should therefore evaluate AI as an untrusted decision component inside a larger security system. The model can propose an action, but deterministic controls must decide whether that action is allowed. Those controls include identity checks, policy enforcement, input isolation, and output validation.

This principle also changes how teams investigate failures. A strange answer is not merely a quality problem when the model has tools. Reviewers must ask which identity executed the request, what data entered the context, and which external state changed.

The headline’s three mistakes are connected by that missing control plane. Companies trust the model, trust the permissions around it, and trust the approval process shown to users. Each layer can fail while appearing normal.

Mistake One: Treating Model Guardrails as Security Controls

A model refusal is a behavioral preference, while an access-control rule is an enforceable decision.

Enterprises often begin AI security reviews by testing whether a model refuses prohibited requests. That work has value, especially for abuse prevention and policy compliance. It does not answer whether the full application can protect secrets or resist manipulated context.

A model guardrail typically operates through training, filtering, classification, or written instructions. These measures influence responses. They cannot revoke a database permission, shorten a token’s lifetime, or prevent an application from passing confidential records into context.

The distinction becomes important when retrieval-augmented generation is involved. Retrieval-augmented generation, or RAG, supplies selected enterprise documents to a model before it answers. The model can only reason over material the retrieval layer gives it, making retrieval permissions part of the security boundary.

If that layer returns documents based only on semantic relevance, it can cross organizational boundaries. A useful-looking passage might belong to another department, customer, or legal matter. The model’s fluent summary can then hide the underlying authorization error.

The same risk appears when applications retrieve content from outside the enterprise. A research agent might read webpages, attachments, support tickets, and shared documents. Any of those sources can contain instructions designed for the agent rather than useful information for the employee.

Microsoft’s description of the fixed EchoLeak vulnerability shows the seriousness of that route. The company says the attack used a multistage, cross-prompt injection under certain conditions to exfiltrate limited data available to a victim. Microsoft addressed the issue as CVE-2025-32711.

The importance of EchoLeak guidance extends beyond one product. It demonstrated that a production assistant can combine external content, internal access, and model behavior into a data-exfiltration path.

A prompt-only defense asks the model to notice the manipulation. A system-level defense assumes detection can fail. It then limits retrieved data, blocks dangerous output channels, and verifies every sensitive operation outside the model.

The National Institute of Standards and Technology takes a similarly broad view. Its generative AI profile addresses risks across design, development, deployment, evaluation, and use. It does not reduce AI security to model filtering.

That lifecycle approach matters because enterprise applications contain many components. They include model providers, vector databases, identity systems, plugins, APIs, monitoring tools, and user interfaces. A security review that tests only the model leaves most of that chain untouched.

A practical test should begin with compromised-context assumptions. Reviewers can place hostile instructions inside documents the application normally retrieves. They can then observe whether the agent exposes data, changes its objective, or attempts an unauthorized tool call.

Teams should repeat those tests after changing models, prompts, connectors, retrieval settings, or tool descriptions. AI behavior can shift even when the application code looks unchanged. A successful evaluation from the previous quarter does not guarantee the current workflow behaves identically.

Model upgrades create another source of false confidence. A vendor may improve refusal behavior while introducing different planning patterns. An application that depended on an undocumented refusal can become less predictable without any formal permission change.

The safer architecture treats prompts as one defensive layer. It combines them with access controls that the model cannot rewrite. Sensitive data should remain unavailable unless the user, task, and resource all satisfy explicit policy.

Outputs also require inspection before they become actions. A generated database query should pass authorization and validation. A proposed email should undergo destination checks. Code should execute inside an isolated environment with narrow filesystem and network access.

This structure does not eliminate prompt injection. It prevents a successful injection from automatically becoming a breach. That is the more realistic target for enterprise security.

Mistake Two: Giving AI Agents Human-Sized Permissions

An agent should receive the smallest temporary permission needed for one task, not the standing access held by its user.

The second mistake appears when an enterprise connects an AI agent to existing employee credentials. That approach is convenient because applications already understand those identities. It also gives probabilistic automation the reach accumulated around a human account.

Employees often need broad access because their responsibilities vary throughout the week. An agent handling one narrow request does not need that same range. If it inherits every accessible mailbox, repository, customer record, and cloud tool, its blast radius becomes unnecessarily large.

OWASP describes this problem as excessive agency. The vulnerability arises when an AI system receives too much functionality, too many permissions, or too much autonomy. Manipulated output can then produce damaging actions across confidentiality, integrity, and availability.

The word “agency” can make the risk sound abstract. In practice, it means ordinary permissions attached to an unpredictable planner. A model chooses a tool call, the application supplies credentials, and another system accepts the request as authorized.

Traditional least privilege remains the right starting point. Each agent needs a distinct identity, a defined task, and a short list of permitted resources. That identity should not quietly borrow a developer’s shell access or an executive’s entire document estate.

Credentials should also expire quickly. Long-lived keys allow an error or compromise to persist after the original session ends. Short-lived tokens reduce that window and create clearer audit records for each task.

Write access deserves separate treatment from read access. Many assistants can deliver useful summaries without modifying source systems. Enterprises should begin there, then add narrowly scoped actions only after testing the complete path.

High-impact operations need transactional boundaries. An agent preparing a customer refund can assemble evidence and recommend an amount. A separate deterministic service should verify policy, authorization, destination, and limits before issuing anything.

The same pattern applies to software development. An agent can propose a patch inside a temporary workspace. It should not automatically inherit access to production credentials, deployment systems, personal configuration files, or unrelated repositories.

Network access also deserves task-level constraints. A coding agent that only needs package documentation should not reach arbitrary external servers. A research assistant can operate through an approved fetcher that blocks private addresses, dangerous protocols, and untrusted downloads.

Tool descriptions are not permission controls. Telling an agent that a function should only be used for a specific purpose does not stop unauthorized invocation. The receiving service must enforce who can call it, which arguments are valid, and which resources remain in scope.

This is where many enterprise AI programs collide with deployment speed. Product teams want one connector that works across many use cases. Security teams need separate scopes, identities, logs, and approval rules for each meaningful action.

The tension is genuine, but broad access is not the only workable design. Enterprises can issue capabilities for individual tasks. A capability is a narrowly defined permission that authorizes one action against one resource for a limited period.

That approach also improves investigations. Logs can show that a specific agent instance read three approved records for one support request. Shared user credentials instead produce a stream of actions that can be difficult to attribute.

Data minimization belongs in the same design. An agent does not need a complete document when a filtered field answers the question. It does not need every customer account when the task names one account.

Teams building searchable internal systems face this issue early. A secure technical knowledge base must preserve source permissions instead of flattening every file into one unrestricted index.

The important comparison is not agents versus humans. It is standing human access versus task-specific machine access. Machines operate faster, repeat actions consistently, and can scale one mistake across many records.

Enterprises should design accordingly. A system that can act hundreds of times during one session needs tighter limits than a person making one deliberate change. Speed expands both productivity and damage.

Mistake Three: Assuming Human Approval Makes an Action Safe

Human involvement adds little protection when the interface hides the target, timing, or consequence of the proposed action.

Many enterprise AI products place a person in the loop before consequential operations. The agent presents a confirmation dialog, and the user chooses whether to continue. That design looks reassuring because responsibility remains visibly human.

The protection depends on what the person can actually see. A vague prompt such as “allow this change” does not support an informed decision. Neither does an approval screen built from content that an attacker can influence.

Wiz’s GhostApproval research exposed this problem across six prominent AI coding assistants. The affected set included Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf.

According to the GhostApproval findings, a malicious repository could use symbolic links to redirect an apparently local file change outside the workspace. A symbolic link is a filesystem reference that points one path toward another location.

The visible approval could name an innocent project file while the resolved path targeted a sensitive system file. In some tested products, Wiz reported that writes occurred before meaningful authorization. That transformed the interface from a security gate into an undo mechanism.

The findings do not mean every current version remains vulnerable. Wiz reported fixes or responses from several vendors, and product behavior can change quickly. The lasting issue is the trust model exposed by the research.

Human approval works only when the system presents canonical, independently verified details. For a file operation, those details include the resolved path, operation type, content difference, process identity, and whether the target sits outside the authorized workspace.

For a message, users need the real recipient, attached data, and sending identity. For a payment, they need the destination, amount, authorization source, and policy result. For a cloud change, they need the account, resource, region, and expected effect.

The application must generate those facts from trusted system state. It should not rely on the agent’s natural-language summary. The same model requesting permission has an incentive, intentional or otherwise, to frame the action as useful.

Timing matters just as much. Approval must occur before the system changes external state. A button that appears after a file write, API call, or message transmission cannot prevent the event.

Enterprises also need to avoid approval fatigue. If users receive frequent requests for harmless operations, they learn to accept without inspecting details. Attackers can then hide a dangerous request among familiar prompts.

Risk-based approval offers a better pattern. Low-impact actions can proceed inside strict limits. Sensitive operations receive richer disclosure, stronger authentication, and independent policy checks.

Some actions should never depend on a single click. Deleting production data, changing access policies, exporting large datasets, or modifying deployment credentials can require a second identity or an out-of-band review.

This does not remove people from the process. It gives them a decision they can realistically evaluate. Humans are best used for judgment, not for verifying hidden technical state under time pressure.

Security teams should test approval screens adversarially. They can ask whether long filenames hide the destination, whether formatting can obscure warnings, and whether a compromised document can influence displayed text.

They should also inspect race conditions. The reviewed state must remain unchanged between approval and execution. If an attacker can replace a file, destination, or argument after approval, the visible decision no longer covers the actual action.

Google News attention to enterprise AI security reflects a broader correction. “Human in the loop” is not a complete control description. Reviewers need to know which human, which information, which moment, and which independently enforced boundary.

Why Enterprises Keep Repeating These Three Mistakes

Deployment incentives reward visible AI capability, while reliable boundaries remain slower and less visible to buyers.

The three mistakes persist because each offers a convenient shortcut. Prompt instructions are easier than redesigning access controls. Shared credentials are easier than creating task-specific identities. Confirmation buttons are easier than building verifiable authorization flows.

Demos reinforce those shortcuts. A successful demo rewards broad access because the agent can find more information and complete more steps. Restricted access produces more denials, setup work, and apparent friction.

Production reverses that calculation. Every connected system introduces another trust relationship. Every added permission increases potential impact. Every automated step reduces the time available for a defender to notice abnormal behavior.

Organizational ownership adds another problem. Product teams choose models and connectors. Identity teams manage credentials. Security teams monitor events. Legal teams define data restrictions. Business units decide which workflows matter.

An agent can cross all those domains during one task. If no team owns the complete execution chain, each group can assume another control will stop the failure.

Vendor assurances can deepen the gap. Enterprise contracts may address data retention, model training, and encryption. Those protections matter, but they do not repair overbroad customer permissions or unsafe workflow design.

A provider can protect stored prompts while the customer exposes internal records through retrieval. It can isolate model infrastructure while an enterprise grants an agent excessive cloud access. Responsibility remains shared across the stack.

Security products also struggle when AI activity resembles legitimate work. An authorized employee might ask an approved assistant to summarize a contract. The same workflow becomes dangerous when the contract contains a hidden instruction that redirects the agent.

Traditional monitoring sees an authenticated user, an approved application, and a permitted data request. The missing signal is the relationship between untrusted context and the action that followed.

Enterprises need richer traces for that relationship. Useful logs capture retrieved sources, model decisions, tool calls, policy outcomes, approvals, and resulting state changes. Sensitive content can be protected while preserving enough evidence for investigation.

The goal is not unlimited surveillance of employees. It is accountable automation. People should understand when an AI system accesses company data and which actions it takes on their behalf.

Shadow AI complicates that work. Shadow AI means employee use of unapproved models, agents, or connectors outside normal governance. Blocking every public tool can push activity toward personal accounts and unmanaged devices.

A better response combines approved alternatives with enforceable controls at identity, browser, endpoint, and data layers. Employees need a practical route for legitimate work. Security teams need visibility into where protected information moves.

Companies should also separate experimentation from production. A sandbox can provide synthetic data, disposable credentials, isolated networks, and limited tools. Successful experiments can then move through explicit threat modeling before receiving real access.

This process requires more than a compliance checklist. Each workflow needs an abuse case. Reviewers should ask what happens when retrieved content lies, a model selects the wrong tool, or a user approves a misleading request.

They should then test recovery. Can the enterprise revoke the agent identity immediately? Can it identify changed records? Can it reverse actions without trusting the same model that caused them?

The strongest counterargument is that these controls will slow adoption. That is true for some deployments. However, unresolved permission and approval flaws create delays later through incident response, emergency restrictions, and lost trust.

Another uncertainty concerns the models themselves. Vendors continue improving instruction handling and attack detection. Those improvements can reduce successful manipulation, but they do not justify removing deterministic limits.

Enterprise security should improve as models change, not depend on those changes. A well-designed application becomes safer with a better model while remaining bounded when that model fails.

What Security Leaders Should Watch Next

The next phase will be measured by permission design, independent testing, and incident transparency rather than model refusal scores.

The first signal is whether vendors publish meaningful postmortems for agent security incidents. Useful disclosures describe the initial input, available tools, credentials, containment failure, and final impact. Vague references to “unexpected behavior” provide little guidance.

Postmortems should also clarify what changed after the incident. A new prompt is weaker evidence than a revoked permission or redesigned authorization gate. Security leaders should distinguish behavioral tuning from architectural remediation.

The second signal is adoption of agent-specific identity controls. Enterprises need separate machine identities, short-lived credentials, resource-level scopes, and emergency revocation. Products that only impersonate the user leave important questions unanswered.

Buyers should ask whether one agent can access unrelated applications during a task. They should request evidence that policy follows every tool call. They should also verify that logs connect actions to the originating user and session.

The third signal is repeatable security regression testing. AI regression testing checks whether known attacks return after changes to models, prompts, tools, retrieval, or permissions. It should run before deployment and after every material update.

Those tests need realistic hostile content. Teams should place attacks inside emails, webpages, documents, repositories, and tool responses. Direct user prompts cover only one portion of the application’s input surface.

Independent research will remain essential. Vendor evaluations often emphasize normal use and known attacks. External researchers approach trust boundaries differently, as EchoLeak and GhostApproval illustrate.

Procurement teams can support that work by asking about disclosure programs, response timelines, and published remediation. A product’s reaction to research reveals as much as its security marketing.

Google News will continue surfacing alarming AI incidents because agents are reaching more sensitive systems. The useful response is not panic or a blanket ban. It is a change in how enterprises define safe deployment.

Treat the model as untrusted. Give the agent less access than the person directing it. Make approval screens reveal independently verified facts before anything changes.

Security leaders should now choose one connected AI workflow and trace it from input to final action. Which control still works if the model follows a hostile instruction? The answer will show whether the enterprise has an AI security architecture or only an AI security promise.