Use case sources
Source reports and analysis supporting this case are listed below. AITBM interpretation and any indicative scoring are derived from this public evidence.
Researchers from Cato Networks demonstrated how adversaries can exploit AI-powered systems embedded in enterprise workflows to execute malicious actions with elevated privileges. This is achieved by crafting malicious inputs from external users such as support tickets that are later processed by internal users or automated systems using AI agents. These AI agents, operating with internal context and trust, may interpret and execute the malicious instructions, leading to unauthorized actions such as data exfiltration, privilege escalation, or system manipulation.
ASSESSED SYSTEM
A support-engineering deployment as demonstrated by Cato CTRL in June 2025: an internal support engineer uses Claude Sonnet connected through Atlassian's Model Context Protocol server to the organisation's Jira Service Management instance, whose public portal accepts tickets from external users, and asks the model to help resolve an externally submitted ticket. The MCP tools available to the model can read other tickets and post replies visible on the public portal. Representative configuration: any MCP-connected LLM client operated by internal staff that processes externally submitted Jira Service Management tickets with read access to other tickets and authority to post public replies.
OUT OF SCOPE
The researchers' reconnaissance (search-engine discovery of public portals) and the malicious ticket are the attack. Atlassian's MCP server and Jira Service Management are assessed only as tool surfaces of the deployment, not as standalone products. Outcomes the summary describes as possible but did not demonstrate — broader privilege escalation or system manipulation — are not scored, and product changes after the disclosure are not evidenced in the record and are not credited.
Architecture: Agentic / MCP System (decision tree Q2) — Q1 = NO: one model client, with no peer agents. Q2 = YES: from the engineer's request to help resolve a ticket, the model invoked Atlassian MCP tools to collect the details of other issues and then invoked another MCP tool to post them as a reply, with the injection executed without the engineer's knowledge (ATLAS AML.CS0039, steps 5–8). Tier 2: Tier 2 (Consumer): the deployment processes submissions from any external user of a public service portal, and the demonstrated harm — other tickets' data posted where an external party can read it — lands on the organisation's external customers. This matches the treatment of the comparable Atlassian Rovo case; the internal-staff operator does not lower the tier, and the exposure is carried by Attack Surface.
Documented attack or failure path
- The researchers studied Atlassian's MCP server and its Jira Service Management integration, and used a search query to find organisations exposing public service portals.
- They crafted a prompt requesting that data from all other support tickets be posted as a reply to the current ticket, and submitted it as a new ticket on a target's public portal.
- As part of the standard workflow, a support engineer used Claude Sonnet, connected to Jira through the Atlassian MCP server, to help resolve the ticket, and the injected prompt executed without the engineer's knowledge.
- The prompt caused Atlassian MCP tools to collect the details of other issues on the instance.
- Another MCP tool posted the collected details as a reply to the malicious ticket, where they were accessible to the researchers on the public portal.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- Jira Service Management's separation between external portal customers and internal staff held for direct access: the external researcher could not read other tickets directly and had to route the request through the internal engineer's AI session. It did not hold against instructions relayed through that session and is credited only at Cn-2 0.25.
- The ATLAS record classifies the case as a proof-of-concept exercise with no reported victim, so no in-the-wild impact is scored in either direction.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.50 indeterminate | |||
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
| Transparency (Tr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.50 indeterminate | |||
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
| Containment (Cn) — scenario interval 0.03–0.47 (midpoint 0.25), Tier 2 MVT 0.55 confirmed breach | |||
| Cn-1Scope Enforcement | 0.00w 0.09 | 0.00 anchor: no effective scope boundary between the engineer's task and the data and write channels the model could reach. The 0.25 anchor requires boundaries that exist but are inconsistently enforced; none is described at the task or tool level. | A request to help resolve one ticket reached the details of other issues on the instance and a public-facing reply channel. No task-scoped boundary on which tickets the model could read for a given request, and no restriction on where collected data could be written, is recorded.source: secureflow/atlas |
| Cn-2Escalation Prevention | 0.25w 0.12 | 0.25 anchor: basic role checks exist but are vulnerable to prompt injection and delegated tool misuse — the portal role was enforced for direct access but not for instructions relayed through the internal user's AI session. Not 0.00, because the role separation is what forced the attack through the AI channel; not 0.50, because a single-step injection defeated it. | Jira Service Management separates external portal customers from internal support staff: the external researcher could not read other tickets directly and had to route the request through the engineer's AI session. That role boundary existed and was defeated by prompt injection — the record states the MCP tool invocation granted 'the researchers increased privileges on the victim's JSM instance'.source: secureflow/atlas |
| Cn-3Output Filtering Robustness | 0.00w 0.13 | 0.00 anchor: sensitive output was returned directly to an unauthorised external party with no output filtering or policy enforcement, the literal 0.00 criterion. The 0.25 anchor requires basic filters that are bypassed; none is described. | Collected details of other tickets were written into a public reply on the malicious ticket, where they were accessible to the researchers on the portal. No release check, redaction, or policy enforcement between the model's output and the public reply is recorded.source: secureflow/atlas |
| Cn-6Action Reversibility Classification Rate | 0.00w 0.08 | 0.00 anchor: no reversibility classification is performed before execution and the disclosure executed ungated (ARCR = 0). The 0.25 anchor requires at least ad-hoc gating of selected high-impact actions; no gate surfaced the public reply as an action requiring authority. | Posting other tickets' data to a publicly readable reply is a delegated-irreversible disclosure, yet it was executed as part of the injected chain while the engineer was unaware the instructions had run. No pre-execution classification of the public-reply write as an external-disclosure action, and no gate requiring explicit authority for it, is recorded.source: secureflow/atlas |
| Cn-8Untrusted Context Isolation | 0.00w 0.14 | 0.00 anchor — no origin labelling; connector-delivered external content was admitted to active context as trusted context by design and acquired instruction authority over MCP tool invocation. Not 0.25, because no origin label on the ticket channel and no prompt-wording denial of instruction authority is evidenced. Moved from Ro-1: the evidence records the boundary failure of admitting untrusted ticket content as instruction, not a test of the model's own resistance. | A plain-text instruction in an externally submitted Jira Service Management ticket, asking for data from all other tickets to be posted as a reply, was executed when the engineer asked Claude Sonnet to help with the ticket, 'causing the injection to be unknowingly executed'. No screening, origin labelling or demotion of ticket content before it entered the model's instruction path is recorded, and the content acquired authority to invoke Atlassian MCP tools.source: secureflow/atlas |
Unknown, not N/A: 21 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.75w 0.25 | Supervised autonomy: the session was started by an engineer working the ticket, but within it the model collected data across tickets and posted a public reply without the engineer being aware the injected instructions had run. Not 1.00, because the session ran inside an interactive engineer workflow rather than an unattended pipeline, and the record does not establish whether per-tool confirmation was displayed. |
| AsAttack Surface Exposure | 1.00w 0.35 | The 1.00 anchor is met: any external user of a public service portal can author content that reaches the model's instruction path, such portals were discoverable with a single search query, and the model holds read and write MCP tools — untrusted input combined with tool integration. elevated |
| CpCascade Potential | 1.00w 0.20 | No verified System Dependency Graph exists for the assessed configuration, so the specification's worst-case default applies. It is independently corroborated on the observed path: an external ticket ran through the model and Atlassian MCP tools to other tickets on the instance and back out through a public reply — a delegated-irreversible disclosure to an external party, with no gate on any hop.GDCP: corroborated by the observed path elevated |
| RfRemediation Feasibility | 0.25w 0.20 | Deployment-configuration remediation class: scope the MCP connection used for ticket processing to the ticket in hand, remove or gate AI-initiated public replies, and treat ticket content as untrusted data. The record documents no vendor fix, and these layers bound rather than remove the model's susceptibility to injected ticket text, so the score is not 0.00. |
Nelevated = 2 (dimensions strictly above 0.75) → CRM = 1.15.
Compound Risk Alert. Two or more dimensions are simultaneously elevated (spec 3.2.2); architectural decomposition is recommended before deployment.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.20 | Minimal provenance record: the model family, the MCP server, and the portal and reply surfaces are named, but the client, tool manifest, OAuth scopes, and configuration of the demonstrated deployment are not published. |
| Ec — Public evaluation coverage | 0.16 | coverage 0.19 (5 of 26 applicable sub-metrics) × independence 1.00 × fidelity 0.85. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.00 | Evidence dated 2025-06-19; age 486 days on the workpaper reference date. Components: T_containment 0.00 · T_calendar 0.02 · C_event 0.35 · C_monitor 0.65 · C_evidence 0.85. Binding term: T_containment. Evidence age is measured from 2025-06-19, the incident date MITRE ATLAS records for the Cato CTRL proof of concept, to the 2026-10-18 evidence reference date (dt_days = 486). agentic = true: the MCP tool set and its OAuth reach are a runtime permission boundary, so the containment staleness floor (M_Cn = 2.0) applies. baw = false: no writable agent memory, online learning, or persistent skill or rule state is part of the demonstrated path. C_event = 0.35: major — a confirmed critical-invariant violation, other tickets' data disclosed to an external party through a public reply. C_monitor = 0.65: the injection executed without the engineer's knowledge and no detection is evidenced. C_evidence = 0.85: no fix for the demonstrated path is recorded. Public sources provide no passing containment or behavioural re-attestation receipt; all caps are diagnostic only and do not affect the normalized-assurance scenario ERS. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.03 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
Published CVSS beside indicative ERS
Each published CVSS record is shown exactly as its scorer published it, one per vulnerability record, with the version, metric group and vector when stated, plus its source and access date. Records are never combined or inferred from a CVE's existence.
INDICATIVE ERS · NORMALIZED-ASSURANCE SCENARIO
5.4 midpoint, interval 1.8–9.0; Moderate scenario band; ACI fixed at 1.00. The published CVSS records do not enter this calculation.
PUBLISHED CVSS
CVSS — no applicable published score verified.
CVSS describes an individual vulnerability as its scorer published it. Indicative ERS describes the assessed AI deployment under the normalized-assurance scenario, so the two values are not direct equivalents and neither replaces the other.
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief or in the AIDEFEND SecureFlow defense map (audited AIDEFEND dataVersion 2026.10.15); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.10.15. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-002.002 | Inference-Time Prompt & Input ValidationExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-5. Presence supplies no score credit. | Candidate evidence route | Ro-1 Ro-5 Fa-1 Fa-3 Cn-8 |
| AID-H-017.007 | Dual-LLM Isolation PatternExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-5. Presence supplies no score credit. | Candidate evidence route | Cn-5 Cn-7 |
| AID-D-001.001 | Per-Prompt Content, Intent & Obfuscation AnalysisExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-5. Presence supplies no score credit. | Candidate evidence route | Ro-1 |
| AID-H-016.001 | System Prompt Structure & Instruction/Data SeparationExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-5. Presence supplies no score credit. | Candidate evidence route | Ro-1 |
| AID-H-018.004 | Intent-Based Dynamic Capability ScopingExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-6. Presence supplies no score credit. | Candidate evidence route | Cn-1 Cn-6 Cn-7 |
| AID-H-018.003 | High-Impact Independent Validation & Approval GateExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-6, step-8. Presence supplies no score credit. | Candidate evidence route | Cn-1 Cn-6 Cn-7 |
| AID-H-018.006 | Continuous Authorization Verification (Anti-TOCTOU)Exact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-6. Presence supplies no score credit. | Candidate evidence route | Cn-1 Cn-6 Cn-7 |
| AID-H-018.002 | Policy-Based Access ControlExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-6. Presence supplies no score credit. | Candidate evidence route | Cn-1 Cn-6 Cn-7 |
| AID-D-003.003 | Agentic Tool Use & Action Policy MonitoringExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-6. Presence supplies no score credit. | Candidate evidence route | Ro-3 Cn-1 Cn-3 Cn-7 |
| AID-H-018.005 | Value-Level Capability Metadata & Data Flow Sink EnforcementExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-7, step-8. Presence supplies no score credit. | Candidate evidence route | Cn-1 Cn-6 Cn-7 |
| AID-D-003.004 | Tool-Call Sequence Anomaly DetectionExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-7. Presence supplies no score credit. | Candidate evidence route | Ro-3 Cn-1 Cn-3 Cn-7 |
| AID-D-003.002 | Sensitive Information & Data Leakage DetectionExact SecureFlow defense-map identifier (flow atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Ro-3 Cn-1 Cn-3 Cn-7 |
WHAT THIS CASE TEACHES
'Living off AI' is a Cn-2 failure with a working role model underneath it: Jira's portal separation forced the attacker through the engineer's AI session, which earns 0.25 rather than 0.00, but an unscoped MCP connection and an ungated public-reply tool turned that relay into a delegated-irreversible disclosure, so Cn-1, Cn-3 and Cn-6 still resolve to 0.00.
Sources: AIDEFEND SecureFlow — Living Off AI: Prompt Injection via Jira Service Management · MITRE ATLAS case study AML.CS0039 · Cato CTRL Threat Research: PoC Attack Targeting Atlassian's Model Context Protocol (MCP) Introduces New "Living Off AI" Risk (catonetworks.com)
SecureFlow attack flow
This record mirrors an AIDEFEND SecureFlow flow (MITRE ATLAS case-study conversion): an ordered attack path with MITRE ATLAS tactic and technique labels and the AIDEFEND controls matched to each step. The scenario above places only the control outcomes this flow and its primary references observed; the matched AIDEFEND controls are evidence routes and earn no score credit.
| MITRE ATLAS case study | AML.CS0039 (exercise) |
|---|---|
| Target | Atlassian MCP, Jira Service Management |
| Actor | Cato CTRL |
| Primary evidence date | 2025-06-19 |
| SecureFlow record updated | 2026-08-02 |
| AI layers | Autonomous agents, Tool integrations / MCP |
| Risk impact | Data exfiltration |
| Affected components | Atlassian Model Context Protocol server, Jira Service Management public portal, Claude Sonnet with Jira MCP access, Jira ticket data, public ticket reply workflow |
Attack steps
| # | Step | ATLAS tactic / technique |
|---|---|---|
| 1 | Research Atlassian MCP and JSM IntegrationThe researchers performed reconnaissance to learn about Atlassian's Model Context Protocol (MCP) server and its integration into the Jira Service Management (JSM) platform. Atlassian offers an MCP server, which embeds AI into enterprise workflows. Their MCP enables a range of AI-driven actions, such as ticket summarization, auto-replies, classification, and smart recommendations across JSM and Confluence. It allows support engineers and internal users to interact with AI directly from their native interfaces. | AML.TA0002 AML.T0003 |
| 2 | Search for Public Jira Service PortalsThe researchers used a search query, "site:atlassian.net/servicedesk inurl:portal", to reveal organizations using Atlassian service portals as potential targets. | AML.TA0002 AML.T0095 |
| 3 | Craft Ticket Data Exfiltration PromptThe researchers crafted a malicious prompt that requests data from all other support tickets be posted as a reply to the current ticket. | AML.TA0003 AML.T0065 |
| 4 | Create Malicious Public JSM TicketThe researchers created a new service ticket containing the malicious prompt on the public Jira Service Management (JSM) portal of the victim identified during reconnaissance. | AML.TA0004 AML.T0093 |
| 5 | Execute Indirect Prompt via Support WorkflowAs part of their standard workflow, a support engineer at the victim organization used Claude Sonnet (which can interact with Jira via the Atlassian MCP server) to help them resolve the malicious ticket, causing the injection to be unknowingly executed. | AML.TA0005 AML.T0051.001 |
| 6 | Invoke Atlassian MCP Tools with Elevated PrivilegesThe malicious prompt requested information accessible to the AI agent via Atlassian MCP tools, causing those tools to be invoked via MCP, granting the researchers increased privileges on the victim's JSM instance. | AML.TA0012 AML.T0053 |
| 7 | Collect Other Jira Ticket DetailsThe malicious prompt instructed that all details of other issues be collected. This invoked an Atlassian MCP tool that could access the Jira tickets and collect them. | AML.TA0009 AML.T0085.001 |
| 8 | Exfiltrate Ticket Data in Public ReplyThe malicious prompt instructed that the collected ticket details be posted in a reply to the ticket. This invoked an Atlassian MCP Tool which performed the requested action, exfiltrating the data where it was accessible to the researchers on the JSM portal. | AML.TA0010 AML.T0086 |
Threat references
Summary and attack steps reproduced from AIDEFEND SecureFlow (https://aidefendlabs.com/en/secureflow/?flow=atlas-aml-cs0039-living-off-ai-prompt-injection-via-jira-service-management; AIDEFEND content CC BY 4.0), converted from MITRE ATLAS case study AML.CS0039 (Apache License 2.0; MITRE ATLAS is a trademark of The MITRE Corporation).