What we hear
Agents arrived faster than anyone could govern them.
Inherited from user214 permissions
Actually used11
Least privilege
They hold far more than they use
To move fast, agents inherit a person's or an admin's access. Most of it is never used, and all of it is open to whoever controls the agent.
We went with the broad permissions inherited from the user, to move fast.
Platform security lead, technology
⚿ svc-erp-prodNever expiresAdmin Used by 3 agents
Credentials sprawl
They run on shared, standing credentials
Service accounts and API keys are shared across agents and never expire. One leaked key opens everything those agents can reach.
Regularly review delegated credentials for scope creep and unused grants.
IAM requirement, travel company
svc-erp-prodWhich agent?Authentication and visibility
Nobody can tell which agent did what
Agents act under a person's login or a shared key, so their access can't be seen, attributed or audited.
The board asked if we have visibility into the agents being run by third parties that have access into our systems, and we don't have that either.
IT leader, manufacturing
Register · Own · Decide · Enforce
The same agents. Now governed.
Oak is the decision engine for AI agent access. It gives each agent its own identity and owner, decides every request from who invoked it and why, and issues access that ends with the task.
Register
No single list
Agents run under people's logins and shared keys, across several platforms.
TodayRegister every agent
Every agent is registered as its own identity, authenticating as itself, not through a person's login or a shared key. Oak shows the accounts and keys it runs on today.
Strong authenticationOwn
3agents with no ownerNobody answers for it
Two were built by someone who left 142 days ago, and they still run.
Today7 of 7agents ownedTie it to a person
Every agent has an accountable owner and a known invoker. When someone leaves, their agents are re-owned, not orphaned.
Lifecycle automationDecide
12 of 21grants never usedAccess nobody checks
Access is granted once at setup and never revisited.
Today9grants left, all in useDecide what it may do
Oak decides each request from the owner, the person invoking it and what that role normally needs. Routine requests are approved on the spot, unusual ones go to a person, and unused access is removed.
Least privilege · Just-in-time accessEnforce
5agents on standing credentialsKeys that never expire
Five agents share two standing accounts, one with admin rights.
Today0standing credentialsEnforce it with short-lived access
Oak issues access scoped to the session and ends it with the task, at the gateway or hooks you already run. A kill switch ends any session in one click. Every decision is on record.
No standing credentials · Audit-ready
Decision logNothing on record
Every decision weighs what its owner and the person invoking it are entitled to.
One request, start to finish
An agent asks. Oak decides. Access ends with the task.
01
Ask
A marketing manager tags an agent in Slack: prepare the analyst briefing assets. The agent asks Oak for read access to the design repository and points to the Slack request.
02
Check
Oak confirms who invoked the agent, what that person is entitled to, and whether marketing normally reaches that repository.
03
Decide
It isn't typical for marketing, so the request goes to the repository owner with Oak's reasoning attached. Routine requests are approved on the spot.
04
Issue
Once approved, Oak issues and provisions access for this task only. When the task ends, so does the access, and the whole exchange is on record.
@Briefing agent prepare the analyst briefing assets
Requesting access from Oak
design-repo · readEvidence: the Slack request- ✓Invoked byNina Alvarez, Marketing
- ✓Entitled toBrand assets, read
- !Peer usage2 of 48 in marketing reach it
- ✓ScopeRead only, one task
request | Nina Alvarez via Slack |
decision | Approved by Sam Lee |
issued | Read, this task only |
ended | Access ended with the task |
Connects anything
Agents reach everywhere. So does Oak.
Oak governs the apps your agents touch, from cloud to on-prem. If it has identities inside, Oak reaches it.
And hundreds more, with new ones built in days.
See it in your estate
Find the standing access your agents don't need.
Bring one platform. Within hours we'll show you its agents, the shared accounts they run on and the access they never use.
Book a demo →Oak Identity Operating System
Start with one use case. Grow without starting over.
Every app, every identity, in days
Out-of-the-box and custom connectors for SaaS, cloud, on-prem and homegrown apps bring every human, NHI and AI agent under one governance program, alongside the IdP and IGA you already have.
The graph no one else can build
Deep connectors read every entitlement down to the resource level and correlate it with your org structure and real activity. The result is the only activity-based identity graph: not only who has access, but who should.
Least privilege that doesn't drift
Role mining runs continuously on the graph, so roles and groups stay lean as your org changes. Unused access surfaces as it appears, and sensitive access moves to just-in-time.
Agents do the work. Your team approves.
Oak's Acorns find and fix risk, through a ticket or directly in the app, and confirm every fix in the graph. Every change is explained, approved, reversible and on record.
“Build a landing pad: show me all the identity data in one place, tell me what's wrong, and let me fix it. Then expand from there.”
CISO, global financial services company, 40,000 employees
Start with agents. Keep going.
The same graph governs everything else.
Agents act for people and run on service accounts. Once Oak sees one, it sees the rest.
Questions, answered.
What counts as an AI agent in Oak?
Any agent that holds access in your estate: agents built on SaaS platforms, homegrown agents running as workloads, and shadow agents nobody registered. Oak treats each one as an identity with an owner, access and activity.
How does Oak decide an agent's access request?
From the agent's owner, the person invoking it and what that role normally needs. Oak shows its reasoning, approves routine requests on the spot and sends unusual ones to a person.
Does Oak issue credentials to agents?
Yes. Oak issues short-lived access scoped to the session, so agents don't keep standing credentials.
Where does Oak enforce its decisions?
Where your agents already run: Oak's gateway, the gateway you have, or a hook in your agents' code. No rebuilt agents.
Can we stop an agent mid-task?
Yes. The kill switch ends the session in one click and revokes its access.
Can an agent reach more than the people behind it?
No. Every decision weighs what the agent's owner and the person invoking it are entitled to.
Can Oak show auditors which agents reach sensitive data?
Yes. For every agent: its owner, what it can reach, what it uses, and every access decision on record.
How does Oak find an agent's owner?
Oak resolves the accountable human from your identity data and keeps that link current. When an owner leaves or changes role, their agents are flagged instead of running unowned.
Will Oak change access without our approval?
No. Oak recommends, your team approves, and every change is explained, reversible and on record.
How fast can we see our agents?
Hours from connection to a full inventory of your agents. Connecting your key systems takes days, not a project per system.
AI agents made identity wilder. Tame them.
Give every agent its own identity, only the access its task needs, and no standing credentials.
Book a demo →