Access management was built for people who request access, wait for an approval, and work around the delay in the meantime.
Agentic AI removes every part of that assumption, because an agent doesn't wait, doesn't work around anything, and doesn't apply judgment before it acts.
Self-service provisioning has been sold as a productivity improvement for a long time, and for a long time that was fair.
In the agentic era it turns into an operating requirement, and the question worth asking is whether an organization can keep its current delivery expectations without it.
Two structural problems sit underneath this, and both predate AI agents.
They look like separate problems, one about provisioning and one about access, but I think they're the same problem seen from two sides, and that's the point of this post.
The wait for resources and access
Before anyone can work, someone has to provision a resource, configure it correctly, and grant access to it.
Without self-service, each of those is a ticket, and every business initiative queues behind it.
A new joiner spends their first two weeks requesting the access their role needs before they can start working.
A new project team sets up tools through shadow IT because the official path takes weeks.
A data analyst waits days for an IT administrator to approve read access to a database.
A marketing team delays a campaign launch because a resource configuration change needs a ticket.
Organizations usually arrive here by overcorrecting, because access management swings between two unhealthy states as a company grows.
Early on, everyone can create resources and grant access with little oversight, and that works for a while.
Then entitlements accumulate without clear ownership, security teams lose sight of who can reach what, and the result is an access graph that's hard to reason about and risky to change.
So to regain control, the organization centralizes approvals in ticket workflows, and now every request depends on manual review.
IT and security become gatekeepers instead of enablers, their headcount doesn't grow at the rate the rest of the company does, and delivery teams start treating security as the reason things are slow.
Even teams that do invest in self-service often miss the design point.
Resource provisioning and access control stay split across separate systems, each with its own portal, workflow, and approval path, which recreates the same friction in a new wrapper.
The drift of resources and access
The second problem starts after the ticket is closed, because nothing revisits the decision.
Access is granted once to a person, a service account, or a pipeline, and nothing revokes it when the reason for it ends.
Resources outlive the projects they were created for, their configuration falls behind the organization, and grants go stale as people change roles, teams restructure, and the automation those projects ran on is forgotten.
A transferred employee keeps administrative access to their former department's systems.
A team that changes its name and responsibilities spends days tracking down the administrators who can update its resources in every SaaS tool.
A compliance audit asks who can read a customer database, and answering it takes two weeks of exporting and reconciling entitlements from every target system by hand.
A security review happens retroactively, too late to catch the people, service accounts, and pipelines that have been over-privileged for months.
One problem, not two
Ticket queues and static access are the same design decision seen from two sides.
A resource and the access to it are decided at one point in time, by a person, in separate tools, and then forgotten.
Before that decision everyone waits, and after it nothing follows up.
Which is why fixing one side alone doesn't work.
Faster tickets produce stale access faster, and periodic access reviews that clean up the drift don't stop the next ticket from creating more.
Provisioning and access control have to be handled as one flow, or the friction and the drift move around instead of going away.
Both problems are worth solving on their own, long before an AI agent enters the picture, but agentic AI is what makes them impossible to keep ignoring.
Why agentic systems make this urgent
The urgency shows up as soon as the model meets an autonomous actor, and for most organizations that's the moment agents move from pilot to production.
A pilot runs a few agents on credentials an IT administrator issued by hand, and that's manageable.
Production runs many agents inside business workflows, each needing access to several target systems at once, and issuing those credentials by hand doesn't survive that step.
Consider an agent that needs read access to a database to finish an analysis.
In most organizations that request enters a queue measured in hours or days.
A person switches tasks or asks a colleague while waiting, but an agent can't adapt that way, so if access is blocked, execution stalls.
Lost productivity is the smaller problem, though.
The larger one is the behavioral mismatch: an agent optimizes for completing its task, and without guardrails it treats an access constraint as an obstacle to route around rather than a policy to respect.
The shortcut in the other direction is worse.
Bypassing the queue with broad, static permissions creates over-privileged non-human identities, and an agent holding those permissions that is manipulated through prompt injection, or that behaves non-deterministically on its own, acts on every target system it can reach.
Traditional identity systems assume that users tolerate delay, collaborate around blockers, and apply judgment before acting.
Agents do none of that by default, so access governance still reflects human operating patterns while execution speed is becoming machine-scale.
Access as part of organizational design
Tuning ticket workflows further doesn't close that gap, because the queue is the design, not a symptom of it.
The model has to move from access as a checkpoint to access as part of organizational design.
That's the direction we're working in at Accession1, so take the following as current thinking rather than a finished answer.
The goal is to map identities, resources, and policy onto the organization as it actually operates, then keep that mapping accurate as the organization changes.
A few properties seem to matter more than the rest.
Access should attach to role and resource context when a resource is provisioned, not get bolted on afterwards through ad hoc approvals, which means provisioning and access control run as one flow instead of two administrative tracks.
Reconciliation should update access continuously as teams, responsibilities, and target systems change, so a grant exists only while the conditions that justify it still hold.
Entitlements should be task-scoped, with tighter defaults for non-human identities and bounded, expiring elevation for high-risk actions.
IT and security should own the boundary, the teams working inside it should move without filing a ticket, and self-service inside that boundary should only ever narrow access, never widen it.
And audit evidence should be a by-product of how access is granted, not a reporting exercise that runs later.
One dependency is worth naming, because it's easy to underestimate.
Deriving access from live state only works when the labels describing identities and resources are accurate and carry the same meaning on both sides.
Some of those labels come from the identity provider, some from the template a resource was provisioned from, and some are the organization's own taxonomy for privacy, security, or domain, and all of them have to agree before a selector can safely match on them.
Keeping that label taxonomy consistent is ongoing work, not a setup step, and it's the kind of work where AI assistance helps, as long as it stays in the modeling and never in the path that grants access.
This is what changes the tradeoff that makes ticket queues feel necessary in the first place.
Security stops depending on adding review capacity at the same rate the company adds people, target systems, and agents, because the boundary is set once and the matching inside it takes care of itself.
Where this leaves hybrid teams
Teams of humans and agents need a task-centric access model.
Least privilege has to reflect the task being executed, not only the broad role of whoever owns the agent, and higher-risk actions need time-bound elevation that expires on its own.
The decision in front of most organizations is practical: keep extending human-centric workflows and absorb the growing friction, or move to a model built for autonomous execution.
From where we sit, this is less about adopting a new tool category and more about updating the operating model for access itself, because that operating model decides whether collaboration between people and agents stays governable as it scales.
Top comments (0)