No-Code AI Agents Are Leaking Data—Stop It Fast

A single prompt shouldn’t be able to expose customer credit card details. Yet that’s exactly what security researchers demonstrated with a no-code AI agent built in Microsoft Copilot Studio: they connected a chatbot to a data source, added explicit “don’t reveal other customers’ data” instructions, and still pulled sensitive records with basic prompt injection.

Most companies get this wrong because they treat AI agents like “just another chatbot.” They’re not. An agent that can read SharePoint files, update bookings, or trigger workflows isn’t a conversation layer—it’s an operational identity with hands on the keyboard. And when non-technical teams can create those identities in minutes, your attack surface expands faster than your security program can keep up.

This post is part of our AI in Cybersecurity series, where we focus on practical ways AI helps detect threats, prevent fraud, and automate security operations. Here, we’ll use the Copilot Studio case study as a cautionary example—and then get concrete about the guardrails and AI-powered detection you need to prevent data leaks in real time.

Why no-code AI agents create a new, risky attack surface

No-code AI agents are risky because they combine three things attackers love: broad access, easy deployment, and ambiguous intent. Traditional apps usually have explicit routes, permissions, and tests. AI agents often have all the same privileges—but with a natural-language interface that’s harder to constrain.

A modern enterprise “agent” typically includes:

• An LLM-driven chat interface (customers or employees talk to it)
• Connections to internal data sources (SharePoint, CRM, ticketing, HRIS)
• Tool permissions (read, write, edit, send email, create tickets, update records)
• Autonomy (it can take actions without a human clicking every step)

That combination changes your security model. Your question isn’t just “Is the model safe?” It’s:

“What can this agent access, what can it do, and how easily can someone talk it into doing the wrong thing?”

The myth: “We’ll just put it in the system prompt”

Many teams assume that if they write a strong system instruction—never reveal other customers’ data—the agent will comply. The Copilot Studio experiment shows the opposite: a user can often override or sidestep those instructions with prompt injection, because the model tries to be helpful and may treat adversarial instructions as legitimate.

The uncomfortable stance I’ll take: policy-by-prompt is not a security control. It’s documentation.

Shadow AI turns “a few bots” into hundreds of unmanaged identities

The bigger operational problem is scale. No-code platforms make it easy for business units to create agents without security review. In practice, that leads to:

• Untracked agents connected to sensitive data stores
• Over-permissioned connectors (“edit everything” because it worked)
• Copy-pasted prompts that include secrets, internal URLs, or workflow details
• Agents deployed for seasonal crunch (hello, end-of-year travel and expense approvals) that never get decommissioned

December is a perfect storm: teams are closing deals, reconciling budgets, handling travel, and staffing is thinner. Attackers know governance gets looser during peak business periods.

How prompt injection becomes a data leak (and a workflow takeover)

Prompt injection works because the model can’t reliably distinguish “instructions it should follow” from “text a user typed that looks like instructions.” If the agent also has tool access, the blast radius grows.

The Copilot Studio case study highlighted two classic failure modes:

1) Sensitive data exfiltration via connected knowledge sources

Researchers created a travel-booking chatbot and connected it to a file (SharePoint in the example) containing customer names and payment details. Even with explicit instructions preventing cross-customer access, the agent was still coaxed into revealing other customers’ information.

This is the pattern to recognize:

• RAG/knowledge connection (the agent can fetch internal documents)
• Weak authorization layer (the agent decides what’s allowed)
• Natural-language exploitation (attacker tries variations until it spills)

If your agent can “look things up,” you must assume an attacker will attempt to make it look up the wrong things.

2) Unauthorized state changes (the “make it $0” problem)

The scarier demo wasn’t just reading data—it was editing it. In the experiment, a simple prompt changed a booking price to $0.

That maps directly to fraud and abuse scenarios:

• Discount abuse (“apply a 100% discount because I’m a VIP”)
• Refund manipulation (“issue refund to this card instead”)
• Account takeover-by-agent (“update email to mine, then reset password”)
• Invoice tampering (“change bank account details for vendor payment”)

Here’s the one-liner that should stick:

If an AI agent can write to a system, prompt injection becomes a business logic exploit.

Why this isn’t a Microsoft-only issue

The underlying risk is endemic to agent platforms, not a single vendor. Any tool that makes it easy to:

1. Connect an LLM to enterprise data, and
2. Grant that LLM the ability to take actions

…inherits the same classes of vulnerabilities: prompt injection, data overexposure, tool misuse, and authorization confusion.

Even “good” teams fall into traps because agent builders optimize for time-to-value:

• Default connectors come with broad scopes
• “Works in dev” quickly becomes “ship to production”
• The person building the agent owns the process, not the risk

I’ve found the only reliable way to manage this is to treat agents like any other software component plus an identity layer:

• Inventory them
• Threat model them
• Permission them like a service account
• Monitor them like a privileged user

The right guardrails: design controls that actually hold up

Start by assuming the model will be manipulated. Then build controls that don’t rely on the model to “do the right thing.”

1) Put authorization outside the model

Your agent should never be the final authority on access. Instead:

• Enforce row-level and object-level authorization in the data source
• Use connectors that support per-user token passthrough (act as the caller)
• Avoid “shared bot accounts” that can see everything

If the agent is customer-facing, make sure every data fetch is scoped to:

• the authenticated customer identity
• the specific record(s) that identity owns

If you can’t enforce that mechanically, don’t connect that dataset.

2) Minimize permissions like you would for service accounts

Most agent deployments fail the same way cloud IAM fails: wildcard permissions.

Set defaults like:

• Read-only unless there’s a clear business need
• Write actions require additional verification (see below)
• Separate agents for separate tasks (don’t make one “super agent”)

A practical pattern:

• Info agent (read-only, limited datasets)
• Action agent (write permissions, heavily monitored, narrower scope)

3) Add “human-in-the-loop” where money or identity changes hands

Not every action needs approval, but certain actions absolutely should.

Require a second step for:

• Price changes, refunds, discounts
• Banking detail updates
• Account recovery changes (email/phone)
• High-volume exports

This doesn’t have to be clunky. A lightweight approval queue or step-up authentication can stop the “set it to $0” class of attacks cold.

4) Instrument the agent like an application (because it is one)

Log and retain:

• User prompts and system messages (with privacy controls)
• Tool calls (what was accessed/changed)
• Data objects touched (which records)
• Response output (what was shown to the user)

If you can’t answer who accessed what through the agent, you can’t investigate incidents—or prove you’re not leaking data.

Where AI-driven security helps: detect leaks before they become incidents

AI agents create AI-shaped problems: high-volume interactions, ambiguous intent, and fast-changing behavior. AI-driven cybersecurity is well-suited to monitor and stop that in real time.

Here’s what “AI-powered threat detection and policy enforcement” should look like for agentic systems.

Real-time anomaly detection for agent behavior

Look for patterns that differ from normal usage:

• Sudden spikes in document retrieval or tool calls
• Unusual combinations (customer chat + access to admin datasets)
• Requests for “all records,” “export,” or broad summaries
• Repeated probing attempts that resemble jailbreak iteration

This is where ML-based baselining shines: it can flag behavioral outliers that static rules miss.

Data loss prevention (DLP) tuned for conversational exfiltration

Classic DLP focuses on email attachments and file uploads. Agent leaks often happen as small text snippets—names, partial card numbers, booking details—returned in chat.

Modern DLP for AI should:

• Inspect agent outputs for sensitive data patterns
• Redact or block regulated fields (PCI, PII, PHI) by policy
• Enforce “no cross-tenant/no cross-customer” constraints

If you’re only scanning files at rest, you’re missing where the leak actually occurs: the agent’s response channel.

Automated security operations for “shadow AI” discovery

You can’t secure what you don’t know exists. AI-assisted security operations can:

• Discover agent deployments across the environment
• Map connectors and permissions automatically
• Identify agents with risky scopes (e.g., write access to finance)
• Trigger remediation workflows (owner notification, permission reduction)

This is the operational bridge to the campaign theme: AI can both introduce risk and help you manage that risk at enterprise scale.

A practical checklist to secure Copilot-style agents in 30 days

You don’t need a year-long program to reduce risk. You need visibility, permissions discipline, and monitoring. Here’s a realistic 30-day plan I’d run with a CISO or AppSec lead.

Week 1: Inventory and ownership

• Find all deployed agents (official and “shadow AI”)
• Assign a business owner and a technical owner to each
• Document connected systems (SharePoint, CRM, ticketing)

Week 2: Permission hardening

• Remove broad “edit” permissions by default
• Split read-only and write-capable agents
• Require approval for high-risk actions (refunds, pricing, identity)

Week 3: Guardrails and testing

• Run prompt-injection test scripts against top agents
• Add output filtering for PII/PCI and sensitive fields n- Enforce server-side authorization checks in data access layers

Week 4: Monitoring and response

• Centralize logs for prompts, tool calls, and outputs
• Set anomaly alerts for scraping/export patterns
• Add a response playbook: disable agent, revoke tokens, rotate secrets

If you do only one thing: stop trusting the prompt to enforce access control. Make the data layer enforce it.

The bigger point for the AI in Cybersecurity series

No-code AI agents will keep spreading because they’re useful. The business value is real. But the security posture can’t be “hope the model behaves.” The Copilot Studio case study makes that painfully clear: a helpful model plus privileged connectors equals a predictable leak path.

If you’re rolling out AI agents in 2026 planning cycles, treat them like production apps and privileged identities—and backstop them with AI-driven detection that watches behavior, not just signatures.

If you’re not sure where to start, start with this: Which agents can read sensitive data? Which agents can change money or identity? And what would you see in your logs if an attacker tried both?