Manual onboarding and offboarding leave orphaned accounts
IT teams have run joiners, movers, and leavers (JML) for years from the hire and termination feed of the HR system. The rest is an onboarding checklist, a spreadsheet of what each role needs, and the memory of whoever handled the last exception. Contractors and partners get a list of their own, kept by a few colleagues with the contract PDF in one place and the guest accounts in another. The people who run it get every new joiner working on day one, and that takes most of their attention. Offboarding gets what is left. A leaver’s identity is disabled or deleted in the identity provider, so the sign-in stops. But the accounts, roles, and shares in each target system stay behind, orphaned, until someone cleans them up by hand. A mover keeps the identity, so the old team’s entitlements stay next to the new team’s. Every transfer adds another layer, and the privilege creep accrues until the next review happens to find it. A spreadsheet can’t grant or revoke anything, so every change becomes a batch of tickets, one per target system, and a faster queue only closes them sooner.
Accession1 is self-service provisioning of resources and access for people and AI agents. Teams decide access inside boundaries administrators set, and Accession1 grants and revokes it as people and agents join, move, and leave.
Joiners, movers, and leavers for AI agents
An employee joins once, moves every few years, and leaves once. Each change is rare enough to handle by hand, and the move is the one that leaks, because the old access outlives its reason by months.
A contractor or a partner’s representative comes for an engagement of weeks or months, so the same headcount brings several times as many joiners and leavers. They should get less than the employees beside them, but the folder or the role in front of them rarely offers anything narrower. And the end is recorded somewhere else, in procurement or in the partner’s own identity provider, so it reaches your target systems late or never.
An AI agent, the non-human identity (NHI) that comes and goes most often, is set up for a project, a workflow, or a launch, sometimes for a single task, and retired when the work is done. It moves when its team reorganizes or its workflow changes, and one team can run more agents than it has people. So agents join, move, and leave on the rhythm of the work rather than of the org chart, far more often than anyone on the payroll. Like contractors, agents need a narrower scope. An agent handles a range of tasks as open as a person’s, works by trial and error, and can exercise a permission a person would never have used.
A process that copes with a few employee changes a month strains with contractors, and it can’t keep up with agents at all. Closing its gaps for employees and contractors now means the first agent a team adds lands in rules that already work, on the way to an agentic organization.
Identity lifecycle automation, from the first day to the last
Take an account executive who moves from the DACH territory to NORAM in April. Sales operations owns the territory and feeds it into the identity provider, so the move is recorded on the day it happens. A request brings the NORAM accounts in HubSpot one ticket at a time, but the DACH accounts stay assigned on top of them. A timer on the DACH access ends it on a date someone guessed, months after the reason ended, and the next move asks again. A usage report keeps DACH, because the account executive still opens those deals to answer a colleague, and trims the NORAM pipeline nobody has touched yet.
In Accession1 the territory becomes a label, and continuous reconciliation grants NORAM and revokes DACH in one pass. The identity lifecycle runs the same way every time: the identity provider sends the change as a SCIM request, the labels on the identity change, and reconciliation brings every grant in line with the new state. An agent identity Accession1 creates in the identity provider goes through the same lifecycle, and there Accession1 records the join, the move, and the retirement itself. The same happens when a partner’s identity provider stops sending a representative, or a team deactivates the agent it set up for a launch. Every grant that came with them goes.
A joiner gets what the workspace’s access policies grant on the first day, scoped to the team’s actual work rather than a static baseline. An agent registered this morning has no usage to derive access from, and it doesn’t need any, because its place in the access graph already says what it gets. On a mover’s first day, a contract’s last, or the day an agent is retired, the record shows what changed in each target system and which rule changed it. So the next access review reads the rule that moved with the account executive, instead of hunting for the DACH grants left over from the move.
Narrower access for contractors, partners, and agents
The more often an identity joins and leaves, the less it should hold while it’s there. In Accession1 outside people come from your identity provider as guest accounts, or from the partner’s own, connected as a separate identity source that administrators scope to the workspaces it serves. Employment type and company arrive as labels, so access policies apply least privilege to contractors and a partner’s people, with a narrower role on fewer resources than the employees beside them. An agent sits in the workspace of the team it works for, and that team is its owner, so its access also ends when the owner moves on. It starts one level below the team, read-only where the team can write.
Context-aware design records your partnerships and the share of contractors in each team, so a workspace that relies on them and handles customer data gets a tighter boundary and a higher risk tier. Self-service inside the workspace can give them less still.
A reorganization is an access policy edit
A renamed team or a department moved under another is a change in the identity provider, and at most an edit to the rules that name it. A team that splits in two is a second workspace and the rules that say which resources go with it. A shared drive handed from one team to another changes its workspace, which moves its ownership and the access to it while the drive stays where it is. Agents carry labels like a person, so they move with their team in the same edit. Reconciliation carries it to every target system, and no approval sits in the path, because no boundary moved.
A merger or a new legal entity is different, because it draws new boundaries. When payroll moves from a subsidiary into the parent company, the AI assistant drafts the new workspace and its rules from the context, and administrators weigh the impact and draw the boundary. The shared drives, channels, and repositories stay where they are while their owners change, so a reorganization never migrates a file.
