Mistake L2 · Context engineering informational

Don't Ship the AI's Insecure Defaults

What it is

The quiet class of security holes that come not from missing code but from settings the AI leaves in a convenient-for-development, dangerous-for-production state: debug mode on, verbose error messages that leak internals, wide-open cross-origin (CORS) rules, default admin credentials, and permissive file or bucket permissions.

Why it works

AI optimises for 'it works on your machine', and the settings that make development easy are exactly the ones that expose you in production. Debug pages reveal your stack and sometimes secrets; verbose errors hand attackers a map; open CORS lets any site call your API; a default password is a published key. None of these break your app, so they sail through your own testing and only help an attacker.

When to use it

Before every deployment, and whenever you move from a local build to anything reachable online. Treat 'going to production' as a distinct step with its own settings, not just the same app on a public URL.

When not to use it

Development conveniences are fine while the app is genuinely local and unreachable. The rule is about the transition to public — that's when the defaults must be tightened.

Prompt

Prepare this app for production and check for insecure defaults: turn off debug mode, make error responses generic (log details server-side, don't send stack traces to users), restrict CORS to the origins that actually need it, remove or change any default credentials, and tighten any file/storage permissions to least privilege. List each setting you changed and its safe production value.

Example

An app is deployed straight from its dev configuration. A user triggers an error and gets a full stack trace showing file paths, library versions, and part of a connection string — a free reconnaissance report for an attacker. Switching to generic error pages and disabling debug mode closes it.

Advanced version

Keep separate, explicit configuration for development and production so you never ship dev settings by accident, add security response headers, and do a final pass asking the AI to enumerate every setting that differs from a hardened production baseline. Automate a check that debug mode and wildcard CORS can never reach production.

Common mistakes

  • Deploying the exact development configuration to production because the app 'already works'.
  • Sending detailed error messages and stack traces to users instead of logging them privately.
  • Leaving CORS or storage permissions wide open because that was the AI's frictionless default.

Related