Your company already has hundreds — maybe thousands — of non-human identities.

Service accounts. API keys. Cloud workloads. CI bots. That one “temporary” token from 2023 that is still in a GitHub Actions secret.
And now: AI agents.

Ask one question before you ship the next one:

Who owns its credentials?

Not who built the agent. Not who owns the Slack channel it posts into. Who is accountable for what it can access, what it can do, and when that access should die?

For a lot of companies the honest answer is: nobody.

That’s a problem. An agent is not “just another service account.”

A service account is boring. An agent is not.

A service account usually does one job with a relatively fixed set of permissions. You grant it s3:GetObject on one bucket, you forget about it for 18 months, and (if you’re lucky) nothing interesting happens.

An agent can pick tools, accept credentials, hop across systems, chain actions, and hand work to another agent. What it can do at runtime is not the same as what you thought you configured on day one.

That’s where classic access control starts to fall apart.
You reviewed the identity. You did not review the action surface.

The NHI problem just became an AI problem

Non-human identities already dwarf humans. Some industry numbers put the ratio around 80:1. Plenty of enterprise datasets are worse.

Secrets are multiplying at the same time.

GitGuardian counted 28.65 million hardcoded secrets in public GitHub commits during 2025. AI-service secrets jumped 81% year over year. Those numbers will be stale by the time you finish this paragraph. The direction will not.

The leak is only half the story. The other half is what happens when an autonomous system already has the credential. Take a coding agent with access to GitHub, AWS, CI/CD, and your secrets manager.

Documented purpose:
Help developers deploy applications.

Effective authority:
Read source → pull secrets → change infra → ship to production.

Those are not the same sentence. Now add one of the usual messes: prompt injection, a poisoned repo, a shady MCP server, a “helpful” document that isn’t. The attacker doesn’t always need to steal a key. They can talk to the thing that already holds the key. That’s the part most IAM diagrams still pretend isn’t happening.

Permissions in isolation are a lie

Traditional access reviews ask:
Can this identity access Salesforce?

For agents, that question is incomplete.

You need:
What can this agent accomplish through Salesforce, given everything else it can touch?

Picture a support agent wired into:

• Salesforce
• Zendesk
• Stripe
• Slack
• an internal customer DB

Each box looks fine on its own. Together they are a refund machine with a Slack announcement feature. Identify the customer. Pull the account. Read billing. Post details to Slack. Issue a refund. The risk is the combination, not the individual checkbox.
If that agent can spawn a billing agent, which can call another tool, the authorization chain gets even harder to draw on a whiteboard. At that point “it’s just a service account” is coping, not a model.

You already have a framework. It’s called SOC 2.

You do not need a new compliance religion for this.

SOC 2 logical access controls already say: grant appropriate access, authorize credentials, apply least privilege, and take access away when it is no longer justified.

That’s the problem, in auditor English.
The question you should be able to answer in a room with an auditor: Show me every production agent. Who owns it. What it can access. Why. And the last time someone actually reviewed that.

Most orgs can do this for employees.
Many can do it for old-school service accounts.
Very few can do it for agents.

That’s the gap. Not “we need a new framework.” We need to apply the one we already pay for.

Treat the agent as an identity

Every production agent should have a record. Not a Notion page someone wrote once. A living identity record.

Something like this:

Attribute	Example
Agent	support-agent-prod
Owner	VP Customer Success
Purpose	Resolve Tier-1 tickets
Identity	Workload identity
Credentials	Short-lived token
Tools	Zendesk, Salesforce, Stripe
Production access	Yes
Delegation	Billing agent
Maximum action	Refund ≤ $500
Last review	2026-09-01
Revocation	Automated

The spreadsheet is not the point.
This chain is the point:

Agent → Identity → Credentials → Permissions → Owner → Business purpose

Break any link and your access-control evidence is incomplete. Auditors notice that. Attackers notice it first.

Least privilege has to become runtime privilege

Classic least privilege:
Give the service account only what it needs.

For agents, that is still too wide.
Better:

Give the agent only what it needs for this action, on this resource, for this window of time.

Not: AWS Administrator
Yes: deploy service X to staging.

Not: Stripe access
Yes: refund transaction X, up to $500.

This is why short-lived credentials, scoped tokens, workload identity, per-tool auth, and a human in the loop for high-risk actions matter.
The goal is not to hobble the agent. The goal is a blast radius you can describe without waving your hands.

Start with an inventory. It will be ugly. That’s useful.

You don’t need a perfect agent IAM platform by Friday.
You need a list.

For every production agent, fill these in:

• Agent
• Owner
• Business purpose
• Identity
• Credential
• Credential TTL
• Tools
• Read permissions
• Write permissions
• Production access
• Delegation
• Sub-agents
• Human approval
• Last review
• Revocation method
• Blast radius

Then ask the questions people avoid in Slack:

Who owns this?
What credential is it actually using?
What can it do if you stop being optimistic?
If it goes sideways, can we kill it in seconds?
Can we prove any of this to an auditor without a scavenger hunt?

You will find gaps. Good.
The risk is not that your company has AI agents.
The risk is agents with authority nobody can explain.
Your agents already have credentials.
Give those credentials an owner.

Be strong and safe.