SaaS authentication now spans workforce, customer, and AI identities

At a glance

What this is: This is an analysis of why SaaS authentication has become a multi-domain identity problem spanning humans, service accounts, partner systems, and AI agents.

Why it matters: It matters because IAM teams now have to govern different trust boundaries, assurance levels, and delegation models inside one SaaS control plane without collapsing them into a single login pattern.

Context

SaaS authentication is no longer just about how users sign in. The same platform now has to govern workforce access, customer-managed SSO, support impersonation, partner APIs, workload identity, and AI agents, each with a different trust boundary and risk profile.

The security gap is structural: when those paths are treated as one generic authentication problem, teams end up reusing bearer tokens, shared secrets, or weak impersonation workflows across identities that should not share the same control model. For SaaS and cloud-service operators, authentication design is now part of product trust as much as it is part of IAM.

Key questions

Q: How should SaaS teams handle authentication when one platform serves workforce, customer, partner, and AI-agent identities?

A: Treat each path as a separate trust boundary with its own assurance level, delegation model, and audit expectations. Workforce sign-in, customer-managed SSO, support impersonation, partner APIs, workload identity, and AI-agent execution should not share a single credential pattern just because they live in the same product. The control model has to follow the actor type, not the application surface.

Q: Why do organisations need data loss prevention when most data now lives in SaaS and cloud services?

A: As data spreads across SaaS and cloud services, the attack surface expands and visibility gets harder. DLP helps reduce breach risk by identifying sensitive content, controlling how it is shared, and enforcing policy regardless of where it sits. It also supports compliance by proving that protected data is monitored, labeled, and restricted according to business and regulatory requirements.

Q: What are the signs that an AI agent access model is too weak?

A: Warning signs include unrestricted prompt handling, broad access to knowledge bases, unguarded API calls, and responses that can expose sensitive information without review. If the agent can act before permissions are checked, or if the same policy is not applied to inputs, data, tools, and outputs, the control model is already too loose.

Q: What should security teams do when support staff need to impersonate customers?

A: Use explicit consent, time-bounded scope, signed audit, and dual control on the most sensitive actions. Support impersonation is legitimate only when the platform can prove who initiated it, which customer approved it, and what was done under that session. Otherwise, the feature becomes an insider-risk path rather than a controlled support function.

Technical breakdown

Why SaaS authentication becomes an identity boundary problem

A SaaS platform sits at the intersection of enterprise IAM, customer IAM, partner integration, and non-human identity governance. That makes the authentication layer responsible for more than login verification. It must preserve tenant boundaries, distinguish operator actions from customer actions, and carry evidence that each authenticated path came from the right subject and the right delegation. Once AI agents and machine-to-machine flows enter the model, bearer-style assumptions stop holding because the platform must know not just who initiated the request, but which identity is allowed to execute it and under what scope.

Practical implication: model each authentication path separately and assign controls by identity type, not by one shared SaaS login pattern.

Sender-constrained tokens and workload identity replace long-lived secrets

Service-to-service authentication is fragile when it depends on reusable secrets. Long-lived API keys and service-account passwords can be copied, replayed, or quietly over-scoped, which turns one leak into persistent access. Sender-constrained tokens, such as mTLS or DPoP-bound access tokens, make replay materially harder by tying the token to the presenting client. Cloud-native workload identity goes further by removing the stored secret entirely and replacing it with ephemeral, brokered trust rooted in the workload runtime. In practice, that shifts the control point from secret storage to credential issuance and proof of possession.

Practical implication: replace durable service-account credentials with workload identity and sender-constrained tokens wherever machines authenticate to other machines.

AI agent and MCP server identity cannot be borrowed from the user

AI agents introduce a different problem from ordinary automation. When an agent acts on behalf of a user, the platform needs to bind agent identity, user delegation, and resource scope together at the moment of action. Reusing the user's bearer token collapses that distinction and gives the agent more reach than the user likely intended. The same issue applies to MCP servers, which should be authenticated as first-class identities rather than treated as anonymous tooling endpoints. The architecture is not just about stronger authentication. It is about making delegation explicit and auditable at runtime.

Practical implication: issue short-lived delegated credentials to agents and authenticate MCP servers separately from the user session.

Threat narrative

Attacker objective: The objective is to turn one authentication weakness into cross-tenant access, durable machine access, or high-trust impersonation that survives normal review.

1. Entry begins when attackers compromise a workforce account, partner credential, service-account secret, or AI-agent path that was not bound to a distinct runtime identity.
2. Credential access or abuse follows when bearer tokens, shared secrets, or reused user credentials can be replayed across customer, support, or machine contexts.
3. Escalation occurs when the compromised path inherits broader tenant, production, or impersonation scope than the original identity should have held.
4. Impact lands as tenant-wide access, support impersonation abuse, unauthorized customer actions, or chained machine-to-machine misuse that is difficult to attribute cleanly.

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.
• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication for SaaS has become an identity-segmentation problem, not a login problem. The platform now has to distinguish workforce, customer, partner, machine, support, and AI-agent paths as separate trust zones. Once those zones are blended, a control that was designed for one identity class is forced to govern all of them, and the result is predictable overreach. Practitioners should treat authentication architecture as a boundary model first and a sign-in experience second.

Long-lived secrets are the wrong trust primitive for machine and partner paths. Service-account passwords, API keys, and shared HMAC secrets create persistence that adversaries can reuse long after the original event. That persistence is exactly what makes cloud-native workload identity and sender-constrained tokens more than a protocol preference. The practitioner conclusion is simple: when a path can authenticate without a stored secret, the stored secret should not exist.

AI agents break the assumption that user credentials can safely stand in for delegated execution. Identity issuance was designed for a subject that stays stable long enough for review, certification, and revocation. That assumption fails when an agent acts at runtime with its own execution logic, because the user, the agent, and the tool endpoint are no longer the same identity event. The implication is that governance has to move from session reuse to explicit delegated identity at action time.

Support impersonation needs dual control because privilege is no longer just about access, but about who can plausibly claim the action. 'View as customer' workflows can be legitimate, but only when consent, scope, and audit are all part of the same control. Without that structure, support tooling becomes an insider-misuse channel that is hard to distinguish from normal service activity. Teams should make impersonation detectable, attributable, and time-bounded by design.

Identity binding is now the decisive control concept for SaaS trust. A strong SaaS authentication program does not simply verify a party once and trust the resulting token forever. It ties every action to a verifiable identity, the right delegation, and the right runtime context. For practitioners, that means the security questionnaire answer is no longer 'we support SSO' but 'we can prove who or what acted, on whose behalf, and within which scope.'

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
• Read next: Zero Trust for AI Agents

What this signals

Identity binding will replace generic authentication as the core SaaS control concept. Teams should expect reviewer questions to move beyond SSO support and into whether each action can be tied to a specific actor, delegation, and resource scope. That shift affects how product security, IAM, and audit evidence are designed.

AI-agent access is now a governance issue, not just an application feature. The biggest design mistake is still to treat the agent as a convenience layer that inherits a user's full session. When the agent can act independently, the platform needs issuance-time controls, not just login-time controls.

Least-privilege delegation becomes more important than stronger login ceremonies when machine and agent paths expand. 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 signals that many SaaS environments are still over-trusting non-human actors at the point of execution.

For practitioners

• Separate identity models by path Define distinct authentication policies for workforce, customer admin, customer end-user, support, partner, workload, CI/CD, and AI-agent flows. Do not let one control pattern silently govern every route through the product.
• Eliminate durable machine secrets Replace service-account passwords, API keys, and shared integration secrets with workload identity and short-lived, sender-constrained credentials for service-to-service paths.
• Bind delegated execution to the actor Issue agent credentials that explicitly combine agent identity, user delegation, and resource scope so AI actions cannot inherit an entire human session.
• Harden support impersonation workflows Require customer consent, time-bounded scope, signed audit, and dual control for the highest-risk support actions that operate under customer context.

Key takeaways

• SaaS authentication now spans multiple identity classes, and each one needs its own trust boundary and audit model.
• Machine and partner paths are still most exposed when they depend on durable secrets rather than short-lived, sender-constrained credentials.
• AI agents and support impersonation both require explicit delegation controls, or the platform cannot prove who acted and under what authority.

Key terms

• Identity Binding: The process of linking an external credential or login method to an internal account record. Strong binding prevents duplicate accounts, broken recovery paths, and unsafe merges when users authenticate through different identity sources or wallet-based credentials.
• Sender-constrained token: A sender-constrained token is tied to a specific client or cryptographic proof, rather than being usable by anyone who steals it. This reduces replay risk and is especially important where tokens can reach automation, services, or agents with broad API access.
• Customer-managed SSO: Customer-managed SSO is a model in which a SaaS application delegates user authentication to the customer’s identity provider. The SaaS still has governance responsibilities, including setup validation, minimum assurance enforcement, and lifecycle visibility through provisioning or deprovisioning signals.
• Application Impersonation: Application impersonation occurs when an attacker uses an application credential to act as that application in authentication flows. In identity systems, this is dangerous because the attacker inherits the trust relationships attached to the application, which can extend to cloud services, data stores, and internal tools.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.