Privacy-enhancing technologies protect data during computation, but IAM governs who the actor is, how it authenticates, and what it may do after access is granted. Enterprises still need SSO, lifecycle provisioning, authorization, and audit logging to run AI systems safely at scale.
Why This Matters for Security Teams
Privacy-enhancing technologies such as encryption, tokenization, differential privacy, and secure enclaves reduce exposure of data during processing, but they do not answer the enterprise control question: who is the actor, how is it authenticated, and what is it allowed to do next? That gap is why IAM remains foundational for AI systems even when data protection is strong. The NIST Cybersecurity Framework 2.0 still treats identity, access control, and logging as core governance functions, not optional add-ons.
For AI programs, the risk is larger than a single data leak. Models, agents, and automation pipelines often need persistent service identities, scoped permissions, lifecycle management, and revocation when behaviour changes. NHIMG has highlighted how fragile secrets handling becomes in practice, including the State of Secrets in AppSec findings from GitGuardian and CyberArk, which reported that the average time to remediate a leaked secret is 27 days. That is a reminder that privacy controls and identity controls solve different problems. In practice, many security teams discover this only after an AI workflow has already used valid credentials outside its intended scope.
How It Works in Practice
The practical model is layered. Privacy-enhancing technologies protect the content of data, while IAM governs the actor that touches that data. For enterprise AI, that means treating the model, agent, pipeline, or workload as a first-class identity and assigning access based on task, context, and policy. A secure design usually combines SSO for human access, workload identity for automated components, JIT credentials for short-lived tasks, and audit logging that shows which identity performed each action.
Current guidance suggests that enterprise AI should not rely on static API keys or broad service accounts for long-running automation. Instead, use short-lived credentials, service-to-service authentication, and policy-as-code so access decisions are evaluated at request time. This is consistent with the direction of Ultimate Guide to NHIs — Why NHI Security Matters Now, which frames non-human identities as a core enterprise control surface rather than a back-office concern. For data in use, PETs can complement IAM by reducing the blast radius of a compromise, but they cannot replace provisioning, deprovisioning, entitlement review, or separation of duties.
In a mature control plane, an AI agent requests a specific capability, receives a time-bound token, performs the task, and then loses access automatically. That aligns better with operational reality than assuming a model will always behave predictably. These controls tend to break down in highly distributed environments where service identities proliferate faster than entitlement reviews can keep up.
- Use IAM to verify identity and authorize actions before the AI system touches sensitive resources.
- Use PETs to reduce data exposure during training, inference, or analytics.
- Use short-lived tokens and rotate secrets automatically after each task or session.
- Log both the workload identity and the action taken so investigations can trace misuse.
Common Variations and Edge Cases
Tighter privacy controls often increase engineering overhead, requiring organisations to balance data minimisation against operational access and debugging needs. That tradeoff is especially visible in AI systems that depend on embeddings, vector databases, or third-party inference services, where PETs may protect payloads but still leave identity, privilege, and audit gaps unresolved.
There is no universal standard for this yet, but best practice is evolving toward a split control model: PETs for data protection, IAM for actor governance. In regulated environments, that means preserving evidence of who approved access, which workload used it, and whether the granted scope matched the task. This is where the McKinsey AI platform breach and the DeepSeek breach matter as cautionary examples: strong data handling is not a substitute for controlling identities and credentials around the system. PETs can make sensitive data harder to read; they do not stop an over-privileged agent, a misconfigured service account, or a compromised token from taking unauthorized action.
The practical rule is simple: if the question is about trust in the data, PETs help; if the question is about trust in the actor, IAM is still mandatory.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Enterprise AI still depends on proper non-human identity governance. |
| NIST CSF 2.0 | PR.AC-1 | Access control remains required even when data is protected in use. |
| NIST AI RMF | AI risk governance must cover both data protection and actor authorization. |
Map AI controls across governance, measurement, and risk response before deployment.
