Let me paint you a picture.
You join a company. You ask how secrets are managed. Someone looks at their shoes. Eventually you find a .env file in a shared Google Drive folder. It has been there for three years. Nobody knows who created it. It has the production database password in it. Thirteen people have access to the folder.
This is not a horror story. This is Tuesday.
The gap nobody is filling
Secrets management has two tiers and nothing in between.
Tier 1 — Enterprise: CyberArk, HashiCorp Vault (now IBM), AWS Secrets Manager. Powerful, battle-tested, and either eye-wateringly expensive or requiring a dedicated platform team to operate. CyberArk enterprise licences start at six figures. Vault OSS is free but running it reliably in production is a full-time job.
Tier 2 — Nothing: Most teams under 200 people. They use .env files, CI/CD secret stores with no audit trail, or shared password managers never designed for machine-to-machine secrets.
And here is the real problem: most organisations accumulate secrets sprawl over time. Applications that talk directly to CyberArk. Others that hit Vault. A handful pulling from AWS SSM. Each with its own credential logic, its own rotation story, and no centralised visibility. When a safe is renamed, a token expires, or a key leaks — you find out by watching something break in production.
That is what I built Aegis to fix.
What Aegis is
Aegis is a vendor-agnostic secrets broker and PAM gateway. It sits as the only secrets endpoint your applications ever need to know about — regardless of whether those secrets live in CyberArk, HashiCorp Vault, AWS Secrets Manager, or Conjur.
Applications authenticate with a scoped API key (one key per team-registry pair) and receive exactly the secrets they are authorised to see. Every fetch, every rotation, every configuration change is written to an immutable audit log with full attribution. There is no way to touch a secret without leaving a trace.
Your Application Aegis Upstream Vault
│ │ │
│ GET /secrets │ │
│ X-API-Key: sk_... │ │
│ X-Change-Number: CHG123 │ │
├───────────────────────────►│ │
│ │ 1. Hash key → lookup │
│ │ team + registry │
│ │ │
│ │ 2. Enforce policy: │
│ │ change number, IP, │
│ │ time window, rate │
│ │ │
│ │ 3. Fetch from upstream │
│ ├───────────────────────────►│
│ │◄───────────────────────────┤
│ │ │
│ │ 4. Write audit log │
│ │ 5. Emit SIEM event │
│ │ │
│ { secret_name: value } │ │
│◄───────────────────────────│ │
What it handles
Scoped API keys per team
Each team gets one API key per registry they are assigned to. Team A and Team B can both access the same registry with different keys. If one key is compromised, only that assignment needs rotating — the other team is unaffected. Keys are stored as SHA-256 hashes. The plaintext is never persisted.
Vendor-agnostic secret fetching
Aegis resolves the upstream vendor at fetch time based on the object definition. You can migrate a secret from CyberArk to HashiCorp Vault without touching application code — just update the object definition in Aegis. Supported backends: CyberArk (CCP + PVWA), HashiCorp Vault (KV v1/v2), AWS Secrets Manager / SSM, Conjur (OSS + Enterprise).
Policy enforcement
Policies are defined per team, per registry, or per team-registry pair. Enforceable controls include:
- IP allowlist — only specific CIDRs can request secrets
- Time windows — a batch job that runs at 2am can only fetch secrets at 2am
- Change number enforcement — every request must carry a valid ITSM change reference
- Rate limiting — per-team RPM cap backed by Redis, prevents runaway services hammering upstream vaults
- Key expiry — maximum key lifetime configurable per policy
Immutable audit logging
Every access is written to audit_log with: timestamp, team identity, registry, objects fetched, source IP, user agent, change number, and outcome. Every admin action is written to change_log with structured before/after diffs. There is no off switch. For regulated environments — financial services, healthcare, public sector — this is the difference between passing and failing a security audit.
SIEM integration
Audit events are emitted as structured JSON to whichever destination you point it at: stdout, Splunk HEC, AWS S3 (gzip JSONL), or Datadog. Configurable at runtime, no code changes needed.
Team self-service model
This is the part I am most pleased with. The security team manages policy — not operations. Teams manage their own:
- Webhook subscriptions (Slack, MS Teams, Discord, or any HTTP endpoint)
- CI/CD rotation triggers via auto-generated inbound webhook URLs
- Notification channels
- Key rotation
No tickets. No waiting. The security team retains full visibility through the audit log and can override anything — they just do not need to be involved in day-to-day operations.
Designed for scale
Built to handle 100+ teams and 40,000+ secrets under a single security team. The data model is relational and explicit — teams, registries, objects, and the many-to-many assignments between them are all first-class entities with their own audit trails.
The stack
- FastAPI (Python 3.12) — async, fast, automatic OpenAPI docs
- PostgreSQL + SQLAlchemy + Alembic — relational, properly migrated, nothing exotic
- Redis — rate limiting and session tokens
- Docker + GHCR — single container, published to GitHub Container Registry on every tagged release
- Terraform — AWS infrastructure modules included
- GitHub Actions — CI with Bandit static analysis, Trivy CVE scanning on every release. Releases block on CRITICAL/HIGH CVEs.
Get started in five minutes
git clone https://github.com/gustav0thethird/Aegis
cd Aegis
cp config/auth.json.example config/auth.json
docker compose up
Alembic runs migrations on startup. The API is live at http://localhost:8080. Full API reference and configuration docs are in the README.
Why AGPLv3
I chose AGPLv3 deliberately. If you are a team in a regulated environment you need to be able to audit what touches your secrets. With a proprietary tool you are trusting a vendor. With Aegis you can read every line of code that handles your credentials.
AGPLv3 means: use it freely, modify it freely, self-host it freely. If you run it as a network service and make modifications, you share them back. This is the right licence for security tooling.
Who this is for
- Platform teams at 20–500 person companies who need proper secrets governance without enterprise PAM pricing
- Regulated industries where audit trails are mandatory — financial services, healthcare, public sector
- Teams already running Vault or CyberArk who want a controlled, auditable access layer in front of their vault rather than every service talking to it directly
- Anyone drowning in secrets sprawl across multiple vendors with no central visibility
Come help build it
Aegis is early-stage and actively developed. The core is stable and the architecture is solid — now it needs people who actually run secrets infrastructure at scale to push it further.
What is being worked on:
- Web UI for policy management
- LDAP / SSO integration
- Kubernetes secrets injection
- Additional vault backends
If you work in security engineering, platform engineering, or regulated infrastructure — your experience is exactly what shapes what gets built next. Open an issue, start a discussion, or send a PR.
Star it on GitHub if it looks useful — it genuinely helps with visibility and lets me know people care about this existing.
Top comments (0)