Our Brussels SaaS ships a Java service built with Maven. A platform engineer asked an AI for 'advanced fat-jar shading.' It returned an artifact name. He added it to pom.xml.
It was a hallucination. No such artifact existed in Maven Central until an attacker published it. The package included a Maven lifecycle hook that copied the build machine's ~/.m2/settings.xml into the produced jar's resources.
That settings.xml contained our private repository credentials — read-only tokens for our internal artifact server, but enough to pull every internal library we'd ever published. For a week, every jar we shipped to staging contained a copy of our repository keys, bundled inside the artifact, waiting to be unpacked.
We caught it when a staging artifact scan flagged an unexpected settings.xml in META-INF. One file, in one jar, in one build, and the whole thing unraveled.
We rotated the repository tokens. We removed the package and returned to the official maven-shade-plugin. We added PGP signature verification to our build and a check that fails the build if a settings.xml appears in any artifact's resources.
The lesson we now teach every new hire: an AI-suggested Maven coordinate is not a real coordinate until you've seen it in Central with the right checksum. The build will happily resolve a name a machine made up.