City developers use an IDE security plug-in that flags risky patterns while building the permits API. What AI-assisted security use does this illustrate?

Using an IDE security plug-in that flags risky patterns while developers build the permits API illustrates AI-assisted AppSec guidance during municipal development because the control embeds analysis into the coding workflow where defects are cheapest to fix. Domain 3 emphasizes AI-enabled security tasks that augment practitioners; IDE plug-ins that highlight insecure APIs, injection sinks, or secrets are a canonical example. For a permits API that may handle applicant PII and payment-adjacent data, early static guidance reduces downstream incident risk.

IDE plug-ins that provide AI-enabled cloud-posture guidance during municipal development fail because assessing cloud configuration posture does not provide AppSec guidance on risky coding patterns while developers build the API. IDE plug-ins that provide AI-enabled SOC-triage guidance during municipal development fail because prioritizing SOC alerts for analysts does not flag risky coding patterns inside the editor while developers build the API. IDE plug-ins that provide AI-enabled threat-intel guidance during municipal development fail because surfacing adversary threat intelligence does not provide AppSec guidance on insecure coding patterns in the permits API.

Exam caveat: IDE findings are assistive, not authoritative proof of security—false positives/negatives exist, and AppSec guidance does not replace AI-enabled cloud-posture guidance, AI-enabled SOC-triage guidance, or AI-enabled threat-intel guidance. Operational check: require the AppSec plug-in (or equivalent SAST) in the developer baseline image, break the build or PR on high-severity rule hits for the permits service, and track mean time from flag to fix as a DevSecOps health metric.