Access graph
An access graph is the whole of how identities connect to resources: which identities reach which resources, through which roles, and why. Most tools discover it from the permissions, logs, and alerts every system already holds, and infer from that current state what access should be. In Accession1 the access graph is designed, and it is the desired state. It is everything your tenant holds: the workspaces and their boundaries, the identity sources and the identities they export, the templates and the resources provisioned from them, and the access policies and the grants they derive. Labels, and the access policies that match on them, define how they connect. It mirrors how your organization is structured, who decides, and who works together, and continuous reconciliation applies it to every target system on every change. It has two levels. Administrators draw the boundaries at tenant level, and workspace members write the access policies at workspace level, inside those boundaries. At both, the AI assistant drafts from the context and from the graph that already exists. See context-aware design and self-service provisioning.
Access policy
An access policy declares the access of a workspace, by rules that match identities to resources on their labels. Each rule says which identities get which role on which resources, so the policy keeps applying as both come and go. See dynamic access management.
Accession1
Accession1 is self-service provisioning of resources and access for people and AI agents. It derives access from what each identity is and what it works on, instead of from tickets that were approved once. It sits between your identity provider and your target systems. Its three core capabilities are context-aware design, self-service provisioning, and continuous reconciliation. See how self-service resource and access provisioning works.
Administrator
In Accession1, an administrator owns the tenant-level configuration: where each workspace’s boundary falls, which identities it receives, and which templates and roles it may use. Administrators draw every boundary, working from the AI assistant’s drafts, so nothing at tenant level takes effect without them.
Agent identity
An agent identity is the dedicated identity an AI agent gets in an identity provider, so it never works under a person’s login or a shared token. Identity providers now offer it natively, such as Microsoft Entra Agent ID and Okta for AI Agents, and Google Cloud uses a service account. Accession1 integrates with those features, so an agent added to the tenant, a workspace, or one person gets its identity from Accession1 and the people at that level as its owner. Its baseline comes from that placement, one level below its owner’s. See SCIM and Terraform integrations for access.
Agentic organization
An agentic organization is an operating model in which AI agents do most of the execution, while people supervise, decide, and handle the exceptions. It describes how work is organized, not a technology, and it multiplies the identities an organization has to govern. See identity and access management for the agentic organization.
Agentic overhead
Agentic overhead is the sum of what agentic AI adds to the access work IT and security teams already carry, and of the new challenges it brings. Agents multiply identities, each on a lifecycle of its own, so a small team meets the joiners, movers, leavers, reviews, and least privilege work of a large organization, and each agent can use any permission it holds. It is due the day the first team runs agents, whatever the organization’s size. See identity and access management for the agentic organization.
AI agent
An AI agent is software that acts on behalf of an owner, with some autonomy over the steps it takes. For access, an AI agent is a non-human identity: it needs an owner, access narrower than its owner’s, and a lifecycle that ends its access when its purpose does. Unlike a service account or a pipeline, an agent is not restricted to one specific, static task. It handles a range of tasks as wide as a person’s, so its permission requirements are as hard to predict, while it gets less trust than a person. See AI agent access control.
AI assistant
Accession1’s AI assistant collects and maintains the context, helps administrators and workspace members design their access graph, and answers questions such as who has access to what. It works from the context and from the existing access graph at the level it works on. At tenant level that is the templates, workspaces, and identity sources of the tenant. At workspace level it is the catalog, resources, and access policies of one workspace. So a change accounts for what a person would not have in view. It never decides a grant and never takes part in reconciliation.
Attribute-based access control (ABAC)
Attribute-based access control decides access from attributes of the identity and the resource, such as a department, an employment type, or a confidentiality label, instead of from a list of named users. In Accession1 access policies match labels on identities with labels on resources to decide which role an identity holds, on top of each target system’s role-based access control (RBAC), which still enforces the role. See self-service provisioning.
Attack surface
The attack surface is every way into an organization’s systems, and in access terms every standing credential, shared token, and identity nobody owns, because each is a way in for whoever obtains it. It is measured before a compromise, where blast radius is measured after one. In Accession1 fewer identities hold a standing privileged role, agents never work under a borrowed login, and an elevation expires, so there is less for an attacker to obtain.
Birthright access
Birthright access is access granted automatically to a new identity from attributes such as job title, department, or location, updated when the identity moves and revoked when it leaves. Most organizations keep it to a static baseline administrators decide centrally, and list the rest in an onboarding doc of whom to ask. In Accession1 birthright access comes from the access policies of each workspace, so a new identity whose labels match gets what the team’s work needs on day one. See joiners, movers, and leavers.
Blast radius
The blast radius is everything a compromised identity can reach, so it is what one prompt injection or one leaked token turns into damage. Excessive permissions widen it, and an agent can exercise ones a person would never have used. In Accession1 an identity holds only what the rules give it and an agent less than its owner, so the blast radius of any one identity stays small. See AI agent access.
Boundary
A boundary is where a workspace’s line falls: which identities it receives, drawn along a business unit, a client matter, an information barrier, a plant, or a legal entity. In Accession1 administrators draw every boundary from drafts the AI assistant makes from the context, and the tenant-level rules add which templates and roles the workspace may use inside it.
Break-glass access
Break-glass access is emergency access for an incident, granted quickly and expected to end with the incident. In Accession1 it is the emergency path of just-in-time elevation, granted to one identity instead of a shared emergency account. See least privilege with just-in-time access.
Catalog
A catalog is the approved set of resource types and roles that teams may provision for themselves. In Accession1 administrators decide which templates and roles each workspace may use, and each template available to a workspace is a catalog entry there.
Chargeback labels
Chargeback labels attribute a resource and the access to it to the cost center, project, or business unit that pays for it. In Accession1 they are labels under your own domain, set on a resource when it is provisioned and carried by identities from the identity provider. The record of who owns and holds what is the attribution. See IT self-service.
Cloud infrastructure entitlement management (CIEM)
Cloud infrastructure entitlement management is the category of tools that inventory the permissions identities hold in cloud platforms, find risky combinations and unused entitlements from activity logs, and recommend what to remove. It is the usage-driven way in the three ways to decide access. The tool doesn’t provision the access, so it infers the desired state from the current one. Accession1 designs the graph and pushes what it calls for to every target system, including cloud infrastructure.
Configuration drift
Configuration drift is the gap that opens between how a resource and the access to it are configured in a target system and how the organization’s current work calls for them to be. Detecting it takes a desired state to compare the current state against. It covers both the configuration of the resource, such as its settings and its labels, and the configuration of the access granted to it. It runs in both directions: from access too restrictive, which blocks work, to access too permissive, which leaves an opening for an attacker. It accrues one ticket at a time, because a ticket ends with the resource. The access the team then configures manually in the target system has no rule behind it and no record of why, and each change is made by someone with part of the knowledge. The result shows up as stale access, orphaned accounts, and resources nobody owns. See access reviews and audits and privilege creep.
Context
In Accession1, the context is the living fact base the AI assistant maintains about your organization, the facts no part of your tenant records on its own. It starts from public research and from what your team already knows. It records your geography, legal structure and regulatory scope, business model, and organizational structure and partnerships, along with the key and the values of each classification label you use. Administrators refine it from the organization’s institutional knowledge, and each fact carries its evidence state, inferred, observed, or confirmed, where confirmed means your team established it. Neither the context nor the access graph is written once. People refine the context as the organization changes, and every design decision changes the graph. A reorganization that redraws the graph calls for a context update too, which the AI assistant helps with. Between those moments the AI assistant keeps refining the context from changes in the organization, from sources such as audit logs, and proposes changes to the graph that administrators take or leave. See context-aware design.
Context-aware access control
Context-aware access control decides access from information about the situation of identities, resources, and the organization, instead of from one generic role model. In identity providers, context-aware and conditional access policies apply it to a single sign-in, from signals such as the device, the network, and the risk of the session. Accession1 carries it end to end. It is shifted left to the design of the access policies, which its context helps administrators and workspace members write, and it runs through every change after. Continuous reconciliation keeps the whole access graph consistent and pushes the valid resource configuration and access controls to each target system. Its context-awareness follows the three stages of a context-aware system: acquire the context, interpret it, and act on it. See context-aware design and access control for regulated industries.
Context-aware design
Context-aware design codifies your organization’s context, from regulation to institutional knowledge, with the AI assistant’s help, and designs the access graph from it, so every access decision is made where its requirements are understood. At tenant level, the AI assistant drafts workspaces, boundaries, and risk tiers from facts about your organization, and administrators approve every one of them. At workspace level, workspace members write their access policies the same way, inside those boundaries, with the AI assistant drafting from the context and from the graph that already exists. See context-aware design.
Continuous governance
Continuous governance is a record of who holds which role on which resource that is current on any day, instead of one rebuilt for each audit. In Accession1 it is what continuous reconciliation produces, because every grant it applies is an explicit record and every grant it revokes leaves that record. See continuous reconciliation.
Data sensitivity
Data sensitivity is how much harm unauthorized disclosure of a resource’s data would cause, the question of what it costs if this leaks. It is usually recorded on a four-level scale: public, internal, confidential, restricted. It is a different dimension from system criticality.
Data type
Data type is the regulatory scope of the data a resource holds, such as personal data, health data, or card data, independent of how sensitive it is. Data sensitivity decides who may reach a resource, and data type decides which regime applies once they do.
Desired state
Desired state is the resource configuration and the grants every target system should hold. In Accession1 it is the access graph administrators and workspace members design, and continuous reconciliation applies it so the current state matches, the declarative model Kubernetes made the standard for infrastructure. A tool that discovers the access graph from the current state has no desired state of its own, so it infers one with heuristics or rules, from systems that may already have drifted. See configuration drift and reconciliation.
Deterministic reconciliation
Reconciliation is deterministic when the same identity, resource, and policy state always produces the same grants. In Accession1 no AI inference sits in the path that grants access, so the result can be checked rather than trusted.
Dynamic access management
Dynamic access management derives access from current identity and resource state instead of from requests approved once. In Accession1 a grant exists while an access policy matches the labels on an identity and a resource, and it disappears when they stop matching. It is what context-aware design and continuous reconciliation produce together, and Accession1 delivers it and self-service provisioning as one flow, not two products. See continuous reconciliation.
Event-driven access
Event-driven access changes when something it depends on changes, rather than when someone files a request. In Accession1 a joiner, mover, or leaver recorded in the identity provider, a resource provisioned or relabeled, or an access policy edited sets off reconciliation, which grants and revokes in every target system. Compare request-driven access and usage-driven access.
Excessive permissions
Excessive permissions are the grants an identity holds beyond what its work requires. They were the norm for two reasons. People had a wide range of tasks, so restricting their access was hard, and access policies were designed far from the work, without insight into what it needs. They were always a residual risk, often within an organization’s risk tolerance while people held them, but an AI agent can exercise one a person would never have used, so they have to go before agents hold access. See AI agent access and privilege creep.
Grant
A grant is one role held by one identity on one resource. In Accession1 every identity an access policy matches gets an explicit grant that records the role assigned on that resource. A derived grant exists only while the access policy matches.
Human in the loop
Human in the loop is the industry’s phrase for a person approving what AI drafts or does before it takes effect. In Accession1 the AI assistant drafts the boundaries, the rules, and the access policies, administrators and workspace members approve every one, and the AI assistant never decides a grant, while reconciliation applies the approved graph deterministically. For an elevation, the elevation policy puts a person in the loop where the risk tier calls for one. See least privilege with just-in-time access.
Identity governance and administration (IGA)
Identity governance and administration is the category of tools that manage the lifecycle of identities and their access: joiners, movers, and leavers, access requests, access reviews, and audit. Most IGA tools manage access to systems that already exist and decide it from requests, certifications, and a baseline of birthright rules. Accession1 combines the capabilities of identity governance and administration (IGA) and IT self-service. It governs the access to the target systems it manages and provisions the resources in them, which governance tools leave to a ticket. It derives access from the access graph you designed on every change, so a certification becomes a review of that one graph. See IT self-service and access reviews and audits.
Identity lifecycle
The identity lifecycle is the sequence of changes an identity goes through, from joining to moving to leaving, and the access that has to change with each. For employees and contractors, the identity provider sends every change to Accession1 as a SCIM create, update, or delete request, so a changed attribute sets off reconciliation and every grant follows. For an agent identity Accession1 creates in the identity provider, Accession1 records the join, the move, and the retirement itself, and the agent follows the same lifecycle controls as a person. See joiners, movers, and leavers.
Identity provider
An identity provider is the system of record for identities, such as Microsoft Entra ID, Okta, or Google Workspace. It authenticates people and holds their attributes, such as department and location, but it doesn’t create resources in other systems or decide which role an identity should hold on them.
Identity security posture management (ISPM)
Identity security posture management is the category of tools that inventory every human and non-human identity across identity providers, clouds, and applications, score the risk of what each holds from configuration and activity, and recommend or automate remediation. It reads the access graph from logs and alerts, the usage-driven way in the three ways to decide access. Accession1 is the other way round. The graph is designed, and continuous reconciliation holds every target system to it, so posture is a result of the design rather than a report about it.
Information barrier
An information barrier keeps two units of one organization from sharing what one of them knows. A bank’s private side, advisory and lending, holds material non-public information. Its public side, research and trading, must never see it. Law firms call it an ethical wall, and regulators such as the SEC, FINRA, and MiFID II’s organizational requirements write information barrier. In Accession1 each side is a workspace administrators drew, or a subsidiary that must be kept apart in every respect is a tenant of its own. The people on each side arrive from the identity provider by department, so a move across the line ends the old side’s access. See regulated industries.
Joiners, movers, and leavers (JML)
Joiners, movers, and leavers are the three moments when an identity’s access has to change: when it joins, when it changes role or team, and when it leaves. Movers are the case most processes miss, because the transfer adds the new team’s access and the old team’s entitlements stay. Contractors pass through all three with every engagement, and AI agents with every project or task they are set up for, far more often than employees. See joiners, movers, and leavers.
Just-in-time elevation (JIT access)
Just-in-time elevation is Accession1’s just-in-time access: it grants elevated access for a bounded time and lets it expire on its own, instead of holding it permanently. In Accession1 it is one mechanism for an agent whose task needs a role beyond its standing access, a person who needs a privileged role for one change, and break-glass access for an incident. The approval is routed by risk tier. See least privilege with just-in-time access for the argument and self-service provisioning for the mechanism.
Label
A label is a key and a value on an identity or a resource, such as a department on an identity or acme.example/confidentiality: confidential on a shared drive.
Identities get theirs from the attributes the identity provider holds, resources from their template, their workspace, and your own classification, and access policies match on both.
Label taxonomy
A label taxonomy is the one set of label keys and values shared by identity attributes, access policies, and resources. Rules that match labels work only where the labels agree, so the taxonomy has to stay accurate as the organization changes.
Least privilege
Least privilege is the principle that every identity holds only the access its current work requires. It is easy to state and hard to keep, because access is granted for a reason and rarely removed when the reason ends. In Accession1 it is designed in the workspace, where the work is known, from unprivileged defaults, and just-in-time elevation covers the one change that needs a privileged role. See least privilege with just-in-time access.
Non-human identity (NHI)
A non-human identity is a tool, pipeline, service account, or AI agent that holds access. It needs a lifecycle like a person’s, because nobody onboards or offboards it otherwise, and in Accession1 it registers upstream in the identity provider and follows the same lifecycle controls as human identities. A tool, a pipeline, or a service account is usually restricted to one specific, static task, so least privilege is easier to design for it. An AI agent handles a wide range of tasks, so its access is as hard to predict as a person’s.
Offboarding
Offboarding is ending an identity’s access when it leaves the organization, the leaver in joiners, movers, and leavers. In Accession1 the identity provider deactivates the identity, and reconciliation revokes every derived grant across target systems, releasing the seats those grants occupied. See joiners, movers, and leavers.
Orphaned account
An orphaned account is access left in a target system after the identity behind it is gone, such as the account of a leaver or a service account whose project ended. It accrues when offboarding stops at the identity provider and the accounts, roles, and shares in each target system stay behind. In Accession1 every grant on the resources it manages comes from a rule and an identity, so deactivating the identity revokes them across target systems. See joiners, movers, and leavers.
Privilege creep
Privilege creep is how an identity’s permissions accrue past what its work requires: a birthright baseline by job title, roles granted whole because the narrower one took a project, and grants never revoked when the reason ended. The result is excessive permissions, a residual risk for people that an AI agent can act on. See AI agent access.
Provisioning
Provisioning is creating and configuring resources in target systems and the access to them. In Accession1 the resource and its access are provisioned as one, through the OpenTofu module behind each template and the access policy written for it in the same step, and reconciliation keeps the resource’s configuration and its grants as declared. Authentication stays with the identity provider, and Accession1 configures authorization in the target system. See self-service provisioning.
Provisioning bottleneck
The provisioning bottleneck is the ticket queue as the choke point where resources and the access to them can’t keep up with demand, so initiatives wait on it. It exists because the identity provider, the ITSM tool, and the target systems are separate tools, and a person connects them for every request, one reply at a time. A request ends with the resource, so the team’s access follows as additional requests. A faster queue leaves the bottleneck in place, because the ticket is still what decides. See IT self-service.
Reconciliation
Reconciliation is the process that brings the actual state of target systems in line with the desired state. In Accession1 it applies resources and grants, retries until they converge, and runs whenever identities, resources, or policies change, which makes continuous reconciliation one of its three core capabilities. See continuous reconciliation.
Request-driven access
Request-driven access changes when someone asks for it, through a ticket, a chat request, or a request a policy approves automatically. The grant that comes back is static, whether a person, an AI agent, or a policy answers. It stays in place when the reason for it ends. A time limit ends it on schedule rather than with its reason. Compare event-driven access.
Resource
In Accession1, a resource is a concrete provisioned instance in a target system, such as a Slack channel, a GitHub repository, or an AWS account. It carries labels, including the three classification labels, that access policies match on.
Risk tier
A risk tier is the one combined classification a workspace, template, or target system receives from its business function, regulatory scope, data sensitivity, system criticality, and workforce composition. It decides how tight a boundary is. It also decides who approves a just-in-time elevation: automatically, a workspace peer, or a tenant administrator.
Role
A role is a named level of access on a resource, such as viewer, contributor, or manager. In Accession1 each template maps its roles to the target system’s own permission model, so a workspace member asks for a role and the target system enforces its own permissions underneath.
SCIM
SCIM, the System for Cross-domain Identity Management, is a standard protocol for moving identities and their attributes between systems. It carries people from an identity provider into other systems, but it can’t create resources there or decide which role an identity should hold on one. In Accession1, SCIM runs between your identity provider and Accession1, and an OpenTofu module connects Accession1 to each target system.
Self-service provisioning
Self-service provisioning lets the people and agents inside a workspace provision resources and access without a ticket. In Accession1 workspace members provision the resources and access their work needs inside the tenant-level rules administrators set. See self-service provisioning.
Separation of duties (SoD)
Separation of duties, sometimes called segregation of duties, is the control that keeps the roles of one process apart, so the role that enters an invoice and the role that approves the payment are never held by one identity. In Accession1 the two roles come from separate rules on separate labels. The separation is a fact in the context, so the AI assistant keeps every policy it helps write inside it, and reconciliation enforces the result on every change. See access reviews and audits.
Standing access
Standing access is access that stays in place between uses, whether anyone needs it at the moment or not. Standing credentials are its riskiest form, because anything that obtains them, including a manipulated AI agent, can use everything they reach, so every one of them is attack surface. In Accession1 a privileged role that is needed for one task is a just-in-time elevation instead of standing access.
System criticality
System criticality is how much of the business stops when a system is unavailable or its state is tampered with, the question of what it costs if this goes down. A public website can be highly critical and hold no sensitive data at all, so it is a different dimension from data sensitivity.
Tenant-level rules
Tenant-level rules are what administrators decide each workspace may use: its boundary, so which identities it receives, and which templates and roles it may provision from. In Accession1 they are the ceiling self-service works below, because nothing a workspace member or agent creates reaches past them. See self-service provisioning.
Target system
A target system is a SaaS application or cloud service where an organization’s resources and access live, such as Google Drive, Slack, or Snowflake. Any target system with a Terraform provider can be integrated into the Accession1 catalog through an OpenTofu module.
Template
In Accession1, a template is a provisionable resource type backed by an OpenTofu module, with its roles mapped to the target system’s own permission model. Administrators decide which workspaces may provision from each template.
Tenant
In Accession1, a tenant is the root isolation boundary, and it holds the organization’s workspaces, identity sources, and templates. See SCIM and Terraform integrations for access.
Tool sprawl
Tool sprawl is the stack that grows one tool per problem, each with its own console, its own policy model, and its own idea of how the organization works, until integrating and maintaining the tools is work of its own. Agentic AI needs tools of its own, one per risk category, and each has to be configured to enforce the same access, in a policy format of its own. Instead of one more of them, Accession1 helps you define the one access graph and pushes resource and access configuration to any target system, so managing what you have and what you add stays sustainable. See identity and access management for the agentic organization.
Usage-driven access
Usage-driven access trims an identity’s access to what it was observed to use. Usage is a record of what an identity did, not of what its work requires. A new joiner, a new task, or a new agent starts with nothing to derive access from. Whatever is not used stays in place until the next trim. Compare event-driven access.
User access review (UAR)
A user access review, also called an access certification or recertification, is a periodic check that the people and non-human identities holding access to a system still need it. It usually means exporting entitlements from each system and asking a manager to certify them. See access reviews and audits.
Workspace
In Accession1, a workspace is the boundary for one business domain, structured along patterns such as business units, project teams, client or customer matters, or cross-enterprise joint ventures. It holds the resources, the access policies, and the catalog entries of that domain, and administrators decide where its boundary falls.
Workspace member
In Accession1, a workspace member is a person who works inside a workspace and provisions resources and writes the workspace’s access policies within the tenant-level rules administrators set.
Zero standing privileges (ZSP)
Zero standing privileges is the model in which no identity holds a privileged role between uses, and every privileged role is granted for a bounded time when it is needed. In Accession1 day-to-day work stays standing access while an identity’s labels match, and administrators can keep privileged roles out of every access policy, so such a role exists only as a just-in-time elevation. See least privilege with just-in-time access.