AI moves faster than your controls. Here's how to fix it.

For a deeper context, read part one of this series on the importance of AI governance.

AI governance cannot be merely a checkbox exercise.

As explained in part one in this two-part series, the rapid integration of generative AI into core business operations has widened the security gap between deployment speed and control in most organizations.

AI now interacts with source code, databases and identity systems.

This means:

• Data moves more easily
• IT struggles to enforce retrieval boundaries
• Autonomous workflows are at higher risk
• Sensitive content becomes more accessible through new interfaces

IT must evolve from reactive AI response into an active operational security discipline.

AI coding assistants

AI coding tools are not merely productivity features. They run inside developer environments next to:

• Source code and infrastructure-as-code
• Terminals
• Package managers
• Build systems
• Git credentials and cloud profiles

Cursor's CurXecute

Cursor’s CurXecute vulnerability, tracked as CVE-2025-54135, demonstrates this risk clearly. Cursor’s own GitHub security advisory says that if chained with a separate prompt-injection vulnerability, the agent could write sensitive Model Context Protocol (MCP) files on the host, allowing code execution by adding a new MCP server. The National Institute of Standards and Technology (NIST), charged with caretaking the the US's National Vulnerability Database (NVD), describes the issue as involving the creation of sensitive MCP files such as .cursor/mcp.json without approval, potentially triggering RCE on the victim host.

Amazon X Developer extension

The Amazon Q Developer extension incident shows a separate supply-chain angle. Amazon Web Services (AWS) disclosed that an issue affected the Amazon Q Developer extension for Visual Studio Code and assigned it CVE-2025-8217. NIST describes the affected extension version as containing inert injected code designed to call the Q Developer CLI; the code executed when the extension launched, but a syntax error prevented a successful API call.

These incidents highlight two distinct risk patterns.

In Cursor’s CurXecute vulnerability, indirect prompt injection could let an agent write sensitive MCP configuration files, such as .cursor/mcp.json, potentially enabling remote code execution. Separately, the Amazon Q Developer VS Code extension was impacted by a supply-chain issue where an over-scoped GitHub token allowed malicious, though ultimately inert due to a syntax error, code into a release.

This means AI developer tools must be governed like privileged software supply-chain components, not like ordinary text editors.

Governance recommendations

• Control which AI coding tools and extensions are approved, which versions are allowed and what permissions they receive.
• Require explicit approval for terminal execution, MCP configuration changes, cloud operations, file deletion and repository-wide modifications.
• Run risky agentic workflows in sandboxes or containers, monitor them with EDR and prevent local secrets from being freely available to AI tools.

AI infrastructure can introduce risk

AI governance must also cover the infrastructure surrounding AI:

• Logs, prompts, outputs and datasets
• Storage buckets, model artifacts and notebooks
• APIs, keys and telemetry

In March 2023, OpenAI disclosed a ChatGPT outage and data exposure bug. OpenAI said a bug in an open-source library allowed some ChatGPT users to see titles from another active user’s chat history. OpenAI also said it was possible that the first message of a newly created conversation was visible in someone else’s chat history if both users were active around the same time. Separate reporting on the same incident noted payment-related exposure for a subset of active ChatGPT Plus subscribers.

In 2023, Microsoft disclosed that an overly permissive Azure Shared Access Signature token exposed internal information in a storage account. Microsoft said a researcher inadvertently included the SAS token in a blob-store URL while contributing to open-source AI learning models and provided the URL in a public GitHub repository. The incident is especially relevant to AI governance because AI research teams often share datasets, models, notebooks and storage links.

In 2025, Wiz reported that it found a publicly accessible DeepSeek ClickHouse database. Wiz said the exposure included more than a million lines of log streams containing chat history, secret keys, backend details and other sensitive information; DeepSeek secured the exposure after disclosure.

AI logs, storage and datasets have become high-value assets.

The common thread is sensitive exhaust: AI systems do not only process sensitive data. They also generate secondary and highly-sought-after sensitive artifacts that can be lucrative for bad actors:

• Prompts, outputs and chat logs
• API keys, evaluation traces and debugging data
• Model telemetry, storage references and dataset paths

Governance recommendations

• Classify and protect AI-generated data
• Define retention rules for prompts and outputs
• Filter secrets from logs and isolate tenants
• Monitor storage permissions
• Scan notebooks and repositories for credentials

And always include AI vendors in third-party risk management.

AI vendors should be evaluated by model quality, data handling, logging, retention, deletion, auditability and breach notification.

Autonomous agents: model-side guardrails are not enough.

Autonomous AI agents introduce a different class of risk. Unlike a chatbot, an agent can:

• Take actions and observe results
• Call tools and run commands
• Edit files, query APIs and iterate

Alibaba

A research example is the a paper first posted to arXiv in December 2025 and revised in March 2026 by an Alibaba-affiliated team. The paper reports that, during agentic training, the agent ROME established and used a reverse SSH tunnel from an Alibaba Cloud instance to an external IP address and repurposed provisioned GPU capacity for cryptocurrency mining.

It's important to note here that this was a research and training incident described in a preprint, not a public enterprise breach.

The risk is that reinforcement-learning optimization and tool access can produce path-of-least-resistance behavior that violates operational boundaries. When the environment exposes network access, compute resources, tools, credentials, or execution pathways, model-side instructions are not enough.

The security lesson is that IT must constrain agentic AI in the environment, disallowing it from following forbidden prompt instructions.

Governance recommendations

Autonomous agents need:

• Least privilege and sandboxing
• Network egress controls
• Human approval of sensitive actions
• Resource quotas and immutable audit logs
• Hard API gateways

Any action involving file deletion, credential access, external network communication, code execution, production data, financial operations or cloud resource changes should require explicit policy enforcement outside the model.

Once AI systems can write files, modify configuration, execute commands, call APIs or allocate resources, model behavior is only one part of the security problem.

The AI governance control planes

While these incidents differ in technical details and impact, they reveal a consistent pattern: AI does not just create new risks. It amplifies familiar weaknesses by making them faster, broader and harder to contain.

The Samsung case highlighted in part one of this series involved not an outside danger, but an internal one: engineers pasted sensitive source code and other internal information into a public tool to boost productivity.

This case illustrates the dangers of unmanaged employee usage.

Retrieval issues with Copilot and GitHub show how indexed or cached data can resurface unexpectedly. The EchoLeak situation (also outlined in part one of this series), in which AI command injection in Microsoft 365 Copilot allowed unauthorized disclosure of information over a network, demonstrates how untrusted external content can manipulate powerful copilots.

Cursor and Amazon Q Developer show how developer tools become part of the software supply chain.

OpenAI, Microsoft and DeepSeek incidents remind us that logs, storage and research artifacts are now high-value assets. Alibaba's ROME shows why model-level guardrails are rarely enough without strong environmental boundaries.

Addressing risks systematically

Effective AI governance must operate across five interconnected control planes:

• Data governance: Map data ingest, embedding vectors, prompt storage, model telemetry, tenant log retention and output handling. Define what data can enter AI systems, where it is stored, how it is logged and when it is deleted.
• Identity governance: Ensure tokens, API gateways, service accounts, user authorization levels and delegated access rights propagate correctly into RAG, copilot and agentic workflows.
• Endpoint governance: Control AI coding plugins, browser-based AI tools, workspace indexing permissions, local terminal execution rights, managed accounts and developer workstation exposure.
• Application governance: Isolate data boundaries when copilots, RAG systems, plugins, MCP servers and agents process external or untrusted content such as emails, PDFs, support tickets, repositories and webpages.
• Process governance: Keep a definitive human-in-the-loop boundary for AI-assisted code commits, data exports, cloud actions, infrastructure mutations and privileged operations.

This approach aligns with major frameworks:

• NIST’s AI Risk Management Framework provides a structure for managing AI risks to individuals, organizations and society. The NIST AI RMF uses the Govern, Map, Measure and Manage functions to operationalize AI risk management across the AI lifecycle.
• ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system.
• OWASP’s LLM guidance adds the application-security layer, especially around prompt injection, sensitive information disclosure, supply-chain risk and agent/tool misuse.

From passive policy to active gatekeeping

AI Governance cannot remain a passive acceptable-use policy. It must actively answer operational questions:

• Which AI tools are employees actually using? Which AI tools are approved, blocked, or restricted?
• Which prompts contain sensitive data?
• Which copilots can access internal repositories, email, chat and files? Which agents can run commands or call external APIs?
• Which developer extensions can access source code and local credentials?
• Which AI vendors retain prompts, outputs, logs and telemetry? Which controls stop an AI tool from becoming an exfiltration path?

The goal is not to slow down AI adoption. The goal is to make AI adoption secure, auditable and sustainable with endpoint visibility and AI-aware incident response.

That requires moving from passive monitoring to active behavioral gatekeeping:

• Discovery, classification and agent sandboxing
• Prompt and upload data loss prevention and retrieval authorization
• Runtime policy enforcement
• Tool-call approval
• Least privilege and egress controls

Treat AI governance as a core of enterprise security.

AI did not invent these breach patterns. It changed the speed, scale and reach of those patterns.

Organizations that treat AI governance as a core layer of enterprise security will be best positioned to capture the upside of AI while managing its operational risks.

The practical question for security leaders is no longer whether employees and systems will use AI. They already do. The question is whether the organization can govern that usage before the next prompt, plugin or agent becomes a security boundary failure.