An MCP server that reads a database, calls a paid API, or writes to a business system needs credentials somewhere, and the single most common mistake we see in early MCP builds, including some of our own early ones, is a secret hardcoded into the server file itself or committed to the repo in a .env file that was never added to .gitignore. This is the specific, practical checklist for doing it properly.
Where secrets actually belong
This matters more for MCP servers specifically than for a lot of other software, because an MCP server is often built quickly by whoever needed the integration that week, sometimes without the same review process a core product change would go through, which is exactly the gap where a hardcoded credential slips in unnoticed and sits there for months.
The baseline that should be non-negotiable for any MCP server touching real business data is that credentials live outside the codebase entirely, in environment variables sourced from a secrets manager or, at minimum, a .env file that's genuinely excluded from version control and never pasted into a chat log, an issue tracker, or a support ticket while debugging a connection problem.
Environment variables loaded at process start, never hardcoded string literals in the server file
A dedicated secrets manager for anything beyond a single-developer prototype, not just a local .env file
Separate credentials per environment, dev, staging, production, never one shared key reused everywhere
Rotation on a defined schedule, not only after a suspected leak
The mistake that actually causes incidents
Hardcoded secrets rarely cause the incident directly; what causes it is that hardcoded secret then getting pasted into a debugging session, a Slack message, or an AI chat asking for help fixing a connection error, at which point the secret has left the codebase entirely and into a channel with far weaker access controls and audit logging than the git repo it came from. The practical fix is a standing team habit: redact or regenerate any credential before it's ever pasted anywhere for debugging, treating that as automatic rather than a judgement call made under time pressure.
A Canberra govtech contractor discovered during a routine security review that a Notion API key had been pasted into three separate support tickets over the preceding six months while engineers debugged connection issues, none of which had triggered any alert, because the key itself hadn't technically been committed to the repo. Rotating the key and moving to a proper secrets manager with access logging closed the gap, and the security lead estimated the incident review and remediation cost around $9,000 in consultant and engineering time, against what would have been a near-zero-cost habit change if caught earlier.
A note on shared team credentials
A single shared API key used by every developer on a team makes it impossible to tell, after the fact, which specific integration or person's script actually caused an unexpected spike in API usage or a malformed write. Per-developer or per-service credentials, even where the underlying permissions are identical, keep that audit trail intact and turn a debugging session from a guessing game into a five-minute log lookup.
Scoping credentials to the minimum the server actually needs
A credential with full account access, when the MCP server only ever needs read access to one table, is a bigger blast radius than necessary if that credential does leak. Most APIs support scoped API keys or service accounts with narrower permissions; taking the extra ten minutes to scope a credential correctly at creation time is meaningfully cheaper than dealing with the consequences of an over-permissioned one leaking later.
Auditing what's already out there before you start
Before building any new secrets-management discipline, it's worth running a genuine audit of every existing MCP server and integration script already in production, because most businesses find at least one credential that's been hardcoded or over-permissioned for months without anyone noticing, simply because nobody had looked. A grep across the codebase for common API key patterns, plus a manual review of every .env file actually in git history, not just the current working tree, catches problems a cursory glance misses.
What this isn't
This is a practical operational checklist, not a full security architecture review; larger organisations with formal security requirements around APRA or government data handling need a more thorough process than what's covered here, this is the baseline every MCP server should clear regardless of size.
Automata AI audits secrets handling across existing MCP server builds for Australian businesses, and builds new servers with this baseline from day one. Get in touch via /contact if you're not confident your current setup would pass this checklist, we run the audit quietly and report back findings before anything gets rotated or changed.
