Part 1 · assessment and mitigation recommendations · published v1.0 · 14 October 2026
An AI assistant treats hostile content as an instruction
SC10 · Customer support · internal knowledge assistants · AI-enabled business tools
What really happened
EchoLeak research described CVE-2025-32711, a prompt-injection data-exfiltration weakness in Microsoft 365 Copilot involving crafted email. It is used here as a published research demonstration, not a claim of a confirmed customer breach.
EchoLeak · published research paper
Evidence limit: The example is about a particular researched weakness. It does not prove every assistant is vulnerable or establish current exposure in a patched product.
The question for the client
Can untrusted content make our assistant expose another customer’s data or request an unauthorised tool action?
Business impact: Confidential-data disclosure, incorrect business decisions or unauthorised changes through connected tools.
- Systems involved
- Retrieved documents/messages, model context, identity and data filters, connected tools, action approvals and output channels.
- Where people fit
- Owners choose data scope and tool permissions; staff may trust an assistant’s output. The weakness can be in the system boundary even when nobody clicks a suspicious link.
How a similar risk could develop here
Proposed client threat model, not a reconstruction of undocumented incident details.
Place hostile instructions in lower-trust content → assistant processes it → model crosses a data or tool boundary → weak external authorisation permits disclosure or action.
Each route depends on several controls. If one stage is blocked, later checks can only continue as a separately authorised, clearly labelled assumed-compromise test. Do not claim an end-to-end attack succeeded merely because a downstream test identity was supplied.
Referenced attack-vector guides
Approval is specific, never inherited from the guide. Check the client, campaign, individual person/asset, method, channel, time window and risk ceiling. Deny overrides allow; absent, expired or withdrawn permission blocks the action. LOW/MED/HIGH describe proposed test impact, not permission or finding severity.
Read the approval rules.
Assessment playbook · Part 1
Start with G01 scope and Target Management, G02 intelligence gathering where needed, and G03 tool/resource preflight. Each selected vector receives its own scoped invocation record.
SC10-S01LOW · proposed test impact1. Map trust and action boundaries
Identify data tenants, connected tools and decisions that must be enforced outside the model.
- Why this is needed
- It tests a barrier in the route above and helps answer: Can untrusted content make our assistant expose another customer’s data or request an unauthorised tool action?
- Vector / method
- Tools and guides
- Repository input
- role-matrix.csv · RES-013 · published assessment resource; pin its version/hash in the case record.
- Output
- Trust-boundary map; attach evidence, target ID, vector version and approval revision.
- Measure
- Selected data/tool scopes with explicit authorisation rules / selected scopes. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Define and enforce the missing external data/tool authorisation boundary. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC10-S02MED · proposed test impact2. Run synthetic hostile and benign cases
Use the inert AI fixture and synthetic customer records in a sandbox with non-destructive tools.
- Why this is needed
- It tests a barrier in the route above and helps answer: Can untrusted content make our assistant expose another customer’s data or request an unauthorised tool action?
- Vector / method
- Tools and guides
- Decepticon · native service; handoff is not automatic execution
- PentestGPT · native service; handoff is not automatic execution
- Repository input
- ai-fixture.txt · RES-023 · published assessment resource; pin its version/hash in the case record.
- Output
- Input, response, tool-call and enforcement evidence; attach evidence, target ID, vector version and approval revision.
- Measure
- Unauthorised actions blocked / hostile cases; benign task success separately. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Reduce data/tool scope and prevent untrusted text from authorising a sensitive action. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC10-S03MED · proposed test impact3. Check interruption and policy changes
Evaluate cancellation, changed approvals and budget stop/resume on synthetic jobs without real external effects.
- Why this is needed
- It tests a barrier in the route above and helps answer: Can untrusted content make our assistant expose another customer’s data or request an unauthorised tool action?
- Vector / method
- Tools and guides
- HILLY · native service; handoff is not automatic execution
- Mission Control · native service; handoff is not automatic execution
- Repository input
- test-case.json · RES-006 · published assessment resource; pin its version/hash in the case record.
- Output
- Boundary and lifecycle findings; attach evidence, target ID, vector version and approval revision.
- Measure
- Cases with no duplicate or unauthorised effects / executed cases. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Improve policy rechecks, cancellation and duplicate prevention before connecting real external effects. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
Use one step-result record per case and G06 reporting for the client deliverable. The report must explain successes, failures, uncertainty, prohibitions and coverage limits.
Recommendations to reduce the risk
Reduce the likelihood: Separate trusted instructions from untrusted content and enforce data/tool authorisation independently of the model.
Reduce the impact if it happens: Limit accessible data and tool effects, require appropriate human approvals and retain evidence of consequential actions.
How to verify improvement later: repeat the failed control case and a permitted/clean comparison using the same agreed measure; compare conditions and evidence. A better test pass rate alone is not a quantified reduction in business risk.
End of Part 1: evidence-backed findings and mitigation recommendations. The implementation action plan, allocated work, commercial service packaging and costs are deliberately deferred.
Supporting TenguProtect capabilities
Baseline from the 13 October operational audit. This does not claim the complete service is ready or that permissions are already enforced across every agent.
| Capability | Observed readiness | Remaining gap |
|---|
| AI assistants, agents and connected-tool security | Usable audit component; adapter and workflow coverage limited | Refresh AgentShield after changes, validate relevant adapters and add controlled evaluation fixtures. One model call does not prove tool isolation or every agent role. |
| Cloud, SaaS, containers and source configuration | Resources present; full execution unproven | Choose one supported cloud and verify read-only permissions, selected scanners and report quality on a disposable fixture. Do not claim every cloud is supported. |