EnvSentinel – contract-driven .env validation, zero dependencies
Solves a real CI/CD pain, but dotenv validation already exists (python-dotenv, pydantic).
Deterministic, CI-safe API key resolution with optional runtime validation (stdlib-only)
Deterministic fallback order (ENV → .env → vault) plus an opt-in validation mode and a strict CI-friendly option is a practical combo I wish I'd had in several projects. The doctor CLI that lists found keys and minimal provider probes (e.g., GET /v1/models for OpenAI) is a nice touch — useful for catching bad tokens before a pipeline runs. It’s not reinventing secret managers, but the zero-deps, stdlib-only approach and CI strictness make it an immediately usable tool for small teams.
Backend developers, AI/ML engineers, DevOps/CI engineers who manage API keys in development and CI environments
Resolves from ENV → .env → vault, with optional runtime validation probes. No deps beyond Python stdlib.
Example:
from api_pilot import resolve_key client = OpenAI(api_key=resolve_key("openai", validate=True))
CLI doctor command:
$ api-pilot-doctor .env file found OPENAI_API_KEY found in environment
Modes: • Default: ENV → .env → vault • Validation: optional runtime API probes • Strict: fails if .env used (CI safety)
MCP integration ready.
Feedback welcome!
Solves a real CI/CD pain, but dotenv validation already exists (python-dotenv, pydantic).
Yet another .env validator when dotenv-linter and git-secrets already exist.
Touch ID for ENV secrets is clever, but dotenvx and 1Password CLI already solve this.
Deterministic parser separates LLM fuzziness from reproducible Python runtime.
Resumable agent workflows with JSON schema validation beats raw Codex scripting.
IFC + capabilities block prompt injection at execution sinks, not input filters—40yr research applied.