An attacker abuses a weak plugin that lets the 311 bot create forged work orders in the city’s CMMS. What failure mode is this?

Classifying abuse of a weak plugin that lets a 311 bot create forged work orders in the city’s CMMS as integration abuse from an insecure plug-in with excessive write access is correct because the assistant’s tool bridge grants unauthorized downstream mutation. AI assistants become high-impact when connected to ticketing, CMMS, or ERP write APIs without least privilege, approval gates, or action attestation. Forged work orders waste crews, hide true backlog, and can be used for fraud or sabotage of municipal operations.

Prompt injection via crafted requests that misdirect the assistant into creating false orders fails because the scenario describes abusing a plugin’s excessive write access to forge CMMS records, not tricking the assistant through crafted user input. Model hallucination from incomplete municipal records that fabricates unauthorized CMMS work orders fails because the issue is attacker abuse of an insecure plugin to create forged work orders, not the model mistakenly inventing orders from incomplete data on its own. Excessive agency via autonomous routines that enable the assistant to create forged work orders fails because the failure is an insecure plug-in granting excessive write access to the CMMS, not autonomous routines overstepping on their own.

Exam caveat: integration abuse can look like a busy legitimate bot if volume alone is monitored; defenders must validate action provenance (who/what authorized each CMMS create) rather than only counting tickets. Operational check: inventory all 311/assistant plugins and scopes, revoke write capabilities not justified by a documented use case, require dual control or human approval for CMMS creates/updates, and alert on work orders created by service accounts outside business hours or without a matching authenticated citizen request.