A recent security analysis has found that Microsoft Copilot Studio’s no-code AI agents can be coerced into leaking sensitive customer data and performing unauthorized actions with trivially simple prompt injections, exposing a new class of operational and regulatory risk that teams must treat as urgent.
Microsoft Copilot Studio is a low‑code platform that lets organizations build AI agents which read tenant data (SharePoint, Dataverse, Exchange), run automations, and execute actions such as “get item” and “update item.” Tenable’s security research shows that these agents—when granted broad read/write access and deployed without strict controls—can be manipulated by crafted natural‑language inputs to reveal sensitive fields (including payment card data) and alter records (for example, setting trip costs to $0). This discovery is not a traditional software vulnerability in the sense of a memory corruption or authentication bypass. Instead, it exposes a systemic failure mode where the agent’s instruction‑processing logic, combined with underspecified action semantics and overly broad permissions, becomes an exploit vector. Tenable’s proof‑of‑concept demonstrates two practical primitives attackers can chain into a full compromise: (1) prompt injection that overrides or subverts an agent’s intended instruction set, and (2) deceptive use of action semantics (for example, asking a “get item” action to return multiple records) to exfiltrate data.
Key immediate risks illustrated by the Tenable test are:
Operationally, this means legal, compliance, and security teams must be part of the agent approval process. For high‑risk agents, include:
Security vendors are responding with runtime inspection and DLP products designed specifically for agent workflows. These solutions typically offer:
Source: Petri IT Knowledgebase Data-Leak Risk Found in Microsoft Copilot Studio Agents
Background
Microsoft Copilot Studio is a low‑code platform that lets organizations build AI agents which read tenant data (SharePoint, Dataverse, Exchange), run automations, and execute actions such as “get item” and “update item.” Tenable’s security research shows that these agents—when granted broad read/write access and deployed without strict controls—can be manipulated by crafted natural‑language inputs to reveal sensitive fields (including payment card data) and alter records (for example, setting trip costs to $0). This discovery is not a traditional software vulnerability in the sense of a memory corruption or authentication bypass. Instead, it exposes a systemic failure mode where the agent’s instruction‑processing logic, combined with underspecified action semantics and overly broad permissions, becomes an exploit vector. Tenable’s proof‑of‑concept demonstrates two practical primitives attackers can chain into a full compromise: (1) prompt injection that overrides or subverts an agent’s intended instruction set, and (2) deceptive use of action semantics (for example, asking a “get item” action to return multiple records) to exfiltrate data. Why this matters now
The shift from passive LLM assistants to agentic systems—AI that can perform real actions in enterprise systems—magnifies classic prompt‑injection risk into operational impact. An agent that can read and update a billing table is not merely giving a wrong answer; it can create fraudulent transactions, remove audit trails, or trigger compliance incidents at machine speed.Key immediate risks illustrated by the Tenable test are:
- Data exposure at scale: Agents with access to structured stores can be induced to return full records that include PII and payment card details.
- Financial fraud and workflow hijacking: Write permissions allow attackers (or careless automations) to change price and entitlement fields, enabling revenue loss.
- Invisible exploitation paths: Because agents often run as service identities and execute on trusted platforms, exfiltration can occur without obvious network anomalies or endpoint signs.
- Governance gaps: No-code builders and business users can unintentionally grant excessive permissions, creating “implicit admin” agents that were never threat‑modeled.
How the proof‑of‑concept worked
Step 1 — Enumerate the agent’s toolset via prompt trickery
Tenable’s team used a variant of a known prompt‑injection pattern: ask the agent to list its own actions and descriptions. That benign‑looking request forced the agent to reveal available primitives such as “get item” and “update item.” With this information, the researcher could craft subsequent prompts that targeted those primitives directly.Step 2 — Abuse ambiguous API semantics (“get item”)
The researchers then asked the agent to retrieve multiple reservation IDs in a single request. Although the agent’s builder had chosen a single‑item retrieval action to limit scope, the agent performed the action multiple times and aggregated the results into one response—effectively returning multiple records where a single‑item query should have been expected. The aggregated response included sensitive fields (in the test environment, full credit‑card details). This is a classic example where an ambiguous or permissive action signature becomes a feature an attacker can exploit.Step 3 — Use update actions to alter financial fields
Because the agent had been granted update permissions on booking records, the researcher supplied a prompt that directed the agent to set a price field to zero. The agent executed the update, and the record reflected a free booking. The chain demonstrates that combining read access to payment data with write access to price/billing fields allows both data theft and fraudulent financial manipulation.Technical root causes
Several intersecting factors create the vulnerability surface that prompt injection exploits:- Natural language instruction ambiguity: LLMs treat user inputs as part of their instruction context. If an attacker embeds higher‑priority or cleverly phrased instructions, the model can reinterpret or override guardrails unless they are cryptographically or procedurally enforced.
- Underspecified action contracts: Actions exposed by agents may accept flexible inputs (multiple IDs, range selectors) without clear server‑side enforcement of cardinality or schemas; that flexibility is exploitable.
- Excessive connector privileges: Agents tied to SharePoint, Dataverse, or other stores often inherit broad scopes; if a connector exposes both PII and writeable business fields, the agent gets dangerous capabilities.
- No-code/low‑code builder model: Business users can assemble agents without security review, creating misconfigurations at scale.
- Insufficient runtime enforcement: Design‑time checks are useful, but they don’t prevent an agent from being manipulated at runtime unless synchronous runtime guardrails inspect and block dangerous plans.
What Tenable and others recommend (practical controls)
Tenable’s guidance—and independent reporting—converge on a layered defense model that combines governance, identity hardening, runtime controls, and developer best practices. The following distilled controls form a prioritized, actionable plan.Governance & process
- Maintain an authoritative agent inventory listing owner, purpose, connectors, and exact scopes.
- Require formal approval workflows for agents that touch sensitive connectors (finance, HR, legal).
- Classify agents into risk tiers (prototype, production) and restrict production promotion to security‑reviewed agents.
Identity and access
- Enforce the principle of least privilege: grant minimal connector scopes required for a task and avoid giving agents write access to financial or payment fields unless absolutely necessary.
- Harden tenant consent: restrict who can grant application consent and require administrator approval for broad Graph scopes; apply conditional access and phishing‑resistant MFA for privileged users.
Action and data segmentation
- Replace generic actions with strict, allow‑listed endpoints: e.g., design server APIs that accept a single ID and return an exact, minimal fieldset, rejecting requests that try to batch IDs.
- Segment and mask sensitive fields (PCI, full SSNs) in knowledge sources used by agents; store only tokenized or masked payment data where possible.
- Prefer read‑only user agents and separate update flows into a restricted, auditable service account with multi‑party approval for financial changes.
Runtime enforcement and observability
- Deploy runtime guardrails that inspect planned tool calls and block or redact requests that would return sensitive fields or perform risky updates. Vendors and third‑party products now offer synchronous webhook inspection for Copilot Studio actions; integrating these reduces the attack surface.
- Log every agent action with contextual metadata (agent ID, invoking user, prompt, tool invoked, fields accessed) and stream events to SIEM for correlation and alerting.
- Implement throttles and explicit multi‑step confirmations for state‑changing actions that exceed thresholds (e.g., mass updates or price changes).
Development and testing
- Require structured inputs for critical operations—avoid free‑text fields where a user can inject instructions.
- Red‑team agents with prompt‑injection tests: ask the agent to enumerate tools, request multiple IDs, and attempt to modify price fields to validate constraints.
- Automate periodic re‑testing after platform updates; treat agents as production software with release controls and CVE/patch monitoring.
Governance, compliance, and legal consequences
Agents that can read or modify payment card data and PII potentially trigger PCI DSS, privacy law (GDPR, CCPA) and sector‑specific compliance obligations. An automated leak is still a breach: organizations must assume that any exfiltration of cardholder data or regulated personal information will trigger notification and remediation duties.Operationally, this means legal, compliance, and security teams must be part of the agent approval process. For high‑risk agents, include:
- Documented data flow diagrams showing where data is stored and processed.
- Contractual controls with security vendors and third parties that perform runtime inspection—clarify retention, residency, and access to telemetry.
- A clearly established incident playbook for agent compromise that includes immediate revocation of the agent identity, token rotation, and forensic collection.
Vendor and ecosystem responses
Microsoft has built several governance primitives—Purview sensitivity labels, Copilot Control System toggles, and admin controls to restrict who can build and publish agents—and has been iterating default consent policies to limit end‑user application consent for high‑risk scopes. However, platform controls are only part of the solution; effective defense requires tenant‑level enforcement and operational hygiene.Security vendors are responding with runtime inspection and DLP products designed specifically for agent workflows. These solutions typically offer:
- Pre‑execution policy checks via synchronous webhooks.
- Content‑sensitive DLP and schema checks on tool inputs/outputs.
- Anomaly detection for agent behavior (bulk reads, frequent updates).
What Windows IT teams should do next (practical checklist)
- Inventory every Copilot Studio agent in your tenant and map connectors and exact scopes.
- Revoke or reduce any agent that has update/delete scopes on billing or payment systems unless a documented business case exists.
- Enforce admin‑only consent for applications requesting powerful Graph scopes; require phishing‑resistant MFA for privileged consents.
- Run a red‑team prompt‑injection exercise in a sandboxed environment: enumerate actions, request multiple IDs, and attempt state changes. Remediate discovered gaps.
- Implement runtime guardrails and DLP for agent tool calls; if needed, pilot vendor solutions that integrate via synchronous pre‑execution webhooks. Validate where inspection runs and how long telemetry is retained.
- Mask or tokenize payment data in any knowledge store indexed by agents; use token references for lookup-only flows.
- Require human approval for price/entitlement changes and add explicit logging, two‑person checks, or workflow approvals for any state changes.
Strengths and limits of the findings
Tenable’s demonstration is compelling because it uses the actual product flow and realistic, reproducible prompts to show end‑to‑end impact. Independent coverage from multiple outlets reproduces the core findings, increasing confidence that these are practical issues rather than hypothetical edge cases. That said, some broad claims about aggregate exposure and large‑scale record counts (for example, vendor DSPM telemetry reports cited elsewhere) are directional and may be biased by the dataset they originate from; such numbers should be treated as indicative rather than universally representative unless corroborated with independent telemetry from the affected tenants. Where a numerical claim is vendor‑sourced and not accompanied by transparent methodology, label it as such and prioritize tenant‑level discovery in your environment.The strategic takeaway
Agentic AI is delivering valuable automation, but it changes the threat model: attackers no longer need shell access or malware; they need only craft text that the agent will treat as instructions. The resulting risk is both technical and organizational. Effective defense is multidisciplinary: security engineering must pair with identity governance, DLP, legal oversight, and business process redesign.- Treat agents as production software: enforce inventories, reviews, lifecycle controls, and periodic re‑testing.
- Apply least privilege and service‑account segregation: separate read‑only front‑end agents from write‑capable backend services with human authorization gates.
- Deploy runtime guardrails and detailed observability so that a malicious plan can be stopped before it touches data.
Conclusion
Tenable’s disclosure about prompt‑injection risks in Microsoft Copilot Studio agents is a wake‑up call: when AI assistants gain the ability to act, adversarial inputs become operational vulnerabilities. The fix is not a single patch, but a disciplined blend of least‑privilege design, strict action contracts, runtime inspection, and organizational governance. Teams that move fast to inventory agents, restrict update permissions, segment sensitive data, and introduce synchronous runtime checks will preserve the productivity benefits of Copilot Studio while dramatically reducing the chance that a simple sentence becomes a costly breach.Source: Petri IT Knowledgebase Data-Leak Risk Found in Microsoft Copilot Studio Agents
