Product SCIM and Terraform integrations for access

Connect your identity provider once, and add each system your teams use with a module instead of a project.

Try the demo Talk to the founder
The Contracts shared drive selected in an Accession1 Legal workspace, showing its labels, its google-shared-drive template, its grants, and the access policy rules that grant on it
The Contracts shared drive was provisioned through the google-shared-drive module, and 31 grants of the manager role are applied to it. Every target system is integrated the same way.

Why integrations stall Every new system is an integration project.

Your IT team connects each tool by hand and keeps every connector working.

  1. People Users pushed by SCIM.
    Roles set by hand.

    SCIM can sync a person and their groups into each app. But someone still decides which group gets which role. Okta provisions a new support hire into Zendesk over SCIM, and a team lead then sets the role and queue access by hand.

    With Accession1 your access policies set the roles from the attributes your identity provider sends.

  2. Agents A new agent on Monday.
    A borrowed login by Friday.

    Creating an account for a new agent means a ticket to the identity team. An operations team adds an AI agent that reads Salesforce cases and updates SAP orders, and a team lead lends it a personal login while the ticket waits.

    In Accession1 the team adds the agent to its workspace, and its identity is created in Microsoft Entra ID.

  3. The long tail No connector on the list.
    A spreadsheet instead.

    An internal billing tool and a niche scheduling app have no connector in the access tools the company runs. A finance manager keeps their access lists in a spreadsheet and updates them when someone asks.

    Using Accession1 your team integrates any system with a Terraform provider through a small module.

How they connect Every identity and every system on one access graph.

  1. Step 1: SCIM provisioning from your identity provider

    Point Microsoft Entra ID, Okta, or Google Workspace at Accession1 over SCIM. Employees and contractors arrive with their attributes as labels.

  2. Step 2: An identity of its own for every AI agent

    An agent you add to the tenant, a workspace, or one person gets an agent identity in your identity provider’s native feature, such as Microsoft Entra Agent ID. The people at that level are its owner, and its placement gives it a baseline one level below theirs.

  3. Step 3: Resource and access provisioning through OpenTofu modules

    A module per target system provisions resources and configures access in it. Anything with a Terraform provider can be integrated, and administrators decide which workspaces may use it.

  4. Step 4: Your coding agent drafts the module

    With the Accession1 skill, it drafts each module and keeps it current as the provider changes. Your team reviews every change, so a new integration takes a request and a review.

SCIM provisioning and agent identities

Accession1 is self-service provisioning of resources and access for people and AI agents. Through a module per target system, it provisions resources and grants access there, and keeps both in line on every change. It sits between your identity provider and your target systems. For people, Microsoft Entra ID, Okta, or Google Workspace sends SCIM requests to Accession1, and attributes such as department, team, and location become the labels access policies match on. Employees usually reach the identity provider from an HR system and contractors from an administrator. Either way, every joiners, movers, and leavers (JML) change arrives as a SCIM request, so no particular HR suite is required. For AI agents, Accession1 integrates with the identity provider’s native agent identities, such as Okta for AI Agents, so each agent authenticates as itself and has an owner. Agents then get grants from the same access policies as the people they work with.

Automated provisioning in any system with a Terraform provider

For each system your teams use, a module provisions resources and configures access in one step. It declares a resource type, such as a shared drive or a support queue, and maps each role to the system’s own permissions. A workspace member grants the manager role in an access policy, and the system enforces its own permission model underneath. Because the major cloud platforms, developer tools, and identity providers already have a Terraform provider, an integration is a module on top of a provider that exists, not a connector anyone has to build. Administrators decide which workspaces may use each module, and access policies grant its roles to the people and agents whose labels match.

Infrastructure as code for every integration

A module is small, so your own AI coding agent can draft it and keep it current as the provider changes. Your team reviews each change like any other infrastructure code. The Accession1 skill teaches your coding agent how Accession1 modules are built. Internal tools and the long tail of niche apps are integrated the same way, without changes to Accession1 itself.

What it means for IT and security

In an agentic organization, teams add agents to accelerate specific tasks, and each one needs an identity and access in several systems at once. With one SCIM connection and a module per system, every system follows the same access policies. Adding the next system takes a module, not a quarter. On any day, one query answers who and what can reach every system, bought or built, and why.

Your stack Anything with a Terraform provider.

The Terraform Registry lists thousands of providers for identity, collaboration, CRM, payroll, finance, and cloud. Much of what your teams use already has one.

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

Takeaways Each new system joins under the same access policies.

Your identity provider stays in charge
Your identity provider remains the system of record for identities. Accession1 takes its changes over SCIM and never replaces it.
One deactivation, every system
When the identity provider deactivates an identity, Accession1 revokes every grant derived for it across target systems.
No synthetic roles
Each module maps its roles to the target system’s own permission model, and Accession1 never creates roles a target system can’t enforce.
Deterministic
The same identity, resource, and policy state always produces the same grants. No AI sits in the path that applies them.

From module to access Each module becomes a catalog entry.

Once a target system has a module, workspace members provision from it inside the rules administrators set, and the access comes with the resource.

Self-service resource and access provisioning

Frequently asked questions SCIM and Terraform integrations FAQ

What do the SCIM and Terraform integrations do?

SCIM brings people and their attributes from your identity provider into Accession1. Terraform providers, through OpenTofu modules, let Accession1 provision resources in your target systems and apply grants to them. Agent identities are created through your identity provider’s native agent identity feature.

What is an agent identity?

An agent identity is the dedicated identity an AI agent gets in your identity provider, so it never borrows a person’s login or a shared token. Identity providers now offer it natively, such as Microsoft Entra Agent ID or Okta for AI Agents, and Google Cloud uses a service account. Accession1 integrates with those features, creates one for every agent someone adds, and records who owns it. Why an agent needs an owner and less than its owner holds is the argument of AI agent access.

Which target systems can Accession1 manage?

Any target system with a Terraform provider, which covers the major cloud platforms, developer tools, identity providers, and much of SaaS. For a system without one, such as an internal tool, writing a provider first adds effort, but it is still a well-documented job your coding agent can help with.

Can Accession1 provision access in SaaS apps without a SCIM connector?

Yes. In Accession1, SCIM runs between your identity provider and Accession1, and keeps the identities current. Between Accession1 and each target system sits a module on that system’s Terraform provider, which works with the app’s own API. So Accession1 provisions the resource and grants the role whether or not the app supports SCIM, where an app’s own SCIM connector would only create the user and leave the role to someone.

How much work is a new integration?

A module is a small file that declares a resource type, its roles, and how each role maps to the system’s own permissions. Your AI coding agent drafts and maintains it with the Accession1 skill, and your team reviews it.

From the blog Posts on self-service provisioning and non-human identities.

All posts