AI in IAM: Automating the Enterprise Without Breaking Compliance
Where AI Actually Plugs Into a SailPoint ISC Implementation
Everything so far has been architecture-agnostic. This page is not: it is specifically about where, inside a real SailPoint Identity Security Cloud (ISC) implementation, an AI integration can live, and just as importantly, where it structurally cannot. Get this wrong and you either build something that can never work, or something that quietly bypasses the platform's own guardrails. All identifiers below (companies, tenants, systems) are fictional.
The platform, in six engines
ISC's own architecture already separates concerns the way this course has been arguing you should: identity data, access data, governance rules, provisioning execution, event-driven automation, and the API surface are six distinct layers. AI has exactly one honest home in this picture.
Where AI cannot go: cloud rules have no network
ISC's cloud-side rules (the Beanshell scripts that compute attributes, generate provisioning fields, or run before and after a provisioning plan) execute inside a sandboxed cloud context with no outbound network access at all. That is not a permissions setting you can change, it is how the execution environment is built. A rule like
AttributeGenerator, BeforeProvisioning, or IdentityAttribute physically cannot call an LLM API, an embeddings endpoint, or any HTTP service. If you have ever seen a slide claiming "just write a rule that calls GPT", that slide is wrong for anything running in ISC's cloud rule context.
Only two places in the platform can make an outbound network call at all: a Virtual Appliance running a customer-managed connector rule (WebServiceBeforeOperationRule, WebServiceAfterOperationRule, BuildMap, and similar VA-side rule types), or a Workflow's sp:http step. The VA path exists for connecting to on-prem source systems, not for calling AI services, and inherits a 120 second execution timeout that makes it a poor fit regardless. The workflow path is the one built for this.
Where AI actually goes: a workflow step
Workflows run outside the cloud rule sandbox specifically so they can call external systems: ServiceNow, a webhook, an email provider, or, just as easily, an AI service. The pattern is always the same shape: an event trigger fires (an access request submitted, a lifecycle state changed, a certification generated), a workflow step calls out to your AI service over sp:http, and the AI's output becomes an input to the next step, never a decision made and executed on its own.
As JSON, a minimal version of that pattern looks like this: an access request comes in, a workflow calls an AI service for a risk score and a draft justification, then hands both to a form the actual approver sees and can freely overwrite.
{
"name": "Access Request - AI Risk Draft",
"trigger": {
"type": "EVENT",
"attributes": {
"id": "idn:access-request-submitted",
"filter.$": "$.requestedItems[?(@.type == 'ACCESS_PROFILE')]"
}
},
"definition": {
"start": "trigger",
"steps": {
"trigger": { "actionId": "sp:trigger", "attributes": {}, "nextStep": "ask-ai" },
"ask-ai": {
"actionId": "sp:http",
"attributes": {
"url": "https://your-ai-service.example.com/v1/access-review",
"method": "POST",
"headers": { "Content-Type": "application/json", "Authorization": "Bearer {{secret}}" },
"body": {
"requestedFor.$": "$.trigger.requestedFor",
"requestedItems.$": "$.trigger.requestedItems"
},
"timeout": 20
},
"nextStep": "show-form"
},
"show-form": {
"actionId": "sp:create-form-instance",
"attributes": {
"formDefinitionId": "form-uuid",
"formInput": {
"riskScore.$": "$.steps.ask-ai.output.riskScore",
"draftJustification.$": "$.steps.ask-ai.output.draftJustification"
},
"recipients": [{ "recipientType": "IDENTITY", "id.$": "$.trigger.requestedFor[0]" }]
},
"nextStep": "end"
},
"end": { "actionId": "sp:terminate", "attributes": {} }
}
}
}Notice what the AI step does not do: it does not call sp:grant-access, it does not touch the provisioning plan, and its output never reaches a target system except by passing through a human-reviewed form first. That is the deterministic-core, AI-at-the-edges rule from earlier in this course, expressed in the platform's own step actions rather than as a slogan.
Try it yourself: map your own tenant's automation surface›
List every workflow, rule, and form currently active in a SailPoint ISC tenant you know (or imagine one for a hypothetical company). For each, classify it: cloud rule (no network, AI can never touch it directly), workflow (can call sp:http, AI can plug in here), or VA-side connector rule (technically can call out, but shouldn't be where you put AI logic). If the classification surprises you for something already running, that's worth a second look.
The governance layer already has AI built in
Before building anything custom, know what SailPoint ships natively: certification campaigns support a recommendationsEnabled flag that surfaces the platform's own access recommendations to reviewers directly in the certification UI, no workflow or external service required.
POST /v2024/campaigns
{
"name": "Q3 2026 Finance Access Review",
"type": "Manager",
"recommendationsEnabled": true,
"autoRevokeAllowed": false,
"filter": {
"type": "CRITERIA",
"criteria": {
"operation": "EQUALS",
"key": { "type": "IDENTITY", "property": "attribute.department" },
"stringValue": "Finance"
}
}
}This is the buy side of build vs buy from earlier: turn this on before building a custom certification copilot. Build the cross-system reasoning (the orchestrator that spans identity, PAM, ticketing, and your own decision history together) because that is what no vendor feature covers, not a better version of a review recommendation that already ships in the product.
The other integration point: an external agent against the API
Everything above lives inside ISC's own automation. The more flexible integration point is outside it entirely: an orchestrator (the same reference architecture from the previous page) that authenticates with OAuth2 client credentials, reads identities, access profiles, entitlements, and campaign data through the paginated REST API, reasons over that data with an LLM, and writes back through the same API, an access request here, a certification decision there, always through the platform's own approval and provisioning machinery rather than around it.
- Authentication: OAuth2 client credentials, tokens live roughly 12 minutes, cache and refresh rather than requesting a fresh one per call.
- Reading at scale: every list endpoint paginates (limit up to 250, offset, an X-Total-Count response header), never assume a single page holds everything.
- Writing: the same access-requests and certification endpoints a human-facing UI calls, an agent gets no special write path and no special exemption from approval workflows.
An agent that only ever calls the same public API endpoints a human user's UI calls is, by construction, unable to do anything the platform's own governance would not have allowed a human to do.
Summary: the AI integration map
| ISC layer | Can AI call out from here? | Use instead |
|---|---|---|
| Cloud rules (AttributeGenerator, BeforeProvisioning, etc.) | No, no network I/O in the sandbox | A workflow step upstream of the rule |
| VA-side connector rules | Technically yes, but 120s timeout and wrong layer for judgment calls | A workflow step, or a VA-triggered workflow |
| Workflows (sp:http) | Yes, this is the sanctioned pattern | Use it, gated by a form or approval step |
| Certification campaigns | AI already built in (recommendationsEnabled) | Turn it on before building your own |
| External orchestrator against the REST API | Yes, the most flexible integration point | The reference architecture from the previous page |