Your AI Agents Are Sharing Human Credentials. Here’s How to Audit the Risk.
69% of enterprises let AI agents share credentials. NHIs outnumber humans 144:1. Here's a five-part audit framework to find and fix credential sharing before it finds you.

Table of Contents
Your AI Agents Are Sharing Human Credentials. Here's How to Audit the Risk.
TL;DR: VentureBeat's June 2026 Pulse Research found that 69% of enterprises let AI agents share credentials. Only 32% give each agent its own identity. NHIs outnumber human identities 144 to 1; only 15% of security teams feel confident about their NHI security. This guide walks through a five-part audit framework to find and fix credential sharing before it finds you.
Table of Contents
1. The numbers you need to know
2. Why human credentials are the wrong tool for agents
3. The five-part audit framework
4. What the vendors say (and what they're not saying)
5. Running your own audit: the practical checklist
1. The numbers you need to know
69% of enterprises have credential sharing somewhere in their AI agent stack, per VentureBeat Pulse Research (June 2026, n=107). Only 32% assign every agent its own scoped identity. If you read nothing else in this guide, sit with those two numbers: 69% sharing, 32% doing it properly.
The Cloud Security Alliance's State of Non-Human Identity Security report found NHIs outnumber human identities 144 to 1. Only 15% of organisations are confident in their NHI security posture. When your agent fleet grows faster than your ability to identify what each agent can touch, you're accumulating risk you can't see.
GitGuardian's State of Secrets Sprawl 2026: 28.65 million secrets detected. AI-generated commits leak secrets at 3.2%, double the 1.5% human baseline. Agents are shipping code that leaks credentials, and those credentials are often human ones with broad access.
Gravitee's State of AI Agent Security 2026: 88% of organisations have already experienced at least one AI agent-related security incident.
The numbers point the same direction. Most organisations are running agents with identity practices that would get a junior developer disciplined, and a majority have already been burned.
2. Why human credentials are the wrong tool for agents
I've watched this pattern repeat across half a dozen conversations with teams building agent fleets. Someone wants to ship fast, so they grab an API key from a colleague, or reuse their own OAuth token, or copy a service account key that "seems about right." The agent ships. It works. Nobody thinks about it again.
Then something happens. The agent gets compromised through a prompt injection. Its code leaks to a public repo. And the credential it's running on isn't a narrow, time-limited token. It's Dave's GitHub PAT with org-wide read access. Or an AWS key with `s3:*` because scoping it properly took ten extra minutes.
Human credentials assume the bearer notices when something is wrong, has a line manager, goes through structured onboarding and offboarding. Agents don't fit this model. They don't get fired. They don't rotate their own keys. They don't question whether they really need production database access to summarise a support ticket.
When an agent uses a human credential, two things break.
First, you lose attribution. The audit log says "Dave created 47 resources." Was that Dave, or the support agent Dave gave his token to three months ago? You will never know. Incident response starts with a guessing game.
Second, you lose surgical revocability. If that agent gets compromised, you have to revoke Dave's credentials. Dave now can't do his job. Every service that depended on that key breaks. What should be narrow containment becomes organisation-wide disruption.
3. The five-part audit framework
This framework catches the practices most likely to hurt you and gives you structure for the audit you probably haven't run yet.
3.1 Identity Separation: One agent, one identity
Every AI agent gets its own dedicated identity. Not Dave's key. Not a shared service account. One identity per agent.
The test: if you look at an audit log entry, can you trace it to a specific, named agent? If no, you failed.
This applies everywhere. Dev agents, staging agents, production agents, the script someone wrote to summarise Slack on a Friday afternoon. If it acts autonomously, it gets its own identity. No exceptions.
3.2 Least Privilege: Minimum viable permissions
Once each agent has its own identity, decide what it can actually do. The answer should make you slightly uncomfortable.
A customer-support agent that reads tickets and drafts responses doesn't need write access beyond the drafts queue. It doesn't need HR records, billing data, or the CEO's calendar. If a permission wouldn't survive a compliance review, it shouldn't be in scope.
Microsoft's "Least Privilege for AI Agents" pattern document (16 July 2026) outlines this: agents should use scoped OAuth tokens rather than broad API keys. A token that can only read from `/tickets` and post to `/drafts` beats a key that grants `read:everything`.
Most teams skip this step because the agent "just needs to work." That shortcut produces the incidents in the Gravitee data.
3.3 Scoped Service Accounts: Time-limited, resource-scoped, auditable
Where agents need service accounts, they should be three things: time-limited (credentials expire), resource-scoped (an agent managing DNS accesses DNS, not the cloud account), and auditable by identity (every log entry maps to a specific service account and owner).
Teams push back on time limits: "what if the agent stops working?" That is the point. If an agent is still valuable after 90 days, someone should actively renew its credentials. If nobody remembers it exists, you want it to stop.
3.4 Secret Handling: Never in code, rotate automatically
GitGuardian's 28.65 million secrets say this bears repeating. Secrets don't go in code, `.env` files that get committed, README examples, or agent system prompts someone might paste into a forum.
Use a secrets manager. Rotate automatically. The interval should be shorter than the time an attacker needs to cause meaningful damage.
AI agents compound this because they generate code that can contain secrets. An agent asked to "write a script that connects to our database" may produce hardcoded credentials if those credentials appeared in its context. The defence: never give agents raw credential material, and scan agent-generated output for secret patterns before it touches a repo.
3.5 Separate Audit Logs
Every agent's actions must appear under its own identity in a queryable log. Not mixed with Dave's activity. Not aggregated under a generic "automation" user.
When something goes wrong, you need to answer three questions in under five minutes: Which agent did this? What permissions did it have? Who approved them? If you can't, incident response becomes a forensic investigation into your own infrastructure.
4. What the vendors say (and what they're not saying)
Major AI vendors have started publishing guidance, but maturity varies widely.
Anthropic's Claude Code security documentation addresses prompt injection and recommends isolated execution environments. Thoughtful on safety architecture, but stops short of prescribing an identity model. Safety is their frame, not enterprise IAM.
Google's Gemini Code Assist operates under a shared responsibility model: you are responsible for the code your agents produce, including credential handling. Honest, but the burden is entirely on you.
Microsoft's Least Privilege for AI Agents blog is the most useful vendor document I've read. Token scoping, agent-specific identities, the principle that unjustified permissions shouldn't exist. If you read one, read this.
Noma Security and Kiteworks have published post-incident frameworks. Kiteworks' post-GitLost analysis is useful if you're defending against prompt injection as a credential theft vector. But these are reactive, not prescriptive.
And that's the real gap. NIST SP 800-63 and SP 800-207 apply partially, but neither addresses AI agent identity directly. No dedicated standard exists. The industry is building agent fleets with identity practices that would have been negligent for human users a decade ago, and standards bodies haven't caught up.
5. Running your own audit: the practical checklist
Steps you can take this week.
Step 1: Inventory every agent. Walk through every team, repository, and cloud account. Find every agent, script, bot, and autonomous workflow. If NHIs outnumber humans 144:1, you'll discover things you didn't know were running.
Step 2: Map every credential. For each agent, document what credentials it uses and where they came from. Flag human credentials, shared keys, and keys you can't trace to an owner.
Step 3: Check permission scope. For each credential, list what it can actually do. Not what you assume. Query the IAM policies. Read the token scopes. Most teams are surprised by what they find.
Step 4: Fix the worst offenders first. Start with agents that have broad production access using human or shared credentials. Replace them with dedicated, scoped, time-limited service accounts. Largest reduction in blast radius for the least effort.
Step 5: Automate enforcement. Use tooling like Okta for AI Agents, Auth0 for AI Agents, or Microsoft Entra Agent ID. If your IAM provider lacks agent-specific tooling, enforce through existing infrastructure: no key without an owner, no scope without justification, no credential without an expiry.
Run this checklist quarterly. Agent fleets change fast. A clean audit in July means nothing by October.
We're building at agent speed with human-era identity practices
That's the mismatch. The velocity of agent deployment has outpaced every identity control that took the industry two decades to develop for humans. Given that, the 69% and the 144:1 ratio aren't surprising. They're what you'd expect.
The fix isn't to slow down. It's to make identity part of deployment from day one. Every agent gets its own identity. Every identity gets minimum permissions. Every credential has an expiry and rotation policy. Every action carries an attribution trail.
None of this is advanced security engineering. It's the same discipline we apply to microservices and CI/CD pipelines. We simply forgot to apply it when we started building agent fleets.
Start the audit this week. The numbers say you'll find something.
Want to read
more articles
like these?
Become a NoCode Member and get access to our community, discounts and - of course - our latest articles delivered straight to your inbox twice a month!


