Worried about Agentic AI and Quantum Threats? Start at the Gateway.

Federal, state, and local agencies are heading toward a collision of old and new. Security Assertion Markup Language (SAML) remains deeply embedded in critical government systems, with the SAML working group disbanding in 2023 and no plans to implement post-quantum cryptography (PQC) algorithms.¹ Autonomous AI agents are arriving at machine speed. Quantum computing is forcing a fundamental cryptographic transition. The identity infrastructure caught in the middle was built for human users, predictable sessions, and classical cryptography, not autonomous actors and post-quantum requirements.

Agencies cannot simply rip and replace every SAML application. Mission systems must stay online. Public services must remain available. Legacy applications still have work to do.

Agencies need a way to protect those systems now, introduce modern controls without waiting for every application to change, and migrate at a pace the mission can support. PingGateway creates that path. It gives agencies a controlled front door, a runtime policy enforcement point, and a practical way to survive the SAML tsunami while preparing for what comes next.

The SAML Tsunami Is Already Here

SAML has supported government federation and single sign-on for decades. It is stable, familiar, and woven into applications that agencies may need to operate for years. But those same strengths have created an enormous modernization challenge. Every application, certificate, trust relationship, and custom integration adds another wave to the SAML tsunami.

In many environments, authentication is embedded application by application. Each integration may rely on its own certificates, metadata, signing configuration, encryption settings, session behavior, and change process. Updating a protocol or cryptographic dependency can therefore require coordination across identity teams, application owners, vendors, contractors, and mission stakeholders.

Now three forces are crashing into that model:

The answer is not to declare SAML obsolete and trigger a big-bang replacement. The answer is to stop letting legacy federation dictate the security model at the edge.

Agentic AI Breaks the Human-Speed Security Model

Government identity systems were built around people who authenticate, open a session, and perform a manageable sequence of actions. Agentic AI shatters those assumptions. AI agents can call multiple APIs, retrieve data from several systems, invoke connected tools, and initiate transactions at machine speed with limited human oversight.

That introduces new attack paths:

• Prompt Injection: Malicious instructions attempt to push an agent beyond its intended task or security boundaries.
• Tool Poisoning: A connected tool or data source supplies misleading instructions or manipulated context.
• Unauthorized Tool Execution: An agent invokes a capability outside its approved purpose.
• Confused-Deputy Behavior: A trusted agent is manipulated into misusing authority granted by a person or service.

An agency must know which agent is acting, which person or service initiated the activity, what the agent is requesting, why it needs access, and whether that action is appropriate right now. A SAML login at the beginning of a workflow cannot answer all those questions by itself.

Securing AI agents requires short-lived credentials, explicit delegation, policy checks in the request path, and an audit trail connecting every action to the agent and the party on whose behalf it operates. Identity can no longer be a one-time login event. It must become the runtime control plane.

The Quantum Threat Is Not Waiting

Quantum risk is often treated as tomorrow's encryption problem. It is already today's identity planning problem. A cryptographically relevant quantum computer could threaten widely used public-key algorithms that support authentication, digital signatures, key establishment, certificates, and federation.

Adversaries do not need to wait for that computer to exist. In harvest-now-decrypt-later attacks, they can collect protected information today and hold it until future capabilities make it readable. For agencies responsible for long-lived, sensitive information, the threat clock is already running.

NIST finalized its first three PQC standards in 2024: FIPS 203 for ML-KEM key establishment and FIPS 204 and FIPS 205 for digital signatures.² OMB Memorandum M-26-15 directs federal civilian agencies to plan and execute a risk-based migration, prioritizing high-impact systems, High Value Assets, highly sensitive data, and systems that rely on vulnerable asymmetric cryptography.³

For SAML environments, the challenge exists at multiple layers:

• The TLS connection that transports a SAML message may depend on quantum-vulnerable key establishment.
• The SAML assertion may be signed with RSA or ECDSA through XML Signature.
• The assertion or attributes may use XML Encryption with classical cryptographic dependencies.
• Certificates, keys, libraries, identity providers, service providers, and application code may each have separate upgrade paths.

Quantum readiness is not a cipher-suite update. It is an end-to-end identity modernization effort. Agencies need a cryptographic inventory and a migration plan that accounts for the entire transaction, not just the first encrypted connection.

Why Gateway Is Critical to Identity Security in SAML Environments

Gateway sits where the action begins: in front of applications, APIs, and services as a reverse proxy and policy enforcement point. Users, partners, applications, devices, and AI agents reach the gateway first, not the protected resource.

That makes the gateway the agency's first line of identity defense. Before a request touches a backend system, teams can apply authentication, authorization, routing, traffic, and monitoring policies. Applications that cannot yet support modern identity protocols or emerging cryptographic requirements stay behind a controlled virtual perimeter instead of facing external traffic directly.

For SAML-dependent environments, this boundary provides four practical advantages:

PingGateway can work with an agency's existing identity provider and authorization services, allowing teams to extend stronger enforcement across a mixed technology environment.

Stop Agentic AI Threats Before They Reach the Application

An AI agent should never inherit a person's broad, long-lived access simply because it acts on that person's behalf. That is how confused-deputy attacks turn trusted automation into a weapon. Every request must be evaluated using the agent's identity, the initiating party, the requested action and resource, and the surrounding context.

As the first control point in the traffic path, PingGateway can help:

• Require the appropriate authentication and authorization flow before an agent reaches a protected API or service.
• Route approved agent requests to the correct service, including tools exposed through the Model Context Protocol (MCP).
• Apply traffic controls and coarse-grained access policies at the edge.
• Keep agent traffic away from applications and endpoints that should not be directly exposed.
• Create an auditable record of requests for investigation and governance.

Gateway works with identity and fine-grained authorization services to bring access decisions into the request path. This makes it possible to evaluate what an agent is attempting to do rather than relying only on who authenticated at the beginning of the session.

That distinction is critical. AI agents are moving from answering questions to acting. The security model must move with them.

Control the Transition, Then Modernize in Waves

With the edge under control, agencies can sequence the work behind it. The next step is to inventory SAML and other legacy dependencies, introduce modern access patterns, and adopt PQC-capable technologies as implementations mature.

A Practical Gateway Roadmap

1. Discover SAML and cryptographic dependencies. Identify identity providers, service providers, certificates, signing and encryption algorithms, libraries, metadata exchanges, trust relationships, and data flows. Prioritize high-impact systems, High Value Assets, long-lived sensitive data, and externally exposed services.
2. Establish the edge boundary. Place PingGateway in front of internet-facing and partner-facing applications, endpoints, and APIs, particularly those that cannot yet support the preferred identity or cryptographic model.
3. Centralize policy and visibility. Apply consistent authentication, authorization, routing, traffic controls, logging, and monitoring before requests reach backend systems.
4. Mediate modern and legacy identity. Present OAuth 2.0, OIDC, or modern tokens at the edge where appropriate, then translate them into the SAML assertions, headers, or other credentials a legacy application requires.
5. Strengthen transport security. Adopt the strongest approved cryptography supported by clients and infrastructure, including PQC or hybrid key establishment as it becomes operationally available. Document any connection segments that remain classically protected.
6. Migrate applications in waves. Move each application toward modern protocols and PQC-capable components based on risk, readiness, and mission impact. Update gateway routes as the target environment changes.
7. Retire transitional dependencies. Remove legacy translation paths, certificates, and cryptographic components once applications can support the target architecture directly.

This approach replaces the big-bang cutover with controlled progress. Agencies can strengthen the edge today, keep essential services running, and move the highest-risk systems first.

Know the Boundary Between Gateway Protection and PQC Compliance

The gateway is a migration boundary, not a magic shortcut to end-to-end PQC compliance.

If a backend application still requires a SAML assertion signed with a classical algorithm, that portion of the transaction remains dependent on classical cryptography. The same is true for non-PQC certificates, XML encryption, application libraries, internal connections, and stored data. A quantum-resistant or hybrid connection to the gateway protects that connection. It does not automatically transform every downstream dependency.

Agencies should therefore treat gateway deployment and application modernization as complementary workstreams:

• Use the gateway to improve control, visibility, and protection now.
• Maintain an explicit inventory of remaining SAML, legacy application, and cryptographic dependencies.
• Assign owners, milestones, and risk decisions for each migration wave.
• Validate the complete transaction path before claiming end-to-end PQC readiness.

That distinction matters. Agencies can gain meaningful protection now while remaining precise about what still needs to change. Strong security starts with knowing exactly where the boundary ends.

Do Not Let the SAML Tsunami Control the Pace of Security

SAML will remain part of government identity environments for years. The question is whether agencies allow those dependencies to slow every security improvement, or put them behind a controlled boundary and take back control of the modernization timeline in smaller waves.

Gateway provides that controlled path forward, helping agencies separate immediate protection from the longer-term work of modernizing applications and cryptographic dependencies.

Agentic AI and quantum computing are different threats, but they demand the same architectural discipline: make every access path visible, make every decision explicit, and never tie security progress to the pace of the slowest application.

The SAML tsunami is coming. Government agencies do not have to face it unprotected. Put identity at the edge, turn the gateway into the policy enforcement point, and start modernizing one controlled wave at a time.

¹ OASIS - Security Services (SAML) Technical Committee (closed 8 July 2023)

² NIST - Announcing Approval of Three Federal Information Processing Standards for Post-Quantum Cryptography

³ The White House, Office of Management and Budget - Memorandum M-26-15: Execution of the Migration to Post-Quantum Cryptography

Frequently Asked Questions