TL;DR: Privacy-enhancing computation can keep sensitive data encrypted during analysis, but it does not replace SSO, provisioning, authorization, audit logging, or agent identity controls in enterprise AI systems, according to WorkOS. Identity, tenancy, and access governance remain the foundational layer for production AI agent deployments, not an optional add-on.
At a glance
What this is: This is an analysis of where privacy-enhancing computation fits in AI agent security, and its key finding is that encrypted computation does not remove the need for identity and authorization infrastructure.
Why it matters: It matters because IAM, NHI, and autonomous-system programmes still have to govern who or what is authenticated, what it can do, and how access is revoked, even when data stays encrypted in motion and at rest.
👉 Read WorkOS's analysis of AI agent security and encrypted computation
Context
AI agent security fails when teams assume encrypted computation can stand in for identity controls. The core gap is not whether data can be processed without plaintext exposure, but whether the user, service, or agent behind that computation is verified, scoped, and governed across the application layer. For enterprise AI agent security, identity remains the control plane.
Privacy-enhancing technologies such as fully homomorphic encryption are useful for collaboration on sensitive data, but they are not a substitute for SSO, directory sync, lifecycle provisioning, MFA, or resource-level authorization. That distinction matters for B2B software and AI platforms that must prove tenant boundaries, admin visibility, and auditability before they can be trusted in production.
Key questions
Q: How should security teams govern AI agents that use encrypted data platforms?
A: Security teams should govern AI agents as non-human identities with explicit authentication, scoped permissions, and audit trails, even when the data they process stays encrypted. The privacy layer protects confidentiality, but the identity layer still determines who can act, which tenant they belong to, and how access is revoked when circumstances change.
Q: Why do privacy-enhancing technologies not replace IAM for enterprise AI?
A: 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.
Q: What breaks when agent permissions are not tied to identity controls?
A: When agent permissions are detached from identity controls, teams lose tenant isolation, revocation discipline, and traceability. That creates a gap where an agent can access or process data without a clear ownership chain, which is especially risky in regulated or cross-organisational workflows.
Q: How do organisations decide whether encrypted computation is enough for a use case?
A: Encrypted computation is enough only when the main risk is plaintext exposure during processing and the surrounding identity model is already mature. If the use case still needs user onboarding, delegated access, admin review, or offboarding, IAM remains the controlling layer.
Technical breakdown
Why encrypted computation does not solve identity and access
Fully homomorphic encryption, secure multi-party computation, and trusted execution environments are privacy controls for data processing. They reduce what a processor can see, but they do not establish who the actor is, what tenant it belongs to, or whether the requested action is allowed. In production AI systems, authentication and authorization are separate layers from computation privacy. That separation is why PETs can strengthen confidentiality while still leaving enterprise access risk unchanged if identity governance is weak.
Practical implication: keep encrypted-computation projects downstream of verified identity, tenant isolation, and application authorization controls.
Agent identity is still an authorization problem
AI agents change the access problem because they act on behalf of users, workflows, or services while consuming tokens and making calls across systems. Even if the underlying data stays encrypted, the agent still needs a durable identity, scoped permissions, and auditable access mapping. Without that, the system cannot distinguish between a legitimate delegated action and overbroad machine access. This is where NHI governance and enterprise IAM intersect: the agent is not just a workload, it is an access-bearing identity with operational consequences.
Practical implication: model AI agents as first-class non-human identities and bind their permissions to explicit tenant and task boundaries.
Cross-org collaboration needs governance above the cryptography layer
Privacy-preserving collaboration is only useful when governance defines who may submit queries, which datasets are in scope, how results may be used, and which organisations retain control over the workflow. That governance is data-centric, but enterprise security still needs identity-centric controls around provisioning, deprovisioning, admin review, and audit trails. The architectural lesson is simple: PETs protect the computation, while IAM governs the participants and the permissions. Treating those as interchangeable creates a false sense of completeness.
Practical implication: pair collaboration-governance rules with identity lifecycle controls so access changes track users, admins, and agents consistently.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Encrypted computation is not an identity model. Privacy-enhancing technologies can reduce data exposure during processing, but they do not answer the governance questions that enterprise systems must still solve: who is the actor, what is its tenant boundary, and what is it allowed to do. The result is that PETs change the confidentiality story without changing the access-control story. Practitioners should treat encrypted computation as a data-protection layer, not as a substitute for IAM or NHI governance.
AI agent security inherits the same trust chain as every other enterprise workload, then expands it. An agent may be able to operate on encrypted data, but it still needs authentication, scoped permissions, and revocation logic that survives delegation across systems. That makes agent identity an extension of non-human identity governance, not a separate discipline. The implication is that teams must design for delegated machine access, not just for protected data.
Cross-organisational collaboration creates an identity governance gap when the policy layer stops at the data boundary. Governance over queries, results, and sharing rules matters, but enterprise assurance still depends on lifecycle offboarding, admin accountability, and traceable user-to-agent mapping. When those controls are missing, privacy protection can coexist with unmanaged access. Practitioners should not confuse cryptographic privacy with operational control.
Workload privacy and access governance are converging, but they are not interchangeable controls. The market is moving toward architectures that combine encrypted computation with enterprise identity infrastructure, because buyers need both confidentiality and auditability. That direction validates stronger NHI governance, not weaker IAM. Teams should expect security architecture reviews to examine both the computation layer and the identity layer in the same decision.
Named concept: encrypted-computation trust debt. This is the gap created when teams assume privacy technology has closed the security problem before identity, lifecycle, and authorization are actually proven. The debt shows up later as weak admin visibility, poor agent scoping, or missing offboarding across collaborative workflows. Practitioners should treat that debt as a design flaw, not an implementation detail.
From our research:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
- That is why teams should also review Ultimate Guide to NHIs , 2025 Outlook and Predictions for the broader governance direction.
What this signals
Encrypted-computation trust debt: organisations can adopt privacy technology and still accumulate identity risk if they do not bind it to SSO, provisioning, and offboarding. The next wave of AI deployments will be judged less on whether data stayed encrypted and more on whether access was traceable, revocable, and auditable across the full lifecycle.
The practical signal for security teams is that AI privacy, NHI governance, and enterprise IAM are converging into a single buying decision. If an AI system cannot prove tenant boundaries, delegated access, and admin accountability at the same time, the architecture is not ready for regulated use.
With 98% of companies planning to deploy more AI agents within 12 months, the governance gap is becoming structural rather than exceptional. Teams should align agent identity controls with the OWASP Agentic AI Top 10 and review decision rights before the next deployment cycle.
For practitioners
- Keep identity upstream of privacy controls Require SSO, directory sync, provisioning, and MFA before approving any encrypted-computation use case for production data. If the platform cannot prove who the user or agent is, the privacy layer is incomplete.
- Model AI agents as governed non-human identities Assign explicit tenant boundaries, scoped permissions, and audit trails to every agent that can request data or trigger computation. Do not allow agent access to inherit from human admin entitlements without review.
- Separate collaboration policy from access policy Define who may submit work, which datasets can be touched, how outputs may be reused, and how access is revoked when a user or vendor relationship changes. The policy set should survive platform changes and account turnover.
- Test offboarding and auditability before rollout Verify that user deprovisioning, agent revocation, and admin activity logs remain intact across encrypted workflows. If investigators cannot reconstruct who acted and when, the deployment is not ready for regulated enterprise use.
Key takeaways
- Privacy-enhancing computation protects data during processing, but it does not replace identity, authorization, or lifecycle governance.
- AI agents still need first-class identity controls because encrypted data alone does not define who can act or revoke access.
- Enterprises should evaluate privacy technology and IAM together, because production readiness depends on both confidentiality and accountability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AA-02 | Agent access and delegation are central to the article's AI security gap. |
| OWASP Non-Human Identity Top 10 | NHI-01 | The article centers on non-human identity controls for AI agents and workloads. |
| NIST CSF 2.0 | PR.AC-1 | Authentication and access management remain the foundation beneath privacy technology. |
Bind agent permissions to explicit identity, scope, and revocation rules before production rollout.
Key terms
- Privacy-enhancing technology: A privacy-enhancing technology reduces exposure of sensitive data while it is stored, shared, or processed. In practice, it shifts the security question from plaintext visibility to governance, performance, and assurance, which means identity and authorization still have to be solved separately.
- Fully homomorphic encryption: Fully homomorphic encryption allows computation on encrypted data without decrypting it first. That protects confidentiality during processing, but it does not authenticate users, assign privileges, or manage lifecycle events, so it must sit alongside identity and access controls, not in place of them.
- Agent identity: Agent identity is the governed identity assigned to a software actor that can request data, call tools, and act on behalf of a user or system. For enterprise security, it must be measurable, scoped, revocable, and tied to audit records just like any other access-bearing identity.
- Encrypted-computation trust debt: Encrypted-computation trust debt is the risk created when teams assume privacy technology has solved security before identity and governance are proven. It accumulates when authentication, authorization, and offboarding remain unclear, even though the data path itself is encrypted.
Deepen your knowledge
AI agent security and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity controls for encrypted-computation workflows, it is worth exploring.
This post draws on content published by WorkOS: Duality for AI Agent Security, Features, Pricing, and Alternatives. Read the original.
Published by the NHIMG editorial team on 2025-11-10.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org