Product Self-service resource and access provisioning

What the context holds

The context is the record of the facts access depends on, and each fact says whether the AI assistant inferred it, found it in a public source, or your team established it from its institutional knowledge. The AI assistant also works from the templates, workspaces, and identity sources your tenant already holds, so a draft never ignores what exists.

• Geography, from facilities and markets to where people work
• Legal entities, their ownership and governance, and the regulation and data sovereignty each one falls under
• Industry, business model, offerings, customers, and the categories of data that come with them
• Structure and partnerships
• The classification scale every resource is assessed on, with its label keys and accepted values for confidentiality, criticality, and data type

Where institutional knowledge enters

The assessment starts from public research and what is typical for your sector, so the first draft already fits a logistics company in the EU or a law firm that keeps its clients’ work apart. An administrator then reviews it one area at a time and corrects it from what only long-standing team members know: which systems are critical, which data is sensitive, who owns what, and which partner gets which access. That review turns the spreadsheets, runbooks, and experience of your most senior people into facts the design rests on, instead of knowledge that leaves with them. As the organization changes, the AI assistant refines the context from sources such as audit logs and proposes changes to the graph that administrators take or leave. A reorganization updates the context and the graph together.

How the graph is drafted from it

From the context, the AI assistant drafts the tenant level of the access graph, and administrators shape it into the one that applies. The identity provider’s attributes arrive over SCIM as labels on the same taxonomy, so a changed department or employment type means something for access.

• Workspaces along the way the business is organized, as business units, project teams, client matters, or joint ventures, each with a boundary
• A risk tier for each template, from business function, regulatory scope, data sensitivity, and system criticality
• One label taxonomy that identity attributes, access policies, and resources share
• Least-privilege roles per template, mapped to the target system’s own permissions

What administrators control, and what they hand over

Administrators decide what self-service may do: which identities each workspace receives from the identity provider, and which templates and roles it may provision from. That boundary is set once, where a ticket used to check the same thing by hand on every request.

Resource and access provisioning in one flow

Access to a resource is configured on the resource, so the resource comes first. A provisioning ticket ends when the drive exists and the requester can open it, and the rest of the team gets access through a manual share or another request. Most access tools leave creating the drive or the repository to that ticket, so self-service stops halfway. In Accession1 a workspace member picks a template from the catalog, names the resource, and writes its access policy in the same flow. The OpenTofu module behind the template creates it in Google Drive, Jira, or GitHub, with its roles mapped to that system’s own permissions, so the team’s access exists the moment the resource does.

How the access policy gets written

The member says who should reach the resource in business terms, and the AI assistant proposes the labels and the label queries. It drafts from the context administrators designed from and from the workspace’s existing resources and access policies. So the draft accounts for what the member wouldn’t have in view, such as a rule that already grants or a label another workspace uses differently. Every access policy starts from unprivileged defaults. The AI assistant also learns from how earlier self-service turned out in similar workspaces of your tenant, so the next member’s draft starts closer to right.

Why the workspace level

Inside a workspace is where the real knowledge lives: who does what, how the tools are used, and how the team works together. Access designed top down, from the org chart and job titles, is unspecific at best, and privilege creep sets in because access policies are written far from the work. Writing them in the workspace puts the decision with the people who know what a day of the work needs. The tenant-level boundaries are what make that self-service safe to trust.

Provisioning for AI agents in the same flow

An AI agent is a non-human identity (NHI) with the same lifecycle as the people it works with. It is added at one level and owned by the people there: the tenant’s administrators, a workspace’s members, or one person. Accession1 creates its agent identity through your identity provider’s native feature and records the owner. By default an agent gets its owner’s access one level lower in scope, read-only where the owner writes. The risk tier of the resource and of the agent narrows it further, so a sensitive resource can carry no agent role at all. A change that needs a privileged role goes through just-in-time elevation from the owner, and when the owner moves on, the agent’s access ends with them.

Just-in-time elevation and break-glass access

A person who needs a privileged role for one change, or an agent whose task needs a role its standing access doesn’t include, requests a temporary grant on top of what the graph derives. That grant is a just-in-time (JIT) elevation with an end date, and reconciliation removes it on that date whether or not a label changed. The elevation policy administrators write decides from the risk tier of the target system whether approval is automatic or comes from a workspace peer or a tenant administrator. Break-glass access is the emergency path of the same mechanism, granted quickly for an incident and expected to end with it.

Attribute-based access control on role-based systems

An access policy matches labels on identities, from the attributes your identity provider holds, with labels on resources, from their template, their workspace, and your own classification. The industry calls this attribute-based access control (ABAC), and here it sits on top of each target system’s RBAC. The labels decide which role an identity holds, and the target system enforces the role as it always has. A role is granted while the labels match and removed when they stop, so the access policy says who the resource is for, never who was on the team the day it was written. Finer-grained roles become sustainable where a ticket queue could not keep up.

Automated provisioning and deprovisioning on every change

Reconciliation runs on any of these: a joiners, movers, and leavers (JML) change your identity provider sends as a SCIM request, a resource provisioned or relabeled, an access policy edited, or a boundary or tenant-level rule changed. It evaluates every access policy against the new state, grants where labels now match and revokes where they stopped matching, keeps each resource’s configuration as declared, and retries transient failures until every target system converges.

Deterministic automation, with no AI in the path

Because AI behaves non-deterministically, it stays out of reconciliation, so the result can be checked rather than trusted. The AI assistant answers questions about the access state, who has access to what and why, and never changes it.

Access that follows the organization

Dynamic access management means a grant exists while the labels match and disappears when they stop. The change can come from anywhere in the organization: a team that splits in two, a department moved under another, or a resource whose owning team changes. So a reorganization is an access policy edit instead of a migration project, and pipelines and AI agents follow the same lifecycle as people.

A record that is current on any day

Continuous governance means the record an auditor reads is current on any day instead of rebuilt for each audit. Each grant records one identity holding one role on one resource, derived from one rule, so administrators query the complete access state across target systems from one API. User access reviews (UAR) still decide whether the rules are right, but they no longer start by hunting for stale grants.