Every agent you connect needs its own credential. Nobody's inventory keeps up

Every new AI agent you connect to a service needs a way to authenticate to that service. Multiply that by how many tools a typical team is now wiring an agent into — a CRM, a code host, a data warehouse, an email platform, a Slack workspace, an internal API or two — and the number of live credentials in play grows fast, usually faster than anyone’s actually tracking it.

GitGuardian’s 2026 State of Secrets Sprawl report put a number on how bad that’s gotten just on public GitHub: 29 million hardcoded secrets exposed in 2025, a 34% year-over-year increase and the largest single-year jump the company has recorded since it started publishing the report in 2021. The part specific to this year’s agent boom is sharper — leaks tied to AI services surged 81%, and GitGuardian found more than 24,000 unique secrets sitting in MCP-related configuration files alone, over 2,100 of them verified as live, working credentials sitting in public repositories. That’s not a hypothetical risk. That’s thousands of real keys, to real services, found by scanning what people accidentally committed.

Why agents specifically make this worse, not just bigger

A human juggling a handful of API keys can, with discipline, keep a mental model of what each one is for. An agent-heavy setup breaks that model in a specific way: every new integration is its own credential, agents get wired up faster than humans historically provisioned service accounts, and the config files agents read from — .env files, MCP server configs, CI pipeline definitions — are exactly the kind of file that’s easy to accidentally commit, paste into a chat, or leave in a shared workspace. Machine identities already outnumber human ones by a wide margin at most organizations, and that ratio is climbing without a matching increase in who’s actually governing them.

The MCP-specific number in the GitGuardian report is the clearest signal of this: a protocol designed to make it easy to connect an agent to a tool also made it easy to leave the credential that connection depends on sitting in a plaintext config file, because that’s often the fastest way to get an agent working during a proof of concept — and the fastest path has a way of quietly becoming the permanent one.

A worked example: how one credential outlives its purpose

Picture a team wiring an agent into a project-management tool for a weekend prototype. Someone grabs an API token, drops it into a .env file so the demo works before Monday’s stand-up, and the prototype gets a good reception. Nobody circles back to mint a scoped key for the “real” version — the .env file just gets copied into the production config, because it already works and there’s a deadline. Six months later that same token still has whatever broad scope it was granted on day one, it’s never been rotated because nothing ever prompted anyone to, and it’s sitting in a config file that’s synced to more machines and more people’s laptops than anyone individually tracks. Nothing about this required carelessness — every individual step was the fastest way to get unblocked. That’s exactly why “we’ll be careful” doesn’t hold up as a strategy: the sprawl isn’t caused by one bad decision, it’s the compounding effect of a dozen locally-reasonable ones, none of which anyone thought to revisit.

	Human-era service accounts	Agent-era credentials
Who provisions a new one	An engineer, usually through a ticket or review	Whoever wires up the next integration, often in minutes
Typical count per person	A handful of long-lived service accounts	One per agent, per tool, per project — and climbing
Where it tends to live	A secrets manager, mostly	Config files, .env files, MCP configs, sometimes chat history
Rotation cadence	Scheduled, if imperfectly enforced	Ad hoc, usually only after something breaks

What actually reduces the sprawl

None of the fixes here are exotic. They’re the same identity hygiene practices that applied to service accounts before agents existed — they just matter more now because the number of credentials in play is growing faster than most teams’ processes for managing them.

A dedicated key per integration, never a reused one. The instinct to grab whatever key is already sitting in a password manager and paste it into a new agent’s config is exactly how one leaked credential turns into “every integration this person ever set up” instead of “one integration.” A key created specifically for one agent, one purpose, is a key you can revoke without taking anything else down — and one whose scope you can actually reason about six months later.

Rotation on a schedule, not a hunch. “I’ll rotate it if something looks wrong” assumes you’ll notice something looks wrong, which the 2,100+ verified-live secrets GitGuardian found in public repos suggests doesn’t happen reliably. A default lifespan for any headless or agent-facing key — ninety days is a reasonable baseline — means a credential that leaks quietly still ages out on its own, rather than staying valid indefinitely because nobody had a reason to look at it.

An actual inventory: which agent holds which credential, to what. This is the piece most teams skip entirely, and it’s the one that turns “we think we’re fine” into something you can actually verify. A spreadsheet is enough to start — one row per credential, what it’s scoped to, which agent or service holds it, when it was created, when it’s due to rotate. The value isn’t the format, it’s that the question “if we had to revoke everything this specific agent can touch right now, could we find it in under five minutes” has a real answer instead of a guess.

Credential sprawl FAQ

How often should an agent-facing credential actually be rotated?+

Ninety days is a reasonable default for anything headless or agent-facing, tighter for a credential with write access to anything financial or customer-facing. The exact number matters less than having a default at all — a credential with no expiry is a credential nobody ever revisits until something forces the question.

Is a spreadsheet really enough for a credential inventory?+

For most teams, yes, at least to start. The format doesn't matter — what matters is that one row exists per credential, with what it's scoped to, who or what holds it, and when it's due to rotate, so the question 'what can this agent reach right now' has a real answer instead of a guess assembled under pressure during an incident.

What's the single highest-leverage fix if we can only do one thing this quarter?+

Stop reusing credentials across integrations. A dedicated key per agent, per tool, costs almost nothing to set up and means a single leak is contained to one integration instead of everything that credential ever touched. Rotation and inventory both matter, but a reused credential undermines both of them at once.

Where this gets Norbelys-specific

The mechanics of scoping and storing the actual credential Norbelys issues — what an org-scoped ak_ key grants, OAuth vs. API-key tradeoffs, where to store either safely — are covered in more depth in scoping the API key you hand an AI agent and authenticating server-to-server with the Norbelys API. Both of those posts assume you’ve already decided to mint a dedicated key for a given integration — this post is about the layer above that decision: having a system, across every tool you connect an agent to, for making sure that decision actually happens every time, and that the resulting credential doesn’t outlive its usefulness or its owner’s memory of it. The GitGuardian numbers are a reminder that “we’ll be careful” isn’t a system — an inventory and a rotation schedule are.