Modern organizations use dozens of business apps like Salesforce, Figma, GitHub, and more, each with its own permissions and access rules. Over 40% of employee requests to IT involve getting access to these apps, often requiring manual review, approval, and provisioning. Making sure your employees have the right access at the right time, securely and consistently, is one of IT’s biggest ongoing challenges.
Autonomous access provisioning, powered by Agentic IGA (Identity, Governance, and Administration), solves this by introducing a simple, structured way to define access policies and provisioning rules once, and allowing Atom to then enforce them intelligently. Atom can understand user intent, determine eligibility, manage approvals, and provision access automatically.
This guide breaks down the core concepts behind Agentic IGA — applications, access policies, entitlements, and provisioning methods — and explains how they work together to deliver consistent, automated access across your organization.
Why access provisioning is "hard" today
Most access requests happen when someone hits a roadblock.
A Sales rep trying to view a dashboard might ask for “Salesforce access.” Someone in IT must then figure out what level of access the user actually needs. An approver gets pulled in. Groups in Okta or Entra need updating. Someone has to follow up. Someone has to remember to remove access later.
Across hundreds of users and dozens of apps, this looks like:
Repeated "Can I get...?" requests
Back-and-forth between employees, approvers, and IT
Manual steps to give a user access
Spreadsheets or Slack messages to track permissions
Painful quarterly access reviews
A single access request isn't a big issue. But at scale, this is a significant operational and compliance burden. Agentic access provisioning introduces a clear model for defining access and automating all decisions that follow.
Core concepts of Agentic IGA
Agentic IGA relies on four simple but powerful concepts:
Applications | The tools your users need access to |
Entitlements | The specific types or levels of access within each application |
Access policies | The rules that determine who can get what, and when |
Provisioning methods | How the access is actually granted |
Each concept plays a distinct role in determining how access is evaluated and provisioned to a user.
Applications: The tools employees need to access
An application is any tool or platform employees use — Salesforce, Workday, GitHub, PagerDuty, Figma, ChatGPT, Cursor, or even a custom internal tool.
Applications matter because:
Each user needs access to a different set of apps to get their work done
Each app has its own permission model
Different teams need different levels of access
Ownership varies (Sales Ops owns Salesforce; Design owns Figma; Engineering owns GitHub, etc.)
Say, your organization uses Salesforce.
Who uses it: Sales updates opportunities and accounts, Finance reviews forecasts and revenue data, Customer Success checks customer health and support activity, and Marketing analyzes leads and campaign performance.
Permission model:
Salesforce uses a layered permission model where
- Profiles define core abilities like creating Leads, editing Opportunities, or running Reports.
- Permission sets add extra privileges like access to Reports & Dashboards, API Access, or Campaign Management.
- Sharing rules determine which teams can see which records, such as giving read access to all Opportunities.
Access levels:
Sales needs Standard User access to create, edit, and manage opportunities.
Finance may need Marketplace Access to access Reports & Dashboards, and APIs for revenue analysis.
Customer Success might get View-Only access to certain accounts and cases.
Marketing may require Campaign Management, Lead access, and reporting visibility.
Ownership: Usually owned and administered by the Sales Ops or Revenue Ops team, who define how profiles, roles, permission sets, and visibility rules are structured.
Entitlements: The specific access levels inside an application
An entitlement describes a specific level of access inside an application - essentially, what exactly the user will be able to do.
Employees never need “Salesforce access”. They need the right level of access to do specific things in Salesforce, like:
Read Only - View accounts, opportunities, and dashboards
Standard User - Create and edit leads, opportunities, and accounts
Marketplace/Reporting Access - Run reports and export data
Campaign Management - Manage campaigns and leads
Integration User - API-only access for system integrations
System Admin - Full configuration and administrative access
Why entitlements matter
Entitlements turn vague access requests into clear, enforceable units the system can understand. They allow Atom to:
Understand what the user is asking for
Map the request to the specific access level or set of permissions
Provision that access through the right method (add them to a group, trigger an approval, or hand off for manual action)
So, if your user says "I need to view customer records in Salesforce".
Atom maps this to an entitlement like Salesforce – Read Only, checks the policy, and provisions it.
Access policies: The rules that decide who gets what
If entitlements describe what access exists, access policies describe who can get that access and on what basis.
An access policy tells Atom:
Who is eligible?
Finance, Engineering, Contractors, All UsersWhich entitlements do they get?
Finance gets Marketplace/Reporting Access and Integration UserHow access is granted?
On request, it is either pre-approved or goes through an approval process.What additional information should Atom ask for?
Business justification, custom questions, etc.
For example, you create a Salesforce for Finance policy.
The policy might say:
Audience: Accounting and Finance
Entitlements: Marketplace/Reporting Access, Integration User
Grant type: Approval required
Approval policy: Reporting manager
Require business justification: Yes
This means anyone on the Finance team can request Salesforce access, but they need to justify it (which will be logged) and it must be approved by their manager.
Provisioning methods: How access is actually granted
Provisioning methods define how access is actually granted behind the scenes.
Provisioning could happen by:
Adding the user to an Okta group
Adding the user to an Entra (Azure AD) group
Creating a service request for manual provisioning
Why this matters
Two entitlements may sound similar, but they can be provisioned in very different ways. For example, your IT team may have set up Salesforce so that:
Standard User might be mapped to a fully automated Okta group
Integration User might require manual provisioning
The provisioning method ensures Atom knows precisely what steps need to be taken to provide access.
How Atom actually provisions access
Here's how all of these pieces come together when a user interacts with Atom:
The user expresses intent - “I need to view reports on Salesforce”
Atom identifies the application and checks the related policies
Is the user in the right segment?
Is approval needed?
Atom collects extra information if required
“Why do you need this access?”
Custom form questions
Atom retrieves the entitlements for that policy and provisions the access
Adds user to Okta/Entra group, or
Creates a service request for an IT agent
Logs the grant for future reference including the access and approval policies used, the justification, and the provisioning method.
Agentic access provisioning transforms access from a series of ad-hoc, repetitive, manual tasks into a predictable, governed, automated system. It reduces inconsistent decisions, enforces approvals and justification trails, simplifies audits, and strengthens compliance.
Once your setup is in place, Atom becomes the decision-maker, the workflow, the approver router, and the provisioning engine—all at once.
Learn more about setting up agentic access provisioning in Atomicwork.