Access reviews User access reviews with the reason on record, AI agents included.

Certify the rules instead of the grants, and let every revoke take effect everywhere.

Try the demo Talk to the founder
The Contracts shared drive selected in the Legal workspace of Accession1, showing its labels confidentiality confidential, criticality tier-1, data-type pii, jurisdiction eu, and retention 10-years, its template google-shared-drive, 31 applied grants of the manager role, and the access policy rules that grant on it
A reviewer of the Contracts drive sees why it is sensitive, the 31 grants of the manager role on it, and the rule that produces them. The grants are what the rule produces today, not what was provisioned by ticket since the last certification, so the decision is about the rule.

Entitlement by entitlement Entitlements certified without a record of why they exist.

A certification asks whether the reason for each entitlement still applies. The entitlements belong to people, to the service accounts teams have always run, and now to agents, each provisioned in the target system itself with nothing recording the reason.

  1. The ticket Granted in January.
    Questioned in April.

    A ticket records the request, never when the access should end. An IT administrator grants a marketing analyst the editor role on the finance folder in Google Drive for one report, in January. The entitlement stands until the April certification asks the analyst’s manager, who can’t say why it exists and approves it.

    In Accession1 you decide once, when the rule is written, and the grant lasts while it matches.

  2. The manual share Shared from the drive.
    Nothing says why.

    A share made in the target system leaves no record of why. A team lead gets a shared drive by ticket and shares it with twelve people from the drive’s own sharing dialog. The next certification lists twelve editors and nothing about why any of them is there, so the manager approves all twelve.

    With Accession1 the team lead creates the drive and its access policy in one self-service step.

  3. Service accounts One job, one role.
    Cloned for every migration.

    A service account’s key outlives the project it was created for. A CI/CD pipeline’s service account has held one role on one cluster for years, and the reviewer approves it after a word with the team that owns the service. The service accounts cloned from it for one-off migrations hold the same role, and the engineer who created them has left.

    Accession1 helps you put a rule behind every pipeline’s grants, so they end when the migration does.

  4. Pilot agents Pilot ended in March.
    The token still works.

    Agents without an identity of their own share whatever credential works. A forecasting pilot ran three agents on one shared token with write access to the finance folder in Google Drive, because no single role fit their tasks. The pilot ended in March, and the token was active last week, so the reviewer approves it.

    Using Accession1 your team grants agents by rule, so their access ends with the pilot, used or not.

  5. Consultants Engagement ended.
    Still opens the drive.

    A review that goes by last use approves whatever is still used. A consultant got editor access to a client’s Google shared drive for a three-month engagement. A year later the consultant still opens it now and then, so the certification approves it.

    Accession1 allows you to end the consultant’s grant by ending the engagement in your identity provider.

How it works The reviewer approves the rule behind every grant.

  1. Step 1: Administrators design from the context

    Administrators draw the workspaces, boundaries, and risk tiers from your organization’s context, with the AI assistant’s help. What a reviewer used to know from memory is in the design.

  2. Step 2: Access policies produce every grant

    Workspace members write the access policies of their workspace, which match labels on identities with labels on resources. Each grant a person, a pipeline, or an agent holds has one rule behind it, and no grant exists without one.

  3. Step 3: Every system is configured from the same graph

    A target system is integrated through an OpenTofu module. Accession1 configures the drives, repositories, and warehouses a certification used to export entitlements from, all from the same graph.

  4. Step 4: Reviewers certify the access graph

    Reviewers read a rule, the identities it matches today, the resources it covers, and the facts in the context it rests on. The AI assistant answers questions such as who can read the Contracts drive and why.

  5. Step 5: Remediation takes effect everywhere

    A rule changed in the review sets off continuous reconciliation, which grants and revokes in every target system that day. So does a transfer, an ended engagement, or a relabeled resource, with no ticket per system.

Access certification runs on exports with no reason on record

Security and IT teams have run user access reviews (UAR) quarter after quarter. Managers, application owners, and data stewards approve or revoke each person’s roles, group memberships, and file permissions against the job. The result is filed as evidence under SOC 2, ISO 27001, or SOX.

Reviewers still catch real exposure, because they know the people behind the rows. What they find is access that outlived a transfer, a promotion, or a temporary grant. The review holds only as long as they have the time to read every row.

But the entitlements come from an export of each target system, and nothing in the export says why any of them exists. Each was provisioned there by ticket or shared by hand. So the certification asks whether the reason still applies without a record of what the reason was. It takes up a large share of an IAM team’s security work.

The entitlements belong to three kinds of identity. A manager can judge a direct report’s against the job, and a service account’s by checking with the team that owns it, because it was built for one static job. An agent fits neither kind, because its tasks are as broad as a person’s and a prompt injection can act with every permission it holds. And it joins, moves, and retires per project, workflow, or task. Between two certifications, stale entitlements stay in place for a quarter or a year, each an attack path for a compromised credential or a prompt injection. In an agentic organization, the agents a team adds between two certifications were never in the last export.

Accession1 is self-service provisioning of resources and access for people and AI agents. Every grant it applies comes from a rule your teams wrote, so a reviewer certifies rules, and a revoke reaches every target system.

Reviewer knowledge moves into the access design

A reviewer’s value is what they know: why Legal manages the Contracts drive, why a contractor may not, which duties finance keeps apart. The certification is the one moment that knowledge is applied, entitlement by entitlement, months after provisioning. In Accession1 it goes into the design instead. The context records how your organization works, and through context-aware design the AI assistant drafts the workspaces, boundaries, and risk tiers from it. The fact a reviewer would have caught in April is in the rule in January.

Workspace members write the access policies of their workspace the same way, in business terms, and the rules administrators set are the ceiling. A rule written that way says why every grant it produces exists. An AI agent is designed the same way, as an identity of its own in the workspace it works for, holding the roles the access policies there grant it and none of its owner’s excessive permissions. So a prompt injection acts with the reach of those roles rather than of a person, and the record shows what the agent holds apart from what its owner holds.

Review the rule, not the grant

In Accession1 every entitlement is a grant an access policy produced, and no grant exists without one. A reviewer reads a rule, the identities it matches today, the resources it covers, and the facts in the context it rests on, such as the regulation a business unit falls under. The AI assistant answers the questions along the way: who can read the Contracts drive, and which rule grants it. On the Contracts drive that is one question instead of 31 line items: should every employee in Legal manage a confidential drive holding personal data?

Most tools that show you an access graph discover it from audit log events, entitlement crawls, and activity, and infer the desired state from a current state that may already have drifted. In Accession1 the graph is designed, by administrators and workspace members from the context, and it is the desired state every target system is held to, the resource configuration and the access alike. So the reviewer reads the design every system follows, on an inventory current on the review date by construction, and a decision on it changes the systems, not a report.

The same rules cover people, service accounts, and agents, in every system an OpenTofu module connects, so a review of the graph covers every grant from one record, with no entitlement export. Whether the rules are right is still the reviewer’s decision, and it is the only one left.

Automated remediation, between reviews too

A revoke decision in a certification campaign becomes a ticket per target system, and that remediation is where campaigns slip. An auditor asks for evidence of it. In Accession1 a rule changed in the review changes the access everywhere in the next continuous reconciliation, so the remediation is applied rather than ticketed. The same reconciliation runs on every change between reviews, for a person, a pipeline, and an agent alike: a joiner, a mover, or a leaver, a resource provisioned or relabeled, or a rule edited. The transfer, the ended engagement, and the retired pilot that a certification used to find in April revoked their grants the day they happened. So the review starts from the graph, not from a hunt for stale entitlements.

Recent usage is not a reason to keep access

The usual way to shrink the certification is to right-size access to what identities were observed to use, often with AI recommending the removals. Identity security posture management (ISPM) and cloud infrastructure entitlement management (CIEM) tools approach least privilege this way. But usage shows what an identity did, not what it should be able to do. The forecasting pilot’s token passes a usage check, because one agent still calls it. The consultant passes too, a year after the engagement ended, having opened the drive last week. And a coding agent created this morning has no history at all, so a usage-driven process falls back to a ticket.

Recent use doesn’t justify itself. The access may have been meant to end months ago, but nothing took it away. And when nobody can say why an identity holds the access it used last week, revoking it is the step everyone avoids, out of fear of breaking something. So the usage report ends up defending the entitlements it was meant to remove.

In Accession1 the reason is the rule, and the change is the trigger. Every grant names the rule that produced it, so the question is never what the use was for but whether the rule is right. A rule that’s wrong is changed without guessing what depends on it. A new agent gets what its place in the graph calls for before it has used anything, so the restriction is in place before the agent is deployed rather than clawed back after. Least privilege is designed in the workspace and reviewed as rules, for people, service accounts, and agents alike, so no separate review tool is needed for agents.

Audit evidence from the current record

An external auditor asks who can approve payments in the ERP, the expense tool, and the card program. The answer used to take an IT administrator two weeks of exports and a spreadsheet. It was careful and correct, but out of date when it was sent. In Accession1 every grant is an explicit record of an identity, a role, and a resource, and continuous reconciliation keeps that record current. Every resource carries the classification labels your organization settled on, so the Contracts drive says why it is sensitive right next to who can reach it. Where SOX, PCI DSS, HIPAA, or ISO 27001 sets the certification cycle, the certification runs on that cycle. The evidence it produces is the rules reviewed and the grants they produce, with the requirement each rule rests on recorded in the context. Who can approve payments is then one rule and the identities it matches today.

What auditors ask about Where sensitive data actually lives.

Audit questions land on shared drives, CRM records, data warehouses, and source code as often as on a database. Accession1 manages grants in Google Drive, Microsoft 365, HubSpot, Snowflake, Databricks, GitHub, and AWS through OpenTofu modules, from identities in Microsoft Entra ID, Okta, or Google Workspace.

  • Microsoft Entra ID
  • Okta
  • Google Workspace
  • Google Drive
  • Snowflake
  • Databricks
  • GitHub
  • GitLab
  • Zendesk
  • HubSpot
  • Jira
  • Google Cloud
  • Kubernetes
  • Datadog
  • Grafana
  • PagerDuty

Takeaways Continuous access certification, with remediation in every system.

Designed, not discovered
A graph discovered from audit logs shows the current state, and what it should be can only be inferred. The access graph in Accession1 is designed from your context and drives the access, so a reviewer reads the design every system follows.
No grant without a rule
A grant exists only while the rule behind it matches the labels on both sides, for a person, a service account, or an agent, so a review of the graph covers every grant.
Remediation applied everywhere
A revoke decided in the review reaches every target system without a ticket per system. A transfer or an ended engagement ends a grant the day it happens, between certifications.
Deterministic
The same identity, resource, and policy state always produces the same grants. An auditor can check the result instead of trusting it.

Continuous governance The record stays current between audits.

Continuous reconciliation keeps every grant true to the rules as identities, resources, and access policies change, so the record an auditor reads is the one your target systems match on that day, not the state of the last export. Because every system is held to the graph the review reads, configuration drift is addressed proactively, on the next change, instead of accumulating until the review.

How continuous reconciliation works

Frequently asked questions IGA access review FAQ

What is a user access review?

It is a periodic certification, also called access recertification, that the human and non-human identities (NHI) holding access still need it and are still authorized to have it. Usually it means exporting entitlements from each system and asking managers to approve or revoke each one. With Accession1 the review moves to the one access graph, because every entitlement is a grant an access policy produced and reconciliation keeps current.

How do access reviews work for AI agents?

An agent fits neither row a review knows. Its tasks are as open as a person’s, but it can exercise any permission it holds, and it joins, moves, and retires on a lifecycle of its own. Teams add agents at a pace no certification cycle meets, so what keeps an agent within its permissions is a rule that exists before the agent is added. In Accession1 an agent’s grants come from the rules of its place and purpose, under an identity of its own and narrower than its owner, and the reviewer certifies those rules. Reconciliation ends them when the labels stop matching or the owner moves on, and elevated access for one change is a just-in-time elevation that expires. AI agent access carries the full argument.

How does a review handle service accounts?

A review treats it as a kind of its own. An engineer creates a service account, not the HR record, and it supports a product or service a team owns. A manager can usually understand its need by checking with that team, and because it was built for one static job, its access could be scoped to that job. What slips is the end: its long-lived credentials sit in a script or a config file after the project ends, and the engineer who created it may have left. In Accession1 a service account is an identity with a rule behind its grants and an owner recorded, like an agent. The migration that ends in the identity provider deprovisions the accounts it ran on, and the reviewer reads the rule instead of the key.

What happens to access between two reviews?

Without a rule behind it, nothing happens to it. An entitlement provisioned by ticket or by a manual share stands until the next certification finds it. With a quarterly cycle, a leaver’s account that was never deprovisioned, a consultant’s drive, or a pilot’s token stays open for three months, and with an annual one for a year. In Accession1 the change that ends the reason is what revokes the grant, that day, everywhere: a leaver deactivated, an engagement ended in the identity provider, or a pilot’s labels removed.

Would reviewing monthly instead of quarterly fix it?

It shortens the window and multiplies the work, and the certification is still a point-in-time attestation. What limits it is the trigger, not the cycle: a certification fires on a calendar, and access goes stale on a change. In Accession1 the change sets off reconciliation, so the access follows the rules between any two dates you might pick. The review that remains asks whether the rules are right.

Would reviewing only the changes since the last review fix it?

It cuts the line items, and the reviewer still approves or revokes entitlements provisioned weeks ago by tickets and manual shares that nothing records a reason for. The delta is smaller and as hard to judge. In Accession1 the changes since any date are rules written or edited and facts that changed, such as a joiner, a mover, or a relabeled drive, and reconciliation has already applied them. So a review reads the access policies that changed and the facts behind them, instead of the grants they left.

Our regulation requires a review every quarter. Does that change?

The obligation stays, and only what the review reads changes. SOX, SOC 2, PCI DSS, HIPAA, and ISO 27001 ask for evidence that access is reviewed and that duties are segregated. The controls behind them ask for timely change and revocation rather than approval alone: CIS Controls 5 and 6, NIST SP 800-53 AC-2 and AC-6, and ISO 27001 A.5.15 and A.5.18. Reconciliation does that on the day of the change. Accession1 doesn’t decide whether you meet any of them. The context records which requirement applies to which legal entity and category of data, and every rule rests on one of those facts. Continuous reconciliation keeps every target system true to the rules, so the quarterly certification reviews the one access graph, its access policies and the grants they produce, and the evidence is the state of that day. Access control for regulated industries shows how a sector’s requirements enter the design.

Does Accession1 support privileged access reviews?

Yes, as part of the same review. A privileged role held as standing access comes from a rule the reviewer reads like any other. One granted for a single change is a just-in-time elevation, recorded with its reason, its approver, and its end date. So the review reads the privileged rules and the elevations of the period instead of every administrator account in every system.

Does Accession1 run certification campaigns?

It turns them into a review of the one access graph. A campaign asks managers to approve or revoke entitlements provisioned months ago, one by one, because nothing else revisited them. In Accession1 every grant is produced by an access policy and continuously reconciled, and the graph is redesigned with the context whenever the organization changes. So a certification reviews the access policies and the facts behind them on that graph, plus the exceptions, which are just-in-time elevations that expire on their own.

Is Accession1 an identity governance (IGA) tool?

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. Why the two belong in one product is the argument of IT self-service.

Why not trim access to what people actually use?

Usage shows what an identity did, not what it should be able to do. A pilot token still in use, or a consultant who opened the drive last week, passes a usage check and is still wrong. A new agent has no history at all, so its access falls back to a ticket. Accession1 derives access from a graph your people designed, inside boundaries administrators drew, and no AI recommendation sits in the path.

Don't ISPM and CIEM tools already give us an access graph?

They discover one, from audit log events, entitlement crawls, and activity, and it is a useful inventory. But it is the current state, and a tool that doesn’t provision the access has no desired state to compare it with. It infers one with heuristics such as unused permissions or peer groups, from systems that may already have drifted. Monitoring it continuously instead of quarterly finds the drift sooner without preventing it. In Accession1 the access graph is designed by administrators and workspace members from the context, and it is the desired state, because continuous reconciliation holds every target system to it. So the review reads the design every system follows, and a change to it is applied everywhere. Audit logs still have a use: the AI assistant reads them to refine the context and proposes changes to the graph that administrators take or leave.

Don't our audit logs and monitoring tools already answer the auditor?

They tell you what an identity did, and you need them. But none of them says what access should be, and that’s the question an auditor starts with. Accession1’s record says what access is: which rule produced each grant, and which fact in the context the rule rests on. The AI assistant answers questions about that record without changing it.

Can we see who holds licensed seats?

Yes, from the same record. A grant is one role on one resource, and where that role occupies a seat in Zendesk, GitHub, or HubSpot, the record shows who holds it, from one API on any day and without an export. Accession1 doesn’t count or assign licenses. It ends the grant, and with it the seat, when the reason for it ends.

Does Accession1 enforce separation of duties?

As rules, continuously. The role that enters an invoice and the role that approves the payment come from separate rules on separate labels. The separation is a fact in your context, so the AI assistant keeps every access policy it helps write inside it, and reconciliation enforces the result on every change. Which duties to separate stays with you and your auditors.