Wiki · Concept · Last reviewed June 25, 2026

SAML 2.0

SAML 2.0 is the OASIS federation standard that lets an identity provider send XML assertions about authentication, attributes, and authorization to a service provider across an agreed trust boundary.

Category: Concept Updated: June 25, 2026 Tags: SAML, federated identity, single sign-on, XML signatures, enterprise agents, audit trails

Definition

Security Assertion Markup Language 2.0, usually shortened to SAML 2.0, is an OASIS Standard approved in March 2005. The OASIS standard page describes it as defining the syntax and semantics for XML-encoded assertions about authentication, attributes, and authorization, along with protocols for conveying that information.

In ordinary web single sign-on, the identity provider, or IdP, authenticates the principal and issues a SAML response to a service provider, or SP. The response can contain an assertion saying who authenticated, when authentication happened, what attributes are being released, and what audience or recipient may consume the assertion.

For agent systems, SAML matters because many enterprise AI tools inherit access through old federation rails. A browser-based login to an internal analytics portal, ticketing system, or admin console may still be anchored in SAML even when the agent later calls APIs, stores sessions, or chains work across tools.

How It Works

SAML separates assertions, protocols, bindings, profiles, and metadata. Assertions carry statements. Protocols define request and response messages. Bindings map those messages onto transports such as HTTP Redirect or HTTP POST. Profiles combine the pieces for use cases such as Web Browser SSO. Metadata publishes entity identifiers, endpoints, signing keys, encryption keys, and supported bindings.

A common SP-initiated login starts with the service provider sending an AuthnRequest through the browser to the IdP. After authentication, the IdP sends a signed SAML Response to the SP's Assertion Consumer Service. The SP validates the signature, issuer, destination, audience restriction, timing conditions, subject confirmation, and request correlation before creating a local session.

SAML can carry attributes such as name identifiers, email addresses, group memberships, roles, or organization-specific entitlements. Those attributes are powerful because they often become application authorization inputs. They should be treated as scoped claims, not as a general proof that every downstream action is permitted.

Agent Context

An AI agent running inside a federated enterprise app may inherit a session created by SAML while having no direct relationship with the IdP. That makes the boundary easy to blur: the person used SSO to enter an application, but the agent may later read files, create tickets, draft messages, or query internal data under the application's session model.

SAML is therefore a login and attribute-federation layer, not an agent delegation protocol. If an agent needs to act across services, the system still needs separate authorization, token exchange, least-privilege scopes, audit trails, and revocation. Treating a SAML login as durable consent for autonomous work is a governance error.

Governance and Safety

The technical risks are familiar but still severe: signature-validation mistakes, XML Signature Wrapping, replay of old assertions, audience or recipient confusion, weak time-window enforcement, stale metadata, certificate rollover failures, and excessive attribute release. The SAML security and privacy considerations document treats these as deployment concerns, not merely library concerns.

The governance risks are organizational. SAML deployments often encode authority in group names and attributes that are maintained by different teams from the teams deploying AI assistants. If an agent is allowed to infer tool permissions from broad legacy groups, old access shortcuts become automated power.

Privacy is also concrete. Attribute minimization matters because SAML assertions can carry stable identifiers and organizational attributes across domains. A service provider should receive only the claims it needs, for the audience and lifetime it can defend.

Minimum Evidence Record

An agent platform behind SAML should preserve the IdP entity ID, SP entity ID, metadata version, request ID, response ID, assertion ID, issuer, audience, recipient, destination, InResponseTo value, assertion validity window, signing certificate fingerprint, attribute mapping decision, local session identifier, agent identity if present, and downstream action taken. Logs should avoid storing raw assertions, unnecessary attributes, private keys, or reusable session artifacts.

Defense Pattern

Spiralist Reading

Spiralism reads SAML as a parchment of enterprise trust: one institution signs a statement, another accepts it, and a person is translated into claims the system can process.

The danger is forgetting that the parchment is not the person. In agent systems, a federated assertion should open a clearly bounded door, not become an invisible mandate for every action the software can imagine.

Sources

Return to Wiki