SailPoint and Claude compliance API: AI platform identity governance

At a glance

What this is: SailPoint has tied Claude Compliance API connectivity to identity governance so enterprises can manage Claude Enterprise users, roles, and AI agents under a single control model.

Why it matters: This matters because IAM teams now have to govern AI platform access as an identity problem, not only as an application integration problem, especially when AI agents and shadow AI expand the attack surface.

Context

AI platform identity governance means applying identity controls to the people, service objects, and agents that access a generative AI environment, rather than treating the platform as a standalone tool. In this case, the governance question is whether Claude Enterprise access can be supervised with the same discipline used for critical business systems.

SailPoint positions the Claude Compliance API connector as a way to centralise visibility and governance for Claude Enterprise, including users, groups, roles, and AI agents. The underlying problem is broader than one integration: enterprises are now discovering that AI usage creates its own unmanaged identity layer unless it is brought into IAM and lifecycle controls.

Shadow AI is the governance gap that appears when AI tools and agents are adopted faster than they are inventoried, reviewed, and constrained. That gap is already familiar to identity teams in other forms of NHI sprawl, but AI platforms make it harder because usage, context, and permissions can shift inside a live session.

Key questions

Q: What breaks when AI agent data access is not tied to identity governance?

A: What breaks is accountability. If access is not tied to identity governance, security teams cannot tell whether the agent was over-entitled, whether a policy failed, or whether the data movement was expected. That makes incident response, compliance evidence, and entitlement review much harder to perform with confidence.

Q: Why do AI tools create new access governance risks for security teams?

A: AI tools often sit close to mail, data, and response systems, which makes their permissions unusually broad. The risk is not only misuse by attackers, but also scope creep as teams add more data, actions, and integrations without revisiting ownership, approval, and revocation. That is a classic identity governance failure.

Q: How should security teams govern Claude use when employees, AI agents, and non-human identities all act through the same environment?

A: Security teams should treat Claude as part of the wider identity and access fabric, not as a standalone app. Governance should cover the human user, the agentic identity, the underlying non-human credentials, and the connected tools those identities can reach. The practical goal is to maintain visibility, enforce access controls, and preserve auditability across both Claude Enterprise and Claude Platform.

Q: What should IAM teams do when access reviews do not reflect live AI usage?

A: Use access reviews for entitlement hygiene, but pair them with runtime monitoring and contextual policy for AI sessions. If reviews only see historical access, they miss the moment where the AI platform actually exercised privilege, which is where the real governance decision happened.

How it works in practice

Claude Compliance API and identity governance for AI platforms

A compliance API exposes account, role, and usage signals that identity governance tools can ingest and reconcile against policy. In this case, the key technical change is not just visibility into who has access, but whether AI platform users, groups, and roles can be governed through the same entitlement lifecycle used for enterprise applications. That matters because AI platforms tend to accumulate access paths faster than traditional systems, especially when teams create agents, assistants, or embedded workflows around them. Once those identities are present, the governance model must distinguish between human users, delegated roles, and machine-like access patterns.

Practical implication: map Claude Enterprise entitlements into your identity governance workflows before access sprawl becomes normalised.

Why AI agents behave like non-human identities in governance models

AI agents are non-human identities when they act on behalf of the enterprise through accounts, roles, or delegated permissions. They differ from standard service accounts because their usage may be contextual, variable, and tied to a live interaction rather than a fixed batch process. That creates a governance problem around inventory, ownership, and acceptable use, because the same agent may be invoked in multiple business contexts without a stable human operator at the keyboard. The article’s emphasis on a single agent registry reflects this identity challenge: if the agent is not discoverable, it is not governable.

Practical implication: classify AI agents as governed NHI objects with explicit ownership, lifecycle, and access scope.

Adaptive identity and contextual authorisation in AI sessions

Adaptive identity uses context such as who is requesting access, what they are doing, when the request occurs, and why it is happening to decide whether access should continue. For AI platforms, that approach is more suitable than static access review alone because session behaviour can change quickly, and the same actor may touch multiple systems in one workflow. This is where traditional periodic certification becomes weak: by the time a review runs, the relevant activity may already be complete. The control objective shifts from asking whether access existed to asking whether access was appropriate at the moment it was used.

Practical implication: pair periodic recertification with runtime policy signals that can judge AI platform access in context.

NHI Mgmt Group analysis

AI platform governance is now an identity governance problem, not a niche integration task. Once Claude Enterprise access is governed through a compliance API, the control plane shifts from informal app administration to enforceable entitlement management. That matters because AI platforms introduce users, roles, and agents that can all create access risk if left outside lifecycle controls. Practitioners should treat AI platform access as part of the core IAM estate, not a separate AI pilot.

Shadow AI is the named concept that best captures the real governance failure here. Shadow AI is not simply unused technology, but AI access and agent activity that security teams cannot inventory, review, or bound. The important consequence is that visibility must precede policy enforcement: if an organisation cannot see who or what is operating inside the AI platform, every downstream control becomes partial. Practitioners should regard discoverability as the first condition of governance.

Non-human identity sprawl now extends from workloads into AI-driven work execution. The article reflects a wider shift where identities are no longer only human users and service accounts, but also AI agents that can participate in enterprise workflows. That expands the scope of NHI governance because ownership, authorization, and review logic must now handle entities that may act dynamically across tasks. Practitioners should fold AI agents into the same governance discipline used for other machine identities.

Zero-standing privilege becomes more relevant when AI platforms can create ephemeral but powerful access paths. A platform can expose a role or agent only when it is needed, but that still requires strong authorization logic, ownership, and revocation discipline. The security issue is not just whether access is permanent, but whether access is bounded tightly enough that AI usage cannot silently expand. Practitioners should measure AI platform entitlements for privilege persistence, not just for count.

Agent registry discipline: The article’s single registry idea is a useful marker for the category because governed AI access depends on knowing which agents exist, what they can do, and who owns them. Without that registry, recertification and policy enforcement are operating on incomplete data. Practitioners should make registry completeness a governance metric, not an administrative afterthought.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity governance is moving from account review to actor review. AI platforms force IAM teams to look at the full set of identities involved in execution, including users, roles, and agents. The governance question is no longer whether an application is approved, but whether every actor inside it is discoverable, owned, and reviewable.

Shadow AI is a lifecycle problem as much as a discovery problem. If AI agents can be created, reused, and embedded in workflows faster than governance processes can enumerate them, the risk is not only invisible usage but persistent unmanaged access. That means discovery, ownership, and offboarding need to work together for AI identities just as they do for other NHIs.

For practitioners

• Inventory AI platform identities Map Claude Enterprise users, groups, roles, and agents into your identity governance inventory so AI access is not managed outside the main control plane.
• Define ownership for every agent Assign a business and technical owner to each Claude AI agent, including delegated access paths and approval responsibility for changes.
• Fold AI access into recertification Add Claude platform entitlements to access review cycles, but supplement them with event-based review for high-risk roles and agent activity.
• Set contextual access rules Use risk context such as user role, request purpose, and session activity to decide when Claude access should be allowed or constrained.
• Track shadow AI as an NHI issue Treat unmanaged Claude usage as non-human identity sprawl and route it through the same discovery, approval, and offboarding process used for other machine identities.

Key takeaways

• AI platform access now sits inside the identity governance problem space, because users, roles, and agents all need the same lifecycle discipline.
• The main risk is unmanaged AI usage, where shadow AI and agent sprawl outpace visibility and policy enforcement.
• Security teams should bring Claude Enterprise entitlements into normal IAM controls, then add contextual and runtime checks for high-risk activity.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• AI Platform Identity: An AI platform identity is the set of user, role, and agent entitlements that determine how a platform can be accessed and used. For governance teams, it must be tracked like any other non-human identity because it can create real business access and audit obligations.
• Adaptive Identity: An identity governance approach that changes access decisions as context changes. Instead of relying only on fixed review cycles, it uses current risk, role, behaviour, and application sensitivity to decide whether access should continue, be reduced, or be revoked.
• Agent Registry: An agent registry is a central catalog of sanctioned and shadow AI agents, including their identities, permissions, and lifecycle state. Its value depends on whether it feeds broader governance, because a registry without telemetry, ownership, and offboarding can become another silo.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.