I see this a lot in SaaS contracts. The assistant writes clean, functional code to integrate an API, but completely misses the security implications baked into that integration.
Think of it like a junior dev who can follow a tutorial but doesn't know the "why." They'll give you working code that:
* Uses hardcoded API keys in a client-side script
* Doesn't validate or sanitize input
* Skips audit logging because it wasn't in the spec
* Chooses the simplest connection method (HTTP vs. HTTPS) to make it work
They're optimizing for "it runs," not for "it's secure." It's the same in vendor management—a slick contract can have terrible terms if you don't know what clauses to benchmark.
Example prompt: "Write a Python script to save user data from a form to our database."
The output works. But it might:
* Use string concatenation for SQL (hello, injection!)
* Store passwords in plaintext
* Have no rate limiting
The correct answer isn't just the code—it's the secure architecture around it, which requires context they don't have.