Identity and Access Management for Models and Data

1. Why Identity and Access Management (IAM) for Models and Data Matters

In traditional IT security, Identity and Access Management (IAM) protects systems, applications, and databases. In the AI era, the most valuable and most vulnerable assets are different: trained model weights, training and fine-tuning datasets, feature stores, vector databases, system prompts, inference endpoints, and the MLOps pipelines that move models from experimentation into production. If any of these can be read, written, or executed by the wrong identity, the consequences include model theft, data poisoning, privacy breaches, regulatory violations, and loss of trust in AI outputs.

ISACA places this topic in the AI Technologies and Controls domain of the AAISM (Advanced in AI Security Management) because IAM is the foundational preventive control for AI systems. Almost every AI-specific threat – model extraction, poisoning, prompt injection leading to privilege misuse, insider exfiltration of weights, unauthorized model promotion to production – is either enabled or prevented by how well identities and access rights are governed.

Key reasons the topic is critical:
• Models are intellectual property – a stolen weight file can represent millions of dollars of compute and years of proprietary data.
• Training data is a poisoning vector – anyone with write access to training or fine-tuning data can silently alter model behaviour.
• AI introduces new non-human identities – pipelines, agents, orchestrators, and model-to-model calls all need identities, credentials, and scoped permissions.
• Regulations demand it – privacy laws (GDPR, CCPA), the EU AI Act, sector regulations, and frameworks such as NIST AI RMF and ISO/IEC 42001 all expect demonstrable control over who can access data and models.
• Accountability requires traceability – audit logs tied to unique identities are the only way to prove who trained, modified, approved, or queried a model.

2. What IAM for Models and Data Is

IAM for models and data is the set of policies, processes, and technologies that ensure only authorized human and non-human identities can access, modify, deploy, or invoke AI models and the data that feeds them, only to the extent required by their role, and that every access is authenticated, authorized, logged, and reviewable.

It extends classic IAM concepts across the full AI lifecycle:

Assets to protect
• Raw, curated, labelled, and synthetic training data
• Validation and test datasets (tampering here hides poor or malicious model behaviour)
• Feature stores and embeddings / vector databases used for retrieval-augmented generation (RAG)
• Model artefacts: weights, checkpoints, architectures, configuration files, system prompts, guardrail rules
• Model registries and artefact repositories
• Training, fine-tuning, and evaluation pipelines (CI/CD for ML, often called MLOps or LLMOps)
• Inference endpoints and APIs, including third-party foundation model APIs
• Keys, tokens, and secrets used by notebooks, pipelines, and agents
• Logs, prompts, and outputs (which may contain sensitive data)

Identities involved
• Human identities: data engineers, data scientists, ML engineers, prompt engineers, reviewers/approvers, auditors, business users, external contractors
• Non-human identities: service accounts, pipeline runners, orchestration tools, AI agents acting on behalf of users, model-to-model (tool-calling) interactions, third-party integrations

Core principles applied
• Least privilege – grant the minimum rights needed; data scientists usually need read access to curated data, not write access to production models.
• Need-to-know – access to sensitive training data (PII, PHI, financial records) is restricted based on classification.
• Separation (segregation) of duties – the person who trains a model should not be the sole approver who deploys it to production; those who label data should not be able to alter evaluation results.
• Zero trust – never trust based on network location; always authenticate and authorize every request to a model endpoint or data store.
• Defence in depth – IAM works alongside encryption, model signing, integrity checks, and monitoring.
• Accountability – unique identities, no shared accounts, immutable logs.

3. How It Works – Controls Across the AI Lifecycle

a) Identity lifecycle management (Joiner – Mover – Leaver)
Provision access when someone joins an AI project, adjust it when roles change (for example, a data scientist moving to a governance role), and revoke it promptly on exit. Orphaned accounts and lingering API keys in notebooks are a leading cause of AI data leakage. Non-human identities also need a lifecycle: a pipeline service account should be decommissioned when the pipeline is retired.

b) Authentication
• Single sign-on (SSO) with multi-factor authentication (MFA) for all human access to data platforms, notebooks, model registries, and MLOps consoles.
• Strong, short-lived credentials for non-human identities: OAuth 2.0 / OpenID Connect tokens, workload identity federation, mutual TLS (mTLS) between services, rather than static long-lived API keys.
• Secrets management: keys and tokens stored in a vault, injected at runtime, rotated regularly, never hard-coded in notebooks or committed to repositories.

c) Authorization models
• Role-Based Access Control (RBAC) – roles such as Data Steward, Data Scientist, ML Engineer, Model Approver, Model Consumer, each mapped to permissions on datasets, registries, and endpoints.
• Attribute-Based Access Control (ABAC) – fine-grained decisions based on attributes such as data classification, project, geography (data residency), time, or device posture. ABAC is especially useful for datasets with mixed sensitivity.
• Policy-Based / Purpose-Based Access – access to personal data allowed only for the approved processing purpose, supporting privacy-by-design and purpose limitation.
• Row-, column-, and field-level controls plus masking, tokenization, or differential privacy so that training can proceed without exposing raw sensitive values.

d) Privileged Access Management (PAM)
Administrative access to model registries, production inference infrastructure, GPU clusters, and data lakes should be governed by PAM: just-in-time (JIT) elevation, approval workflows, session recording, and automatic expiry. Changing a production system prompt or guardrail configuration is a privileged action and should be treated as such.

e) Protecting training and fine-tuning data
• Classify data before it enters the pipeline; classification drives access rules.
• Restrict write access tightly – write access equals poisoning capability.
• Maintain data provenance and lineage so each dataset version is attributable to an identity and an approved source.
• Segregate environments (development, test, production) with separate identities and no implicit trust between them.

f) Protecting model artefacts
• Store models in a controlled registry with versioning, access control lists, and digital signing of artefacts.
• Enforce immutability of approved production models; changes require a new version and a new approval.
• Restrict download/export of weights; monitor for bulk retrieval, which may indicate theft.
• Separate roles for model submitter, model reviewer/approver, and deployer to enforce segregation of duties and a human-in-the-loop checkpoint before production promotion.

g) Protecting inference endpoints and model consumption
• Authenticate every API call; issue per-consumer credentials and scopes.
• Apply rate limiting and quotas per identity to mitigate model extraction and denial-of-service.
• Enforce authorization on what the model may do downstream – a chatbot acting for a user should inherit that user's permissions (delegated authority), never a super-user service account. This prevents the confused deputy problem where prompt injection tricks a model into using privileges the user does not have.
• For RAG, apply document-level access controls at retrieval time so the model only retrieves content the requesting user is entitled to see.

h) Non-human and agentic identities
• Every pipeline, agent, and tool integration gets its own unique identity and narrowly scoped permissions.
• Agents should operate with delegated, time-bound credentials and have explicit allow-lists of tools and actions.
• Monitor agent behaviour for anomalous access patterns, just as you would for a privileged human user.

i) Monitoring, logging, and review
• Centralized, tamper-evident logging of data access, model downloads, training runs, deployments, and inference calls, each tied to an identity.
• Periodic access certification (recertification) by data and model owners to remove excessive or stale rights.
• Integration with SIEM / user and entity behaviour analytics (UEBA) to detect anomalies such as off-hours bulk downloads of weights or unusual queries to sensitive datasets.
• Metrics for governance reporting: percentage of accounts with MFA, number of orphaned service accounts, time to revoke access, recertification completion rates.

j) Third-party and cloud considerations
• Understand the shared responsibility model when using cloud ML platforms or foundation model APIs – the provider secures the platform, but the organization controls identities, keys, and permissions.
• Govern API keys to external model providers like any privileged credential; use enterprise accounts with SSO and usage controls rather than individually created keys (a common form of shadow AI).
• Ensure contracts and configurations prevent the provider from using your prompts and data for training unless explicitly approved.

4. How to Answer Exam Questions on Identity and Access Management for Models and Data

ISACA exam questions are scenario-based and ask for the BEST, MOST effective, PRIMARY, or FIRST action. The exam tests judgement from the perspective of an AI security manager, not a hands-on engineer. Use the following reasoning approach:

Step 1 – Identify the asset and the risk. Is the question about training data (poisoning, privacy), model weights (theft, tampering), the pipeline (unauthorized deployment), or the endpoint (abuse, extraction, confused deputy)? The correct control usually maps directly to the asset at risk.

Step 2 – Identify the type of identity. Human users point toward MFA, RBAC, recertification, and segregation of duties. Service accounts, pipelines, and agents point toward unique non-human identities, scoped credentials, secrets management, and short-lived tokens.

Step 3 – Prefer preventive governance controls over detective or corrective ones unless the question specifically asks about detection or response. Least privilege, segregation of duties, and classification-driven access are usually stronger answers than simply adding logging.

Step 4 – Look for the root cause. If credentials leaked from a notebook, the best answer is typically secrets management and credential rotation policy, not merely retraining staff. If a data scientist deployed a model directly to production, the best answer is segregation of duties and an approval gate.

Step 5 – When asked what to do FIRST, think inventory and classification. You cannot assign appropriate access until you know what models and data exist and how sensitive they are.

Step 6 – Eliminate distractors. Wrong answers often: rely on network location alone (contradicts zero trust), use shared accounts (destroys accountability), grant broad access for convenience (violates least privilege), or address a symptom rather than the control gap.

5. Exam Tips: Answering Questions on Identity and Access Management for Models and Data

• Least privilege is the default best answer when a question involves excessive or unnecessary access to data or models.
• Write access equals poisoning risk. If a scenario describes integrity concerns in training data, focus on restricting and logging write/modify permissions and enforcing provenance.
• Read/download access equals theft risk. For model weights or proprietary datasets, think export restrictions, registry access controls, and monitoring for bulk retrieval.
• Segregation of duties is the answer when one person can both develop and deploy a model, or both label data and approve evaluation results.
• Delegated, user-scoped permissions are the answer for AI assistants, agents, and RAG systems – the model should never have more authority than the user it serves. Recognize confused deputy and prompt injection privilege escalation scenarios.
• Unique identities for every pipeline, agent, and integration – shared or generic service accounts are almost always the wrong choice.
• Secrets in notebooks or code repositories point to a secrets management / vault and rotation answer.
• Static API keys to third-party model providers point to enterprise SSO, centralized key governance, and shadow AI controls.
• Data classification precedes access design. If asked what should be done before granting access to a training dataset, choose classification and owner approval.
• Recertification / access reviews are the answer when the concern is accumulated or stale privileges over time (privilege creep).
• Zero trust language – if an option trusts users because they are on the corporate network or inside the data science environment, it is a distractor.
• Accountability requires logging tied to identity – if the question asks how to support investigations or prove compliance, choose immutable, identity-attributed audit logs.
• Think like a manager: policies, roles, ownership, approval workflows, and risk-based decisions are preferred over purely technical tweaks, unless the question explicitly asks for a technical control.
• Watch for lifecycle wording: onboarding, role changes, project completion, and offboarding all signal joiner-mover-leaver processes and timely revocation.
• Shared responsibility: in cloud or API-based AI services, identity and access configuration remains the customer's responsibility – an option that shifts all IAM accountability to the provider is wrong.

6. Quick Revision Summary

IAM for models and data = right identity (unique, authenticated, human or non-human) + right access (least privilege, need-to-know, RBAC/ABAC, segregation of duties) + right asset (classified data, versioned and signed models, controlled pipelines and endpoints) + right assurance (logging, monitoring, recertification, revocation). In the exam, map the scenario to the asset at risk, choose the preventive governance control that addresses the root cause, and favour least privilege, segregation of duties, delegated authority, and accountability over convenience or network-based trust.