One Key, Many Machines: Keeping the Aggregator Key Out of Git, Shell History and Frontend Bundles

Why a Single Key Deserves Serious Care

On a no-login, no-KYC aggregator, your API key is the only credential that ties usage and billing to you. Unlike platforms with per-user accounts, there is no password reset or identity check to fall back on. If the key leaks, anyone can spend your balance until you notice and rotate. Treat it like a credit card number that never expires on its own.

Common Leak Vectors (and How to Plug Them)

Version Control (Git)

• Never commit .env files. Add .env, .env.*, and any local config files to .gitignore before the first commit.
• Use .env.example with placeholder values to document required variables.
• Scan for accidental commits with tools like git-secrets or trufflehog. If a key is ever committed, rotate it immediately—removing it from history is not enough because copies may exist.

Shell History

• Commands containing API keys—like export AGGREGATORKEY=sk-... or curl -H "Authorization: Bearer sk-..."—are saved in .bashhistory or .zsh_history.
• Prefix sensitive commands with a space if your shell supports HISTCONTROL=ignorespace or equivalent.
• Avoid typing keys directly; load them from a secure file or a secret manager.
• Periodically clear history or use a dedicated shell for sensitive work.

Frontend Bundles

• Client-side code (JavaScript in browsers) is fully visible to anyone. Never embed an aggregator key in a frontend bundle.
• Instead, proxy requests through your backend. The backend holds the key and forwards calls to the aggregator.
• If you must call from a browser, use a short-lived token service—but note that this aggregator does not issue per-user tokens, so a backend proxy is the only safe pattern.

CI/CD and Secrets Management

• Store keys as masked secrets in your CI platform (e.g., GitHub Actions secrets, GitLab CI variables).
• Avoid echoing secrets in logs; use ::add-mask:: or equivalent.
• Restrict secret access to necessary branches and environments.
• Rotate CI secrets whenever team membership changes or a leak is suspected.

The Rotation Habit

Without per-user logins, rotation is your primary defense. Make it routine:

• Schedule rotations—for example, every 90 days—even without evidence of compromise.
• Rotate immediately after any suspected exposure: a committed file, a screenshot, a shared terminal session.
• Keep a rotation log with dates and reasons (internal note, not in the repo).
• Automate where possible: use a script that generates a new key via the aggregator dashboard, updates your secret store, and revokes the old key.

Verify Your Defenses

• Run a secret scanner in pre-commit hooks and CI.
• Audit your shell history for accidental key exposure.
• Check that frontend bundles contain no sk- strings (search built assets).
• Review CI logs for accidental prints of environment variables.

What to Do If a Key Leaks

1. Revoke the key immediately in the aggregator dashboard.
2. Generate a new key and update all legitimate uses.
3. Review usage logs for unauthorized calls (the aggregator provides usage data).
4. If you are a contributor earning credit, check that your balance is intact.
5. Document the incident and adjust your process.

Remember: you pay official price × 1.3 for usage, and contributors receive official price × 1.1 (or × 1.2 for premium models) as credit. A leaked key can burn through your USDC balance quickly, so proactive key hygiene is essential.