The ITSM queue, held together by the people who run it
IT and IAM teams keep the queue moving with runbooks, a spreadsheet of who approves what, and the knowledge of whoever has been there longest. Most requests are still answered within the week, and that is down to those people rather than the queue. Whoever picks up a ticket sees part of the picture, so an aspect a colleague would have caught is missed, and configuration drift accrues one ticket at a time. The identity provider, the ITSM tool, and the target systems each do their part, and a person connects them for every request, partly by hand in a console and partly through infrastructure as code.
That held while requests grew with headcount. It stops holding once teams add agents, because an agent that reasons in seconds and waits days for access gets handed a person’s token instead, with everything that person can reach.
Accession1 is self-service provisioning of resources and access for people and AI agents. Teams provision what they need from a catalog administrators approve, and Accession1 keeps each resource and its access in line on every change.
A faster ticket queue still leaves static grants
The tempting fix is to speed the queue up, with more automation in the runbook or an AI agent answering the tickets. Both close tickets sooner, but both apply the same static grant a person would, because the ticket is the trigger. A support team’s triage agent gets its Zendesk token sooner, and the grant still outlives the reason it was filed for.
In Accession1 the trigger is the change itself. Any of these sets off reconciliation: a shared drive provisioned with a confidentiality label, a hire your identity provider sends as a SCIM create request, or an access policy a workspace member edits. Reconciliation then grants and revokes in every target system without anyone filing anything. A new hire or a new agent gets what its place calls for on day one, before it has a history for anyone to look at. An agent gets less than the person it works for.
Identity governance that provisions, too
Access to a resource is configured on the resource, in the target system, so there is nothing to configure until the resource exists, and a resource is worth nothing until the team can reach it. A ticket asks for the resource, whoever creates it gives the requester access, and the request ends there. The requester then shares it with the team manually in the target system, with no rule behind the grants, or files additional requests as the team finds out who needs what.
Most identity governance and administration (IGA) tools manage access to systems and resources that already exist, and leave creating the drive, the channel, or the repository to a ticket. So a request workflow that got faster still stops halfway. The access is approved, the drive waits in another queue, and once it arrives, the team’s access to it is one more request.
A resource catalog fails from the other side. It creates the drive and leaves the access to the requester, who configures it manually in Google Drive. Governance then rests on a weak after-the-fact audit, which commonly leaves excessive permissions in place, and they become the risk the day an agent is granted access the same way. A resource created by hand also carries no classification until someone gets around to it, and nothing keeps the identity provider and the target system in agreement as the team, the rules, and the drive change.
Accession1 provisions the resource and its access as one flow. A workspace member picks the template, names the resource, and writes the access policy for it in the same step, through self-service provisioning. The team’s access exists the moment the drive does, as a rule that says what it is for and who needs access to it. The AI assistant proposes the classification labels the resource should carry, so governance starts at creation instead of at the next review. Every access policy starts from unprivileged defaults, so least privilege is designed in rather than trimmed later. Continuous reconciliation keeps both current whenever an identity, an access policy, or a resource changes, and the record an audit reads is the rule.
Engineering feels this first. The coding agent that ran on a token for every repository reaches only its engineer’s repositories, read-only where the engineer writes, and the CI pipeline deploys only to its own service’s namespaces. Both came from the catalog with their rules.
The labels also carry the cost center, the project, or the business unit from the start, and people arrive with the cost center your identity provider holds. Chargeback starts from the record of who owns and holds what instead of a tagging cleanup. Accession1 holds no cost data, and your billing tool reads the attribution.
From working the queue to curating the service catalog
Routine requests stop reaching IT, so the backlog stops growing with headcount or with agents. Your team spends the time on the catalog, the boundaries, and the risk tiers, where its judgment counts. That work is context-aware design. Access reviews run on the same rules, and so do joiners, movers, and leavers (JML). The next team that needs a cluster finds one in the catalog, or asks your team whether it should offer one.
