I ran across a post from The Identity Salon discussing AI, private keys, and eventually the bigger issue: sensitive data.
Man I wish I could have been in that room.
Because while the conversation started with keys, the real issue isn’t keys.
It’s Non-Human Identities.
The Question Isn’t “Should AI Have Access?”
They already do.
We’ve spent years stripping elevated access from humans because:
- Humans get phished
- Humans get tired
- Humans make bad calls
But NHIs? They run silent.
Service accounts, API tokens, CI/CD identities, workload roles — most organizations still don’t:
- Have full inventory
- Rotate credentials consistently
- Review scope creep
- Enforce ownership lifecycle
That’s the baseline.
Now layer AI on top.
AI Doesn’t Just Access Data. It Recombines It.
Traditional NHIs are mostly deterministic:
- If X, call Y
- If condition met, write record
AI agents don’t follow clean execution paths. They:
- Synthesize responses
- Merge context from multiple systems
- Generate new derived output
- Reframe answers based on prompt context
The risk isn’t just access.
It’s recombination and disclosure during solution delivery.
An AI agent might pull from HR, finance, and internal policy and combine it all into a helpful executive summary.
All individually authorized.
But was that combination authorized?
That’s where things get uncomfortable.
Least Privilege Has to Evolve
Least privilege answers:
What can this identity access?
It does not answer:
What can this identity construct from what it accesses?
If you don’t have:
- Output constraints
- Data classification enforcement
- Role-aware response boundaries
- Context-bound retrieval limits
You don’t have governance.
You have hope.
And as my audit friends would say:
Hope is not a control.
The Real Risk: Delegated Authority at Scale
AI agents don’t just retrieve data. They:
- Open tickets
- Trigger workflows
- Generate documents
- Influence human decisions
When an AI NHI operates across multiple roles or entities, you’re delegating authority.
If those boundaries aren’t explicit, you get:
- Privilege blending
- Cross-role data leakage
- Silent policy violations
- Decisions without accountable ownership
The real question isn’t:
Should it hold a key?
It’s:
Who is responsible when it makes a bad call?
What Do We Do Monday Morning?
This doesn’t need to be theoretical. Here’s where I’d start.
1. Inventory Every AI-Backed Identity
If an AI system exists, it has:
- A service principal
- A workload identity
- API credentials
Document them. Assign an owner. No exceptions.
2. Define the Principal
Every AI agent should map to:
- A sponsoring human
- A business unit
- A clearly defined purpose
No floating AI identities.
3. Scope for Construction, Not Just Access
Review not only what the AI can retrieve, but what it can combine.
If it can access multiple high-sensitivity domains, require explicit approval for cross-domain synthesis.
4. Implement Output-Aware Logging
Don’t just log:
Agent accessed database.
Log:
Agent combined HR and Finance data into response.
If you can’t see it, you can’t govern it.
5. Treat Agents Like New Employees
For the first 90 days:
- Heightened monitoring
- Output review sampling
- Restricted authority
When scope changes, the review cycle resets.
No silent privilege growth.
This Is an IAM Maturity Problem
This isn’t an AI problem.
It’s an IAM maturity problem.
AI is accelerating the consequences of the NHI sprawl most of us already have.
We didn’t finish governing machine identities.
Now they can talk.
And that changes everything.
Leave a Reply