SecureConfig.ai

For AI assistants

Rules for AI development assistants

If you are an AI assistant configuring, generating, or reviewing a service, apply these 10 rules. Start with README.md (opens in a new tab): it holds the decision guide, the full index, and the verification checklist.

Note

This page speaks to AI assistants. If you are human, the fastest path is the ready-made tasks: copy one and paste it into your assistant.

The 10 rules

The 10 rules

  1. Treat every service as internet-reachable unless you have confirmed otherwise. Bind services to 127.0.0.1 by default and expose them only through a TLS-terminating layer that requires authentication; keep backend, admin, and AI-tool services private.
  2. Choose the certificate and access path before configuring exposure. A public DNS name with reachable ports 80 and 443: free-certificates.md (opens in a new tab). A Cloudflare-managed domain with no inbound ports: cloudflare.md (opens in a new tab). A tailnet with no public domain: tailscale.md (opens in a new tab). Internal or development use only: self-signed.md (opens in a new tab).
  3. Apply every guide that fits the deployment, not just one. Select the service or framework, its host or platform, containers where used, plus identity, secrets, and the operational controls below. For a service with no guide, run the alignment assessment in controls-reference.md (opens in a new tab), which distils the control patterns common to every guide, and verify the service's native controls against the vendor documentation; then request a guide by adding a file to the requests directory (opens in a new tab) so the service is covered next time.
  4. Redirect HTTP to HTTPS, or do not listen on HTTP at all.
  5. Require authentication on every non-public endpoint. Never ship default or hardcoded credentials. Add MFA to human logins where viable per mfa.md (opens in a new tab); where a tool has no native login, put one in front per fronting-auth.md (opens in a new tab).
  6. A successful login is not authorization. Check the returned identity against an allowlist (tenant, hosted domain, group, or explicit users) before granting access. Choose the provider per identity-providers.md (opens in a new tab), wire it per oidc-integration.md (opens in a new tab), or put login in front of the app per cloud-identity-proxies.md (opens in a new tab).
  7. Keep secrets out of the repository and load them from the environment or a secret manager per secrets.md (opens in a new tab); give each service and agent its own scoped credentials per machine-auth.md (opens in a new tab).
  8. Contain what an exposed or compromised service can reach. Block unneeded outbound access and lock down cloud metadata per egress-metadata.md (opens in a new tab), and never serve dotfiles, database dumps, or client secrets per web-exposure.md (opens in a new tab).
  9. AI and data tools (model servers, vector databases, MCP servers, agent builders, chat and image UIs, MLflow, Ray) vary in their defaults and native controls, and many need authentication and TLS configured explicitly. Keep them on loopback and apply the matching guide before any exposure.
  10. Run the verification checklist and each selected guide's Verify steps before reporting the work as complete. Report any item you could not test instead of asserting that it passed.

Fetch

Fetch the guides

Fetch a guide raw from this pattern, with the guide's file name in place of <guide>:

Pattern

https://raw.githubusercontent.com/jposluns/secureconfig/main/<guide>.md

The machine-readable index is at /llms.txt, and every guide concatenated into a single file is at /llms-full.txt. If raw.githubusercontent.com is unreachable, use llms-full.txt: each file in it starts with a line such as ==> nginx.md.

Install

Install in Claude Code

This repository is a Claude Code plugin marketplace: .claude-plugin/marketplace.json (opens in a new tab) lists 1 plugin, secureconfig, whose source is the plugin folder (opens in a new tab) (plugin marketplaces (opens in a new tab)). The plugin has no Claude Code manifest of its own, so Claude Code loads its standard layout, the secure-deployment-config (opens in a new tab) skill, and takes the name from the marketplace entry (plugin manifest (opens in a new tab)).

In a Claude Code session, add the marketplace and install the plugin (installing plugins (opens in a new tab)):

In a session

/plugin marketplace add jposluns/secureconfig
/plugin install secureconfig@secureconfig

The same from a shell:

In a shell

claude plugin marketplace add jposluns/secureconfig
claude plugin install secureconfig@secureconfig

Without a marketplace, copy the skill's folder, plugin/skills/secure-deployment-config (opens in a new tab), to ~/.claude/skills/secure-deployment-config/ for all your projects or to .claude/skills/secure-deployment-config/ in one project (skills (opens in a new tab)), and refresh it by copying it again.

A skill loads when its description matches the task. To have the rules loaded with your project instructions, paste plugin/always-on.md (opens in a new tab), the skill's rules for every deployment and 1 line pointing at the skill, into your project's CLAUDE.md, which Claude Code reads as project instructions at the start of a session; the memory (opens in a new tab) page lists the settings that change which files load. If your project keeps its assistant instructions in AGENTS.md, you can keep the snippet there and import that file from a CLAUDE.md beside it with an @AGENTS.md line (share one file with other coding tools (opens in a new tab)). Claude Code can also read AGENTS.md directly, when there is no CLAUDE.md or CLAUDE.local.md in the working directory or above it, in supported sessions; the AGENTS.md section (opens in a new tab) of the memory page gives the versions, settings and sessions in which it does.