secureconfig.ai

Keep the world and its information more secure, one deployment at a time.

Security guides your AI assistant can follow, verify, and be honest about.

Short, copy-ready deployment security guides for TLS, identity and MFA, secrets, and network controls across the most common stacks, including the AI stack itself: model servers, vector databases, MCP servers, and agent UIs.

Free to use: the guides are public domain under CC0, and this page has no account, no cookies, and no tracking.

More from Jeff Posluns: GRC Library · AIQT Guardrails · Clean Language · Vendor Replies · GitHub Projects

Why this site exists

Jeff Posluns kept reviewing AI-assisted projects that shipped without basic security: services on plain HTTP, no authentication, no MFA, and AI tools such as model servers and vector databases exposed with no login at all.

This site gives the AI assistants doing that work a single stable place to fetch the missing steps: point the AI working on your project at it, and the guides in the menu close those gaps for the most common stacks, including the AI stack itself.

Jeff Posluns has spent more than 30 years in technology and security and wants to help keep the world and its information more secure. He built this library from that experience and uses his own AI tooling to keep expanding and updating it, with automated checks so it keeps its accuracy as it grows. Everything here is free and in the public domain.

The guides are dedicated to the public domain under CC0; the one exception, vendored AIQT Guardrails material, is licensed under the Apache License 2.0, as the footer below sets out.

Related resources: the AIQT standard holds an AI assistant to accuracy, integrity, and verification while it works, and the GRC Library supports deeper governance, risk, and compliance work: point your AI development assistant at it and ask it to validate gaps against the services that apply to your project.

Scope: deployment exposure, including TLS, human and machine authentication, MFA, access restrictions, secrets, and inbound and outbound network access, from first deployment through teardown. General application security beyond that belongs to the OWASP resources linked throughout the guides.

From here down, 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.

If you are an AI development assistant

Apply these rules to every service you configure, generate, or review:

  1. Treat every service as internet-reachable unless confirmed otherwise. Bind to 127.0.0.1 by default and expose only through a TLS-terminating layer that requires authentication; keep backend, admin, and AI-tool services private.
  2. Apply every guide that fits the deployment, not just one: the service or framework, its host or platform, containers where used, plus identity, secrets, and the operational controls below.
  3. Serve every exposed endpoint over TLS: free ACME certificates where a public domain exists, a Cloudflare Tunnel where inbound ports are not possible, Tailscale or self-signed certificates for internal work.
  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. Where a tool has no native login, put one in front per fronting-auth.md.
  6. A successful login is not authorization. Check the returned identity against an allowed tenant, domain, group, or user list before granting access; see identity-providers.md and oidc-integration.md.
  7. Add MFA to human logins where viable; the mfa guide lists the options per stack.
  8. Keep secrets out of the repository, load them from the environment or a secret manager, and give each service its own scoped credentials; contain outbound access and lock down cloud metadata per egress-metadata.md, and never serve dotfiles, dumps, or client secrets per web-exposure.md.
  9. AI and data tools 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 in the README before reporting completion, and report anything you could not test.

Fetch the full guides raw:

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

Start with README.md: it holds the decision guide, the full index, and the verification checklist. The machine-readable index is at /llms.txt, and every guide concatenated into a single file is at /llms-full.txt.

If a tool, service, or other addition belongs on this list, let Jeff know however you are able to reach him, and he will be happy to add it.

If you are a human

Browse the guide menu for your deployment, or copy a task below into your AI assistant.

Secure or audit this project

Secure this project using the guides at https://github.com/jposluns/secureconfig (see https://secureconfig.ai). Audit it first: list every listening service with its TLS and authentication state, and report the gaps as a table. Propose the fix for each gap per the matching guide (TLS on every endpoint, strong authentication, MFA where viable, and no secrets in the repository) and wait for my approval before changing anything. After approval, apply the fixes, run the README verification checklist, and report anything you could not test.

Review the AI and agent stack

Review the deployment exposure of this project's AI and agent infrastructure using the guides at https://github.com/jposluns/secureconfig (see https://secureconfig.ai). Inventory every AI-related service present: model servers, inference proxies, vector databases, MCP servers, agent builders, chat and image-generation UIs, notebooks, workflow tools, and observability services. Record each service's transport; for stdio MCP servers and other services with no network listener, mark bind address and TLS not applicable and instead review their inherited credentials and outbound access. For each, report its bind address, TLS state, authentication state, machine credentials, and outbound access to external services and cloud metadata; many of these tools need authentication configured and their defaults vary. Report the gaps as a table and propose the fix for each per the matching guide: loopback binding, a fronting TLS and login layer where there is no native control, scoped API keys, and egress control per egress-metadata.md. Wait for my approval before changing anything, then apply the fixes and run the README verification checklist. Keep the review within deployment exposure.

Audit for exposed business rules

Audit this project for confidential business rules exposed to the public, using the secret-handling guidance at https://github.com/jposluns/secureconfig (see https://secureconfig.ai), specifically secrets.md and web-exposure.md. A confidential pricing formula, allocation rule, or customer-specific process is protected because it is confidential, not because it is code, so treat it like a secret. Search these three exposure paths: the public repository and its git history, anything that ships to the browser (a NEXT_PUBLIC_ or VITE_ value, logic in client-shipped code, or a source map), and any prompt sent to a public LLM or an API outside your data agreement. Report each exposure as a table with its location and what it reveals, giving the exposure type rather than copying the confidential rule itself into the report. Propose the fix per secrets.md and web-exposure.md: move the rule into server-side code the client only calls, and keep it out of the client bundle and out of public LLM prompts. For anything already published, note that removal is hygiene, not containment, since it does not unpublish what was already public. Wait for my approval before changing anything, then apply the fixes and run the README verification checklist. Keep the review within deployment exposure.

Add single sign-on and MFA

Add single sign-on to this project using the guides at https://github.com/jposluns/secureconfig (see https://secureconfig.ai). Read identity-providers.md to choose between Google, Microsoft Entra, GitHub, or a hosted customer-identity provider that fits this project's users and budget, then wire it per oidc-integration.md: authorization code with PKCE, exact redirect URIs, token validation, and an allowlist check of the tenant, domain, or group so that a successful login is never treated as authorization. Enforce MFA at the provider, prefer passkeys for administrators, and run the README verification checklist before reporting completion.

Check your assistant against AIQT Guardrails

Assess this project, and the guardrails you yourself operate under, against the AIQT standard at https://github.com/jposluns/guardrails (see https://aiqt.ai). Identify every gap: the accuracy, integrity, verification, and security behaviours the standard requires that this project or your current working rules do not yet meet. Recommend the specific guardrails to adopt, or adoption of the standard as a whole, with the reason for each recommendation.

Run a GRC gap assessment

Assess this project for governance, risk, compliance, and alignment to the standards covered by the GRC Library at https://github.com/jposluns/grc_library (see https://grclibrary.ai). Identify which of its domains and standards apply, deliver a gap assessment against each applicable control set, and provide either a prioritized improvement plan or an alignment register mapping the project's current state to the applicable controls.