Every program, every integration, and every AI agent running inside a company carries at least one credential with it: a key that opens the door to some system. According to the State of Secrets Sprawl 2026 report, from security firm GitGuardian and published in March 2026, 28.65 million new credentials were found exposed in public code throughout 2025 — a 34% jump over the previous year and the largest single-year increase the firm has ever recorded.
A meaningful slice of that growth is tied directly to AI: credentials linked to AI services alone totaled 1,275,105 in the same study, up 81% in a single year. Every new agent put into production is, in most cases, one more credential circulating through the company — and few of them have a clear owner, an expiration date, or access limited to the task they were meant to perform.
OWASP, the international foundation that sets reference standards for software security, formalized this picture in 2025 with a list of the ten most common risks in identities used by programs and agents, not by people. Among them: excessive privilege, credentials with no expiration date, and incomplete offboarding when a project ends. For anyone deciding to put agents into production, one simple question rarely gets asked: what exactly does this agent's key open — and for how long?
More keys than any team can count
No company decides, in one move, to accumulate thousands of system credentials. They pile up gradually: one integration here, one agent there, each granted access to a system to solve a specific task. The problem is that the credential is rarely revisited afterward — it just stays active, long after the original task has changed or ended.
GitGuardian's own report measured that habit directly: 64% of the credentials confirmed valid in 2022 were still active and exploitable in January 2026. Four years later, most of them had never been rotated or revoked — just forgotten somewhere in the system.
OWASP's list names exactly this pattern. One of the ten risks, overprivileged non-human identity, describes credentials used by programs and agents with far more access than their function requires. Another, long-lived secrets, describes keys and certificates with no set expiration. A third, improper offboarding, describes what happens when nobody revokes access once a project ends.
Verizon's 2026 Data Breach Investigations Report shows why this matters in practice. Credential abuse fell to 13% as an initial access vector — down from 22% the year before — but when counted at any point in the attack, not just the first step, it still tops the list, present in 39% of the breaches analyzed. The report itself cites improper credential rotation and missing least-privilege controls on system and service accounts among the most common root causes in breaches involving third parties.
At Brazilian and Latin American companies now putting AI agents to work on customer service, record updates, or financial systems, the pattern repeats: the integration goes live quickly, someone reuses an existing credential or creates one with broad access "so it doesn't break later," and nobody comes back to narrow that access once the routine settles in.
Why the master key looks like the fastest path
When an agent needs to connect to a payment system, a spreadsheet, or a support system, the fastest route is to hand it a broad-access credential — the same one a person would use to do anything in that system. Setting up restricted access to just two or three functions, inside a tool that has dozens, feels like too much work for an automation that "only does one thing."
The problem shows up once that agent makes a mistake, gets manipulated, or is simply used beyond what was planned. Because it inherited the reach of a general-purpose credential, the action it takes carries all of that power — even when the original task called for far less. And in the system's log, what gets recorded is the generic name of the account or the agent, not the person or process that should be accountable for it.
That combination is exactly what OWASP catalogs as misuse of non-human identity: someone reuses a broad credential because setting up a narrow one feels like bureaucracy, and the risk only surfaces months later, in an investigation where nobody can say with certainty who authorized what.
What has to be in place
Fixing this isn't about trusting the agent more or less. It's about architecture: every credential needs to be born narrow, have an owner, and carry a deadline.
A personal credential for every connected tool. Every integration used by an agent or a person has its own access key — never a generic credential passed around between different automations or people.
Access granted function by function, even inside the same tool. If a connected system has thirty functions and the agent only needs two to do its job, only those two get unlocked — not the whole tool.
A review deadline for every credential, no exceptions. No key stays active indefinitely just because nobody remembered to reassess it; periodic review is part of how the system runs, not extra work someone has to remember.
Human approval before any sensitive action. Before an agent carries out something with real impact — moving money, changing a critical record, publishing a document — the action pauses and asks a person to confirm, right inside the conversation.
An audit trail that ties the action back to who originated it. Every use of a credential is logged in a way that points to the responsible person or process, not just the generic name of the agent.
This is how Skyller was designed: every connected tool gets its own credential, access is granted function by function, and sensitive actions wait for human confirmation before they happen.
What changes when every key has an owner
The first gain shows up when something unusual needs investigating. With a narrow, personal credential per tool, figuring out what a specific agent could have done stops being guesswork and becomes a direct lookup — because that key's reach was limited from the start.
The second gain shows up when a project ends or a tool gets replaced. Retiring that one credential doesn't require tracing everyone else who might depend on it, because it was never shared with anything beyond the task it was created for.
The third matters most as the company grows: adding agent number fifty stops being riskier than adding agent number five, because each one carries only the access its own function requires — not whatever was left over from a borrowed credential. At Skyller, reviewing what a specific tool authorizes, and revoking it without touching anything else, is a settings screen, not an investigation.
A checklist for reviewing the keys already in use
Before connecting the next agent to a new system, it's worth sitting down with IT and answering these questions about what's already running:
- List the credentials your AI agents already use today. Including the informal ones, created by someone solving a one-off task that's still running months later.
- For each one, ask what it opens — not just which system. Systems tend to have dozens of functions; few credentials genuinely need all of them.
- Find out how long it's been since each credential was rotated. A key with no review date is, in practice, a key with no owner.
- Define who approves what before the agent acts. Not every action needs manual confirmation, but anything involving money, sensitive data, or external communication does.
- Confirm the log points to a person, not just the agent's name. Without that, the next investigation will hit the same vague answer: "someone on the team, not sure who."
