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 why encrypted computation does not remove the need for identity and authorization controls in AI agent deployments.
Why it matters: IAM teams need this distinction because AI agents still require authenticated identities, tenant boundaries, and scoped permissions even when the underlying data never leaves encrypted form.
Context
Privacy-enhancing computation changes how data is processed, not how identity is established or governed. In AI agent environments, that distinction matters because a system can preserve confidentiality during computation and still fail on authentication, authorization, provisioning, or auditability.
The article’s central claim is that encrypted computation is additive to identity controls, not a substitute for them. For enterprise AI and NHI programmes, the governance problem remains who or what is acting, what it is allowed to do, and how that access is administered across tenants and lifecycle events.
Key questions
Q: What fails when encrypted AI computation is treated as a substitute for identity controls?
A: The failure is governance, not confidentiality. Encryption can protect data in use, but it does not authenticate users or agents, assign tenant context, enforce least privilege, or create accountable audit trails. If identity and authorization are missing, the system may still expose resources to the wrong subject, even when the underlying data remains encrypted.
Q: Why do AI agents still need authorization if their workloads run on encrypted data?
A: Because authorization decides what the agent can query, modify, or export, and encryption does not make that decision for you. AI agents can process protected data while still being over-entitled or mis-scoped. Enterprise risk comes from the combination of access and action, so the permission model must exist outside the cryptographic layer.
Q: How do organisations know whether privacy-preserving AI is actually enterprise-ready?
A: Look for identity proofing, SSO, provisioning, role mapping, tenant isolation, and audit logging tied to real users or agents. If those controls are absent, the platform may be privacy-preserving but not enterprise-governed. Readiness is shown by the ability to administer access, investigate activity, and deprovision subjects cleanly.
Q: What is the difference between encrypted computation and authorization in AI systems?
A: Encrypted computation protects the data while it is being processed. Authorization governs which authenticated subject can invoke the workflow, which resources it may reach, and what it can do with the result. In practice, the first reduces exposure of content, while the second determines whether access was valid at all.
Technical breakdown
Why encrypted computation does not solve authentication
Fully homomorphic encryption, secure multi-party computation, trusted execution environments, and related privacy-enhancing technologies let organisations process sensitive data without exposing plaintext. That is a data confidentiality control, not an identity control. These systems do not verify who the user is, how an agent was onboarded, or whether access should exist in the first place. In enterprise deployments, the identity provider, directory sync, and SSO layer still define the trusted subject before any encrypted workload can safely run.
Practical implication: Treat encrypted computation as a privacy layer and keep identity proofing, SSO, and provisioning in the control stack.
Authorization and tenant isolation still decide what an AI agent can do
AI agents can be authenticated and still be dangerous if their permissions are too broad. Authorization governs resource-level access, tenant boundaries, role mapping, and delegated permissions for both humans and agents. Encrypted computation does not enforce least privilege by itself, because the system still needs a policy engine that determines which data sources, queries, and outputs are permitted for a given identity. That is especially important when an agent acts across organisational boundaries and inherits access through application logic.
Practical implication: Scope agent permissions explicitly and verify that tenant isolation is enforced at the application layer, not inferred from encryption.
Why enterprise governance still depends on identity-linked audit trails
Audit logging without identity linkage cannot support enterprise governance. If a platform cannot tie actions to a real user, service account, or agent identity, it cannot support incident investigation, recertification, deprovisioning, or compliance reporting. The article’s point is that privacy-preserving analytics may reduce exposure of data content, but they do not remove the need for lifecycle controls, admin visibility, or accountability for who approved access and who exercised it.
Practical implication: Require identity-linked audit logs, lifecycle events, and administrative traceability before allowing AI systems into production.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity is the control plane, while encrypted computation is only the data plane. The article is right to separate privacy-preserving computation from enterprise access control, because the two solve different problems. Encryption protects what the system sees, but identity determines who gets to see it, who can invoke it, and which tenant context applies. Practitioners should not let privacy tooling blur the fact that enterprise AI security still begins with authenticated, governed subjects.
AI agent security breaks when organisations assume cryptography can substitute for authorization. That assumption fails because access decisions still have to be made before, during, and after computation. An agent can process encrypted data and still be over-entitled, mis-scoped, or untraceable if the surrounding identity layer is weak. The implication is that encrypted workloads must be evaluated through the same entitlement discipline applied to any B2B application, including tenant separation and delegated access governance.
Cross-organisation AI use cases expose a new governance concept: encrypted collaboration without identity collapse. Privacy-enhancing computation enables shared analytics without raw-data disclosure, but the governance model still needs authenticated actors, bounded permissions, and accountable administrators. In other words, collaboration privacy does not erase tenancy, it makes tenancy more important because the same agent may touch multiple domains under different policy constraints. Practitioners should treat this as a governance integration problem, not a cryptography replacement.
Verified user identity and verified agent identity now sit on the same trust ladder. The article correctly notes that enterprise AI deployments need both human and agent controls, because the business risk is not limited to people logging in through SSO. Agents need their own lifecycle, authorization, and audit model, and those controls must align with the organisation’s identity governance programme. The practical conclusion is simple: if the identity layer is missing, the AI layer is not ready for enterprise use.
Identity and authorization remain the prerequisite for AI trust, not an afterthought. Privacy-enhancing technologies may narrow exposure, but they do not create enterprise readiness on their own. The market signal is that AI security programmes are maturing from data-centric debate to governance-centric implementation, where authentication, provisioning, permissioning, and auditability determine whether a system can operate beyond a pilot. Practitioners should plan accordingly.
From our research library:
- Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
- Read next: AI Agent Authorisation Guide
What this signals
Identity-linked governance is the missing layer in many AI deployments. Privacy-enhancing computation can reduce exposure, but it does not solve who authenticated, who authorised, or who can revoke access later. That gap becomes more visible as AI systems move from pilot projects to production workflows that must satisfy enterprise controls.
Encrypted collaboration without identity collapse: the emerging design challenge is to let multiple parties compute on sensitive data without flattening tenant boundaries or accountability. The control question is no longer whether data can stay encrypted, but whether the surrounding identity model can preserve ownership, delegation, and review.
According to the 2026 Infrastructure Identity Survey, 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job. That gap shows why permissioning and lifecycle governance must be designed for AI actors, not borrowed from human IAM as a default.
For practitioners
- Define the trust boundary before deployment Map which parts of the AI workflow are protected by encryption and which parts still require identity, tenancy, and authorization controls. Do not assume privacy-enhancing computation covers user authentication, admin access, or cross-tenant policy enforcement.
- Require SSO, SCIM, and lifecycle governance Treat enterprise authentication, directory sync, and provisioning as mandatory controls for any AI platform that will handle regulated or sensitive data. The platform must support joiner, mover, and leaver events for both human and non-human identities.
- Scope AI permissions at the resource layer Model what each agent can query, write, or export at the application layer, then verify tenant isolation and delegated access rules independently of the encryption scheme. Encrypted data in use still needs explicit authorization boundaries.
- Tie every action to an identity-linked audit trail Require logs that show who approved access, which identity exercised it, and which tenant or data domain was involved. Without that linkage, recertification, incident review, and deprovisioning lose evidentiary value.
Key takeaways
- Encrypted computation reduces data exposure, but it does not replace identity, authorization, or auditability in production AI systems.
- Enterprise AI readiness depends on whether authenticated users and agents are assigned scoped permissions and tenant boundaries that can be governed over time.
- The practical control point is the identity layer, because that is where access is granted, reviewed, and revoked.
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 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents in the article still need governed identity and scoped privilege. |
| Recommendation — Apply ASI03 to verify agent identity, scope permissions, and prevent privilege misuse. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article stresses that encrypted computation does not replace authentication infrastructure. |
| NHI-05 — Overprivileged NHI | The article highlights the risk of AI systems receiving access beyond their job needs. | |
| Recommendation — Enforce strong authentication for every non-human identity before allowing encrypted workloads to run. Review agent entitlements against least privilege and remove access that exceeds task scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Authorization and tenant boundaries are central to the article's argument. |
| Recommendation — Use PR.AA-05 to keep AI access scoped to explicit permissions and tenant boundaries. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is fundamentally about enterprise identity infrastructure around AI systems. |
| Recommendation — Apply IAM controls to link authentication, provisioning, and authorization across AI deployments. | ||
Key terms
- Privacy-Enhancing Computation: A set of techniques that let organisations process sensitive data while limiting exposure of the underlying content. In this article’s context, it includes fully homomorphic encryption, secure multi-party computation, trusted execution environments, and related methods that protect data during analysis but do not govern identity or access.
- Agent Authorization: Agent authorization is the decision process that determines whether a software agent may take a specific action at runtime. It evaluates context, delegated authority, and resource sensitivity at the moment of execution, not only at login or provisioning time.
- Identity-Bound Audit Trail: An identity-bound audit trail links a sensitive action to a verified user, recipient, timestamp, and outcome. For secret sharing, this gives security teams the evidence needed to review handoffs, investigate misuse, and distinguish governed transfers from informal credential exchange.
- Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security 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.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org