Inviting SaaS AI—Without Inviting Trouble

The External SaaS Integration Challenge

AI agents don't live inside a single network anymore. They reach across enterprise and SaaS boundaries — calling external tools, retrieving partner data, or exposing internal capabilities to trusted third parties. This cross-boundary interaction introduces two distinct integration scenarios, each with its own security profile.

• Only trusted, authorized agents may communicate across boundaries.
• Sensitive data must be protected in transit between systems.
• All cross-boundary access must be fully auditable.
• The integration must scale to many agents — manual credential handshakes won't cut it when dozens of AI agents spin up or down daily.

OAuth 2.1 — Secure Baseline for AI-to-SaaS Integration

OAuth 2.1 provides a modern, hardened baseline for delegating access securely across systems. It isn't a new protocol but a security-focused evolution of OAuth 2.0 that removes unsafe practices and mandates proven ones. The MCP specification leans heavily on OAuth 2.1 for agent authorization — and for good reason.

In both scenarios, we use OAuth 2.1 as the foundation: the AI agent acts as an OAuth client and the MCP (or API) as a resource server protected by an OAuth authorization server. The twist is ensuring trust in an otherwise open OAuth registration model — that's where Trust Registries and Dynamic Client Registration come in.

Trust Registries for Controlled Onboarding

A Trust Registry is an authoritative list or service that tracks which external parties (SaaS agents or services) are trusted to integrate with your system. Instead of allowing any unknown AI service to connect, both the enterprise and SaaS provider maintain a controlled roster of trusted partners. Think of it as a "permissioned phonebook" for OAuth clients and servers.

How Trust Registries Enforce Control

• Pre-vetting: Only organizations that have been vetted (contract, security review, compliance check) get a registry entry. Unknown parties are rejected.
• Credential binding: The registry issues digital credentials (certificate or signed token) to the trusted partner. This credential is later used in OAuth flows to prove "I am an approved partner."
• Dynamic verification: When an OAuth client registers or requests access, the authorization server checks presented credentials against the Trust Registry. Invalid or missing credentials mean instant denial.
• Revocation: Removing a partner from the registry (and revoking their credential) prevents any new token issuance or registrations — a central kill-switch for access.

Dynamic Client Registration (DCR): Self-Service Onboarding

Dynamic Client Registration (RFC 7591) allows OAuth clients to register themselves with an authorization server on the fly by calling a standard /register endpoint with metadata. Instead of manually pre-registering every client, DCR enables programmatic onboarding — vital when you don't know ahead of time which AI agents or services will need to connect.

Signed Software Statements

The solution adopted in many ecosystems is to require the registering client to present a software statement — a JWT containing the client's details, signed by a trusted authority. The authorization server verifies this JWT using a known public key (the trust anchor). Per RFC 7591, a software statement is "a digitally signed JSON Web Token (JWT) that asserts metadata values about the client software." The trust relationship the auth server has with the issuer of this JWT determines whether registration is accepted.

The Complete Onboarding Flow

1. 1
   Trust Onboarding

   Out-of-band, the enterprise and SaaS provider agree to integrate. The SaaS provider is added to the enterprise's Trust Registry. The registry generates a software statement JWT for the provider's application, or the provider supplies one from an agreed authority.

2. 2
   Discovery

   The new AI agent or MCP discovers the other party's authorization server metadata via a .well-known endpoint — authorization, token, and registration URLs.

3. 3
   Dynamic Client Registration

   The AI client submits a POST /register request to the authorization server, including its metadata (redirect URIs, contact info, desired scopes) and the signed software statement. The request is authenticated — commonly via mutual TLS or a JWS signed with a private key verifiable against the statement.

4. 4
   Validation

   The authorization server verifies the software statement JWT: checks the issuer (iss) is the trusted authority, fetches the issuer's JWKS to verify the signature, validates claims (expiration, audience, software ID). If any check fails, registration is denied.

5. 5
   Client Provisioning

   The authorization server creates a new client record, assigns a client ID, and generates credentials (client secret or public key setup for JWT-based auth). The response contains the client ID and credentials.

6. 6
   Registration Outcome

   The AI agent now has OAuth credentials. Both parties have a record of this client. The SaaS agent or service is onboarded in a controlled manner — its identity was only issued because it was in the trust registry.

Scenario 1: Internal Agent → External SaaS MCP

An internal AI agent needs to call an external SaaS-hosted MCP to utilize external AI tools or data. The enterprise must ensure outbound calls are secure and controlled — the agent should only access SaaS endpoints with proper authorization, and the SaaS should trust that the call comes from a legitimate client.

• The enterprise agent discovers the SaaS OAuth endpoints via documentation or OAuth discovery document.
• If the SaaS requires registration, the agent registers dynamically — supplying a software statement if the SaaS has whitelisted the enterprise via a trust program.
• The SaaS authorization server creates a new client and returns a client ID (and secret or certificate requirements).
• At runtime, the agent performs an OAuth flow to get a token — client credentials if acting as itself, or authorization code if acting on behalf of a user.
• The agent calls the SaaS MCP API presenting the access token in the Authorization header.
• The SaaS MCP validates the token and serves the request. All actions are logged.

Scenario 2: External Agent → Internal MCP

This scenario flips the perspective: a SaaS-hosted AI agent needs to call into an enterprise's MCP server or APIs. The enterprise hosts the protected resource and the external agent is the OAuth client. This is analogous to a third-party app trying to access a company's API — a high-risk operation without proper controls.

1. 1
   Trust Establishment

   The external SaaS provider is onboarded in the enterprise's Trust Registry. The enterprise may issue the provider a signed software statement JWT and share its OAuth endpoints.

2. 2
   Dynamic Client Registration

   The external AI agent calls the enterprise's /register endpoint, including the software statement. The call uses mutual TLS or signed JWT auth so the enterprise can confirm the caller's identity matches the statement.

3. 3
   Validation

   The enterprise auth server verifies the software statement signature against the trust registry's public key. If valid, it creates a client record for the external agent with a client ID and credentials.

4. 4
   Token Request

   When the external agent needs to perform an action, it uses its client credentials to obtain an access token. This could be a client credentials grant (machine client) or authorization code grant if acting on behalf of an enterprise user.

5. 5
   Access Enforcement

   The agent calls the enterprise MCP API with the access token. The MCP server validates the token — checking signature (JWT) or calling an introspection endpoint — then executes the allowed action. The entire transaction is authorized under the token's scopes and logged with client ID, resource, and timestamp.

This pattern mirrors the approaches used in open banking and data-sharing ecosystems. Before an external agent ever gets a token to access your data, it must prove its identity and authorization via the registration step. Without a trust registry entry, registration is rejected outright.

Real-World Analogies: Open Banking & CDR

These patterns aren't theoretical — they're proven at scale in regulated industries where third-party integrations are common and highly regulated.

These real systems prove that combining OAuth with a trust framework scales to large ecosystems. They address the same fundamental challenge we have with SaaS AI integration: how to let in external code to sensitive APIs without giving up security or control.

Security Without Sacrificing Agility

Looking Ahead: OpenID Connect Federation

In this article, we focused on explicit trust lists and signed statements to federate identity of clients. In Part 5 of this series, we explore emerging standards like OpenID Connect Federation for automating these trust relationships — using hierarchical trust and signed metadata to further reduce manual coordination. But even without full federation, the approach outlined above is a powerful way to securely integrate SaaS AI today.

Inviting a SaaS-hosted AI agent into your enterprise need not equate to inviting chaos. The External SaaS Pattern enables a careful balance: frictionless integration for trusted partners, but significant roadblocks for anything untrusted.