No‑Code Copilot Agents Can Leak Data—Here’s Control

A single prompt shouldn’t be able to pull customer credit card details out of a chatbot.

Yet that’s exactly what researchers demonstrated with a simple no‑code AI agent built in Microsoft Copilot Studio: the agent was instructed (in bold, no less) not to reveal other customers’ data, but a basic prompt injection still persuaded it to disclose names, payment details, and booking information. The same experiment also showed something even scarier for finance teams: the bot could be talked into editing a booking to cost $0.

This post is part of our AI in Cybersecurity series, where we focus on a practical truth: AI can widen your attack surface, and it can also help you defend it. No‑code agent platforms are rolling into enterprises fast—especially in Q4, when teams race to automate customer support, procurement, HR intake, and year‑end reporting. If you don’t govern them like real apps, you’re going to treat a production risk like a “productivity tool.”

Why no‑code AI agents are a security problem (not an IT nuisance)

No‑code AI agents create risk because they combine three things that attackers love: easy deployment, broad access, and unpredictable behavior.

Traditional apps usually go through a pipeline: design review, threat modeling, test, staging, approval, monitoring. No‑code agents often skip all of that. A business user can connect an agent to SharePoint, CRM, ticketing systems, or email, and publish it in hours—sometimes minutes. That speed is the point, but it also means:

• Security teams don’t see the agent (classic shadow IT, now “shadow AI”).
• Permissions are inherited from connectors, not carefully designed per workflow.
• Natural language becomes an attack interface, and it’s much harder to predict than a form field.

Here’s the stance I’ll take: if an AI agent can read files, change records, send emails, or approve actions, it’s not “just a chatbot.” It’s an application with an LLM front end—and it should be governed accordingly.

The hidden multiplier: connectors and tool use

The real danger isn’t the model being “confused.” The danger is the model being authorized.

Agent platforms typically let the LLM call tools (connectors, APIs, workflows) to complete tasks. This creates a powerful capability: a conversational interface to your internal systems. It also creates a blunt truth:

If the agent has permission to access a dataset, then prompt injection is often just a matter of finding the right phrasing to make it do so.

In the Tenable experiment referenced in the RSS source, connecting the agent to a SharePoint file containing fake customer and payment data made the bot instantly more useful—and instantly more abusable.

How prompt injection turns “helpful” into “harmful”

Prompt injection works because LLMs don’t enforce rules the way software does. They “follow instructions” probabilistically, and they can be manipulated into treating attacker text as higher priority than your policy text.

The reported experiment is a clean illustration:

1. Researchers created a travel‑booking agent.
2. They added explicit system instructions to prevent cross‑customer access.
3. They used simple prompts to reveal the agent’s capabilities.
4. They requested data for other customers.
5. The agent provided it.

That’s not a minor slip; it’s the model doing the exact thing you hired it not to do.

Why “just write better instructions” doesn’t solve it

A lot of teams respond to agent risk with prompt hygiene: longer policies, stronger wording, “never do X” repeated three times.

That’s security theater.

The core issue is that system prompts are not access controls. They’re guidance. If your agent can reach sensitive data through a connector, then you need controls outside the prompt:

• explicit authorization checks
• data scoping
• action gating
• monitoring and anomaly detection

If you remember one line from this post, make it this:

Prompts are not permissions.

The second failure mode: workflow hijacking

Data leakage gets headlines. Workflow hijacking hits the bank account.

The same class of manipulation can push an agent to:

• edit records (pricing, inventory, invoices)
• send emails or messages “on behalf of” a user
• create or close tickets to hide activity
• trigger approvals or refunds

In the travel bot test, changing a booking to $0 via a one‑sentence prompt is the perfect example of business logic compromise—except the business logic is now being executed through an LLM and a connector.

The real enterprise risk: shadow AI agents you didn’t approve

The most dangerous AI agent is the one your security team doesn’t know exists.

Modern enterprises are already full of automation: low‑code workflows, RPA, integration tools, and SaaS add‑ons. No‑code agents pour gasoline on that fire because they’re socially easy to justify (“It’s just helping our team answer questions”).

In practice, shadow AI shows up like this:

• A sales ops manager builds an agent that can pull “any contract clause we’ve used before.” It’s connected to a broad document library.
• An HR coordinator builds an onboarding agent connected to employee records.
• A finance analyst builds an agent that summarizes invoices and can “correct” line items.

None of these people are reckless. They’re doing their jobs. The platform makes it feel safe because it’s polished and simple.

What “centralized visibility” actually means

A vague mandate like “govern AI” won’t help. You need a concrete inventory and exposure map.

At minimum, centralized visibility should answer these questions in plain language:

1. Which agents exist? Name, owner, business unit, environment, publishing channel.
2. What can each agent access? Files, lists, mailboxes, CRM objects, ticket queues.
3. What can each agent do? Read, write, delete, send, approve, trigger workflows.
4. Who can interact with it? Internal users, external customers, anonymous web users.
5. What data is in scope? PII, PCI, PHI, source code, credentials, legal docs.

If you can’t answer these quickly, you don’t have an AI agent program—you have an unmanaged app ecosystem.

A practical governance framework for Copilot-style agents

You can use no‑code AI agents safely, but only if you treat them like production systems with human‑friendly interfaces.

Here’s a framework I’ve seen work because it’s realistic and enforceable.

1) Classify agents by risk and enforce guardrails by tier

Start with three tiers. Keep it simple.

• Tier 1 (Low risk): public FAQs, generic policy explanations, no internal data access
• Tier 2 (Medium risk): internal knowledge access to non‑sensitive documents, read‑only
• Tier 3 (High risk): access to sensitive repositories or any write capability (edit, send, approve)

Then enforce rules:

• Tier 1: basic monitoring, rate limits
• Tier 2: strict data scoping, DLP checks, logging
• Tier 3: approvals, break‑glass controls, step‑up authentication, human-in-the-loop for actions

2) Fix the permission model: least privilege on connectors

Most “agent leaks” are permission leaks.

Do these two things:

• Use dedicated service identities for agents, not shared user tokens.
• Scope access to the smallest possible dataset, ideally via separate libraries, separate lists, separate CRM views, or separate indexes.

If your SharePoint connector can see “All Employees” or “All Customers,” your agent can too—whether it’s supposed to or not.

3) Add action gating for anything that changes state

If an agent can modify data, it should face friction.

A strong pattern is a two-step commit:

1. The agent proposes an action in structured form (what it will change, where, and why).
2. A policy engine (and often a human) approves it.

For high-risk workflows, require one of:

• manager approval
• ticket creation + approval
• step-up authentication
• restricted time windows

This protects you from both prompt injection and simple user mistakes.

4) Monitor agent behavior like you monitor endpoints and users

This is where the campaign theme “AI needs to fight AI” becomes practical.

AI agents generate rich signals:

• unusual query patterns (e.g., “show me all customers”)
• repeated attempts to bypass policy
• abnormal tool calls (sudden access to new repositories)
• unusual write actions (discounts, refunds, edits)

You should feed these signals into your security operations monitoring and apply anomaly detection tuned for agent behavior.

If your SOC can detect impossible travel and suspicious OAuth consent, it can also detect:

• an agent that suddenly starts exporting large volumes of data
• a customer-facing bot that asks internal tools for sensitive fields
• repeated prompts that look like jailbreak attempts

5) Test agents like apps: red-team prompts and regression suites

Agent security isn’t “set and forget.” Models, connectors, and prompts change.

Build a lightweight testing loop:

• Prompt injection test pack: 25–50 known attack patterns tailored to your tools
• Data exfil tests: attempts to retrieve PII/PCI/PHI beyond user scope
• Action abuse tests: attempts to edit prices, change bank details, trigger refunds
• Regression cadence: run tests on every publish and on a schedule

The goal isn’t perfection. The goal is catching obvious failures before attackers (or curious users) do.

People also ask: quick answers for security and IT leaders

Can we rely on system prompts to prevent data leakage?

No. System prompts guide behavior; they don’t enforce access control. Preventing leakage requires permission scoping, policy enforcement, and monitoring outside the prompt.

Are Copilot Studio risks unique to Microsoft?

No. The underlying risk is common to any platform that connects an LLM to tools and data sources. The brand changes; the pattern stays.

What’s the safest default for enterprise AI agents?

Read-only access, narrow data scoping, dedicated identities, and human approval for state-changing actions.

How do we find “shadow AI agents” already deployed?

Inventory agent platforms, audit connectors and service identities, review published bots/channels, and correlate tool-call logs with known owners and business units.

Where this goes next: using AI to secure AI agents

No‑code AI agents are going to keep spreading because they’re useful. Trying to ban them outright usually backfires; you’ll just drive them further underground.

A better posture is to assume agents exist, then build controls that make risky behavior visible and stoppable. That’s the AI-in-cybersecurity story in a nutshell: we’re not choosing between innovation and security—we’re choosing between unmanaged automation and governed automation.

If you’re rolling out Copilot-style agents (or already have them), the next step is straightforward: create an agent inventory, tier them by risk, lock down connector permissions, and put monitoring in place that treats agent actions as first-class security events.

What would you discover if you audited every agent in your environment and mapped exactly which data stores it can touch—today?