Start every AI-built prototype with login required on every route, deny-by-default access, least-privilege credentials, debug modes off and public sharing off. Defaults matter because prototypes are built fast, and people rarely revisit settings that already work. The safe setting should be the one nobody has to remember.
The idea behind secure defaults
CISA's Secure by Design material argues that products should be secure out of the box, with additional security features available as needed, and that security is a core business requirement rather than only a technical feature. You can apply the same thinking to your own prototypes: make the safe choice the starting point, and require a reason to loosen it.
Five defaults to adopt
1. Authentication on for everything. Add login at the framework or gateway level so new routes inherit it. Public pages are then the exception you list on purpose, rather than the routes someone forgot to protect.
2. Deny by default for data. A request gets data only if a rule says it may. This is the opposite of building the feature and adding checks later. OWASP's 2025 Top 10 puts broken access control first, which is a reminder that missing checks are common.
3. Least privilege for credentials and service accounts. Grant the narrowest scope that works. If a prototype needs to read one storage bucket, it should not hold rights to the account.
4. Debug off, errors quiet. Detailed stack traces help attackers. Set production-like error handling in the template and turn debug on locally only.
5. Private by default. New repositories, deployments and storage buckets start private. Sharing is an explicit step.
Put the defaults into a template
Defaults only work if they are present at the start. Build a starter template that includes:
- A framework configuration with authentication applied globally.
- An example permission rule with a failing test for a user reading another user's data.
- Environment variables split into public and secret.
- A deployment configuration that is private and spend limited.
- An instruction file for your AI assistant that states these rules.
Tell the assistant, then check
Assistants follow instructions imperfectly. State the defaults in the repository's rules file, then verify with automated tests and a review. A test that calls every route without login and expects a refusal is a cheap check you can run on every change.
What a failing default looks like
You will know a default has failed when a new route is reachable without login, when a new bucket is public, or when a service account has rights it never uses. Write a small automated check for each: call new routes without credentials, list public resources, and compare granted permissions with permissions used. Run them in CI so a regression is caught in the pull request, not in production.
Handling exceptions
Sometimes a route must be public. Write it into a short allowlist with a reason and an owner. Anything not on the list is private.
Where Safeguard fits
Safeguard offers policies, gates and guardrails, including an MCP Guardrail for agent tool use, so some of these defaults can be enforced rather than only requested. Try a free scan at gold.safeguard.sh/scan.
Quick check
What is the quickest default to adopt today?
Make login required for all routes at the framework level, with a short list of public exceptions.
Do defaults replace review?
No. They reduce the number of mistakes that reach review. You still need a human to read the risky parts.
Sources
Last reviewed: 19 October 2026.
