Introduction
The explosion of enterprise AI adoption has created a governance blind spot. Companies are deploying large language models like Claude across their organisations—embedding them in customer service, financial analysis, content creation, and decision support workflows. Yet most enterprise deployments lack any formal identity governance and administration (IGA) framework to control which users can access which models, what data those models can consume, and what actions they can take on behalf of users.
Linx Security’s integration with Claude’s Compliance API represents an early attempt to bridge this gap: embedding compliance and identity governance directly into the AI execution layer, ensuring that AI systems operate within approved guardrails and log their actions for audit.
The Problem: AI Systems Lack Identity Governance
Traditional enterprise applications have identity governance built in. A user authenticates, their identity is verified against a directory, their permissions are checked against a role-based access control (RBAC) matrix, and their actions are logged. This is standard IGA practice.
But AI systems in most enterprises operate outside this framework. A user gets access to Claude (or similar models) based on a blanket decision: either they can use it or they can’t. Once they have access, there’s no granular governance over what the model can do. Can this user prompt the model to analyse sensitive financial data? Can the model access customer records on their behalf? What happens if the user asks the model to perform an action that violates policy?
The compliance problem is equally severe. When a user interacts with an AI model, does that interaction get logged for audit? Are prompts and responses retained? Can the organisation prove compliance with data protection regulations when sensitive data is processed by an external AI system? In most cases, the answer is no.
Key Points: Identity Governance for the AI Layer
1. API-Based Compliance Integration
AI platform providers must expose compliance APIs that allow enterprise IGA systems to enforce governance decisions in real time. Before a user’s prompt is processed by an AI model, the IGA system should verify that the user has permission to interact with that model, that the prompt doesn’t contain prohibited data types, and that the requested action aligns with their role and permissions.
2. Granular Model and Data Access Controls
Enterprise identity governance must extend to AI models themselves. Rather than granting blanket access to all models, organisations should define which users can access which models, which datasets those models can analyse, and what actions they can perform. A financial analyst might have access to a Claude instance trained on financial data but not customer data. A customer service representative might have access to Claude but with guardrails preventing financial transactions.
3. Audit and Logging of AI Interactions
Every user-model interaction should be logged and auditable through the IGA system. This includes the user’s identity, the time of access, the content of prompts, the model’s response, and any actions taken based on that response. This creates an audit trail suitable for compliance reviews and incident investigation.
4. Compliance-First AI Governance Frameworks
Organisations should treat AI systems as another application layer requiring identity governance and administration controls. Define SOD policies for AI (can a single user both request and approve an AI-generated financial analysis?), establish access review cycles, and monitor for anomalous usage patterns that might indicate misuse or compromise.