What breaks when organisations rely on SAML alone for agentic AI?

Why This Matters for Security Teams

SAML was designed to assert who authenticated, not to carry the full operational context of an autonomous action. In agentic ai systems, that limitation matters because the same signed session can be reused across multiple tool calls, data sources, and prompts, even when the request is no longer aligned with the original intent. If teams treat SAML as the whole control plane, they can miss scope creep, delegated overreach, and actions that appear legitimate but are not appropriate in the moment. The practical consequence is that governance becomes retrospective instead of preventative. Security teams may see a valid user session in the logs while missing the fact that an agent used that session to reach a resource the person never explicitly chose, or that the action exceeded the intended business task. That is why agentic systems need decision-time context, not just login-time proof. The challenge is not authentication alone, but attribution across person, agent, resource, and purpose. This gap is showing up in current deployment patterns: AI Agents: The New Attack Surface report found that only 52% of companies can track and audit the data their AI agents access, which means nearly half lack basic investigative visibility. In practice, many security teams discover this weakness only after an agent has already acted outside its intended scope, rather than through deliberate control design.

How It Works in Practice

In a conventional SAML flow, the identity provider issues a signed assertion that a user authenticated and what broad attributes they possess. That works well for browser sign-in and coarse-grained enterprise access, but it does not describe the full chain of execution once an AI agent begins operating. The missing pieces are the ones that matter most in agentic systems: which action the person intended, which action the agent actually executed, which tool or resource was reached, and whether the authorization should have been time-bound, task-bound, or step-bound. Agentic AI adds another layer because the agent can decompose a human request into several sub-actions. One SAML assertion can therefore underwrite a long sequence of decisions, some low risk and some highly sensitive. The control problem is to separate durable human identity from transient delegated authority. Without that split, organisations inherit the user’s access into every downstream action, which makes it hard to distinguish a benign automation step from an unauthorized one.

• Use SAML for session establishment, but pair it with per-action authorization checks for tool use, data access, and side effects.
• Record the initiating user, the agent instance, the target resource, and the specific action outcome for each step.
• Treat high-impact actions as requiring fresh policy evaluation, not just a previously valid session.
• Limit the agent’s standing permissions so a single assertion cannot silently unlock broad inherited access.

For teams that need a deeper model of the agent-risk surface, the OWASP Top 10 for Agentic Applications 2026 is useful because it frames common failure modes around autonomy, tool misuse, and privilege abuse. These controls tend to break down when SAML assertions are reused as a blanket permission layer across multiple tools, because the original authentication event no longer reflects the current decision context.

Common Variations and Edge Cases

Tighter identity control often increases operational friction, so organisations have to balance delegation speed against blast-radius reduction. The right answer depends on whether the agent is only retrieving low-risk information or is allowed to mutate records, trigger workflows, or access sensitive systems. A few cases change the design materially:

• Low-risk read-only agents may tolerate broader session reuse if outputs are monitored and no sensitive side effects exist.
• Agents that act across systems need step-level logging and explicit scoping, because one SAML session cannot safely describe every downstream authorization.
• Shared enterprise sessions are especially dangerous, because the original human intent becomes difficult to separate from agent behaviour.
• Long-lived sessions increase exposure, since the original authentication event becomes stale relative to the action being taken.

The best-practice direction is evolving toward contextual, task-aware authorization rather than pure single-sign-on reuse. That does not mean replacing SAML everywhere, but it does mean refusing to let authentication prove more than it actually can. The edge case to watch most closely is delegated action on sensitive systems, where a valid session can still be the wrong authority for the task.

Risk and Threat Considerations

The core risk is confused-deputy behaviour: an agent uses a valid user session to perform an action that the person did not explicitly intend, approve, or understand in that moment. That creates a governance problem even when the authentication event was legitimate, because the trust boundary shifts from login to action execution. Failure mechanism: The attacker or failure path is usually over-broad delegation, stale session reuse, or insufficient step-level policy enforcement. Once a SAML assertion is accepted as proof for an entire workflow, the agent can inherit access to tools and resources that exceed the scope of the original request. Impact: The result can be unauthorized data exposure, unintended record changes, policy violations, and weak forensic attribution. Security teams may be able to prove who logged in, but not whether the specific action was appropriate, necessary, or authorized at the time it occurred.

Practitioner Guidance

What to prioritise: Separate authentication from delegation. SAML can remain the sign-in layer, but sensitive agent actions should be governed by per-action policy checks, not by the original login alone.

What to verify: Confirm that logs capture the initiating person, the agent instance, the exact resource, and the concrete action outcome. If any one of those is missing, incident review will be incomplete and scope analysis will be weak.

Decision rule: If an agent can write, delete, transfer, approve, or expose data, treat the action as a fresh authorization event. Read-only retrieval can tolerate more reuse than irreversible side effects.

Practitioner takeaway: The control objective is not to distrust SAML, but to stop treating a successful login as proof that every downstream agent action is still appropriate.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on endpoint controls alone for AI use?
• What breaks when organisations rely on human oversight alone for AI risk?
• What breaks when organisations rely on DMARC alone against AI-driven phishing?
• What breaks when organisations rely on SBOMs alone for AI-enabled applications?