SaaS authentication now spans workforce, customer, and AI identities

At a glance

What this is: This is a practitioner guide to SaaS and cloud authentication, showing why the modern control plane must span workforce, customer, partner, machine, and AI-agent identities.

Why it matters: It matters because IAM teams now have to align phishing-resistant human authentication, customer-managed SSO, machine identity, and agent delegation without creating blind spots or review gaps.

👉 Read Scramble ID's guide to SaaS authentication across workforce, customer, machine, and AI identities

Context

SaaS authentication is no longer a single login problem. The same platform must authenticate internal staff, customer admins using their own IdPs, support agents acting under consent, partner systems, cloud workloads, and AI agents that act on behalf of users.

That creates distinct trust boundaries and failure modes, but they still need one coherent identity model. If those paths are treated as interchangeable, teams end up with bearer-token reuse, over-scoped service accounts, and audit trails that cannot prove who actually acted.

For SaaS operators, the baseline has moved toward phishing-resistant human authentication, customer-managed SSO, and sender-constrained machine credentials. The article is best read as a map of where identity programmes break when product, platform, and workforce requirements collide.

Key questions

Q: How should SaaS teams authenticate users, partners, and workloads without mixing trust boundaries?

A: Use separate identity domains for workforce, customer, partner, and machine paths, then connect them through a shared audit model rather than a shared credential model. Human paths should use phishing-resistant authentication, customer paths should support OIDC or SAML plus SCIM, and machine paths should use workload identity with sender-constrained tokens.

Q: Why do long-lived service-account credentials create so much risk in SaaS environments?

A: Because they can be copied, replayed, and reused long after the workload or team that created them has changed. That turns one compromise into a durable access problem. Short-lived workload identity and sender-constrained tokens reduce the blast radius by binding credentials to a specific runtime context.

Q: What do security teams get wrong about customer-managed SSO?

A: They often treat protocol support as the finish line. In practice, the SaaS still has to validate customer IdP setup, enforce minimum assurance properties where possible, and watch lifecycle changes through SCIM. Otherwise the application inherits weak or misconfigured identity policy from the customer.

Q: How should organisations govern AI agents that act on behalf of users in SaaS apps?

A: Treat the agent as a first-class identity and require explicit user delegation plus resource scope for each action. Do not let an agent reuse a user’s full bearer token by default. The control goal is to make every agent action attributable, bounded, and revocable.

Technical breakdown

Why SaaS authentication needs separate trust domains

A SaaS platform usually sits across four identity domains at once: workforce, customer, partner, and machine. Each domain has a different assurance target, different lifecycle expectations, and different blast radius when credentials leak. The common mistake is to unify them at the application layer and assume one login pattern can serve every actor. That creates hidden privilege transfer, especially when support tooling, customer SSO, and API access all rely on the same session primitives. A stable architecture instead keeps the domains distinct while still mapping actions back to a single audit model.

Practical implication: define explicit trust boundaries for each identity domain and stop reusing one authentication path for all actors.

Customer-managed SSO and SCIM as baseline controls

Customer-managed SSO via OIDC or SAML shifts the authentication decision back to the customer’s IdP, while SCIM handles lifecycle changes such as joiners, movers, and leavers. In SaaS environments, this is no longer an enterprise-only feature. It is the expected control surface for enforcing customer MFA policy, reducing account sprawl, and proving lifecycle consistency during questionnaires and audits. The hard part is not protocol support alone. The hard part is validating customer configuration, enforcing minimum assurance properties, and making the SaaS observable enough to detect when the customer’s IdP settings weaken your own security posture.

Practical implication: validate customer IdP setup, enforce minimum assurance properties, and treat SCIM as a governance control, not just provisioning automation.

Why workload identity beats long-lived service-account secrets

Service-account passwords, static API keys, and shared HMAC secrets are still the most common machine-to-machine failure mode in SaaS and cloud services. Cloud-native workload identity changes the model by issuing short-lived credentials tied to workload attestation, platform trust, and deployment context. Sender-constrained tokens such as mTLS and DPoP reduce replay risk because the token cannot simply be copied and reused elsewhere. The architectural point is simple: if a credential can live for months, it can be stolen for months. If it is bound to workload identity and a narrow scope, the blast radius drops sharply.

Practical implication: replace persistent machine secrets with workload identity and sender-constrained tokens wherever service-to-service trust crosses boundaries.

Threat narrative

Attacker objective: The attacker wants durable access that survives normal authentication checks and lets them act across tenant, customer, or service boundaries without clear attribution.

1. Entry occurs when a human, partner, or pipeline credential is reused across SaaS and cloud paths that were never meant to share the same trust boundary.
2. Escalation follows when the borrowed credential grants broader access than the original actor should have held, especially in support tooling, partner integrations, or service accounts.
3. Impact lands as tenant-wide exposure, replayable API access, or unauditable actions that cannot be cleanly tied back to the real actor.

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

SaaS authentication is now an identity architecture problem, not a login problem. The platform has to govern people, customers, partners, workloads, and AI agents in one control plane without collapsing their trust boundaries. That makes the audit trail as important as the login ceremony, because the real question is whether every action can be mapped to a verifiable identity and scope. Practitioner conclusion: identity teams should stop treating authentication as a frontend feature and manage it as a cross-domain governance layer.

Long-lived machine secrets are a structural liability, not a legacy convenience. Service-account passwords and static API keys create an exposure window that outlives the workload, the deployment, and often the team that created them. The article’s architecture points toward workload identity and sender-constrained tokens because replayable secrets simply do not fit modern SaaS blast-radius expectations. Practitioner conclusion: if a machine credential can be copied once and used many times, the programme has already lost control of the trust boundary.

Customer SSO is only secure when the SaaS can observe and enforce minimum assurance. Giving customers OIDC or SAML support is necessary, but it does not end the governance problem. If the SaaS cannot validate setup, detect weak customer MFA policy, or track lifecycle changes through SCIM, the application inherits unknown trust from the customer IdP. Practitioner conclusion: customer-managed identity must be treated as a control dependency, not an integration checkbox.

AI agents and MCP servers are becoming first-class identities in SaaS authentication. Treating them as whatever token the user happened to have is the next breach class because it erases the difference between human intent and machine execution. This is where NHI governance and agentic identity converge: the agent, the user delegation, and the resource scope all have to be bound at action time. Practitioner conclusion: teams should design for explicit agent identity and explicit delegation rather than inherited bearer privilege.

Identity blast radius is the right way to measure SaaS authentication maturity. The decisive question is not whether a login method is modern, but how far a compromised identity can move before controls stop it. That includes workforce phishing resistance, customer SSO validation, partner token binding, and machine credential scope. Practitioner conclusion: map every authentication path to its blast radius and eliminate the paths that let one credential behave like many.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For the broader control model, see OWASP Agentic AI Top 10 for agentic application risk patterns and governance boundaries.

What this signals

SaaS teams should expect authentication programmes to converge with lifecycle governance. Customer SSO, SCIM, workload identity, and support impersonation controls are no longer separate projects because failures in one layer now show up as audit gaps in another. For a useful framing of the machine side of that problem, see Ultimate Guide to NHIs — 2025 Outlook and Predictions.

Identity blast radius: the next maturity test is how far a compromised credential can travel before the platform can prove scope, stop replay, or revoke access. That is where SaaS authentication, NHI governance, and agentic delegation converge into one measurable control problem.

For practitioners

• Separate identity domains in the architecture Model workforce, customer, support, partner, workload, and agent paths as distinct trust domains with explicit boundaries and separate assurance rules.
• Replace persistent machine secrets Move service-to-service authentication onto cloud-native workload identity and short-lived sender-constrained credentials instead of long-lived API keys or shared HMAC secrets.
• Validate customer SSO and SCIM on setup Test IdP configuration, attribute mapping, and lifecycle round-trips before enabling production access so customer authentication strength does not become an unknown variable.
• Bind agent actions to identity and delegation Require a separate agent identity, explicit user delegation, and narrow resource scope for every action so AI agents do not inherit broad bearer privileges.

Key takeaways

• SaaS authentication now has to govern many identity types at once, and weak trust-boundary design is what creates most of the risk.
• Persistent machine secrets and inherited bearer tokens remain the clearest failure points, because they turn a single compromise into durable, replayable access.
• The strongest programmes bind every action to a verifiable identity, a narrow scope, and an auditable delegation chain across humans, machines, and agents.

Key terms

• Workload Identity: A workload identity is the runtime identity assigned to software that needs to authenticate without using a shared secret. It ties access to the workload context, platform attestation, and intended scope, which makes it far more governable than static credentials held in code or vaults.
• Sender-constrained token: A sender-constrained token is an access token that can only be used by the party that received it. The token is cryptographically bound to the client, which reduces replay risk and limits the damage if the token is stolen in transit or from logs.
• 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.
• Agent identity: Agent identity is the distinct identity assigned to an AI agent when it acts on behalf of a user or system. It should not collapse into the user’s credential, because the agent may select actions, tools, and timing differently from the human who delegated the task.

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 identity security programme, it is worth exploring.

This post draws on content published by Scramble ID: Authentication for SaaS and Cloud Services. Read the original.