A vendor evaluation framework for enterprise security teams, and a readiness guide for the B2B SaaS vendors who want to pass it.
Before your organization connects an AI agent to any external tool via Model Context Protocol, your security team needs clear answers from every vendor in that chain. This isn't optional due diligence. MCP servers operate beneath the application layer, which makes issues difficult to detect after the fact. Pynt's 2025 analysis of 281 MCP implementations found that ten interconnected servers push exploitation probability to 92%. The time to ask these questions is before enablement, not after the incident.
If you're a B2B SaaS vendor reading this: these are the questions your enterprise customers are going to ask. Having prepared, accurate answers is a sales asset. Share this page with your security and product teams before your next enterprise deal enters the security review phase.
How to Use This Document
CISOs: use these ten questions in your vendor security intake process for any SaaS product that exposes an MCP server or participates in an AI agent workflow. A vendor that can answer all ten clearly is materially lower risk than one that can't answer half of them.
SaaS vendors: use this as a gap analysis. Each question maps to a security control. If you can't answer a question today, that's your roadmap item. The vendors who close these gaps first will win enterprise deals faster.
A co-branded PDF version of this checklist is available for SaaS vendors to share with their own enterprise customers. Use it as a "we answer all of these" leave-behind in your security review process.
Question 1: What Authorization Model Does Your MCP Server Use?
What the CISO is really asking: Does this server implement proper OAuth 2.1 with PKCE, or is it running some custom auth scheme that hasn't been audited?
The November 2025 MCP specification mandates OAuth 2.1 with PKCE (Proof Key for Code Exchange) for all remote HTTP connections. Any vendor who says they use a "custom token" approach or "API keys only" for remote MCP connections is running outside the spec, which means outside the security model the specification was designed to enforce.
What a good answer looks like:"Our MCP server implements OAuth 2.1 with PKCE S256 for all remote connections. We support RFC 9728 (Protected Resource Metadata) for authorization server discovery. The implicit grant flow is disabled. Local connections use environment-inherited credentials per the MCP stdio transport spec."
Why it matters for your org: A vendor that hasn't implemented PKCE is vulnerable to authorization code interception attacks. CVE-2025-6514 in the mcp-remote library, downloaded over 500,000 times, demonstrated how auth-adjacent code failures translate to arbitrary code execution on developer machines. Spec-compliant auth is the baseline, not a bonus.
Question 2: How Does Your MCP Server Integrate with Our Identity Provider?
What the CISO is really asking: Can our Okta or Azure AD policies actually govern this thing, or is it running a parallel identity system we don't control?
Enterprise identity governance runs through the corporate IdP. If a vendor's MCP server creates its own user session layer that doesn't talk to Okta, Azure Active Directory, or Google Workspace, then your centralized access controls, your MFA policies, and your deprovisioning workflows all have a gap. A terminated employee's MCP sessions may survive their identity provider deactivation by days or weeks.
What a good answer looks like:"Our MCP server integrates with enterprise IdPs via SAML 2.0 and OIDC. SSO sessions are bound to the customer's identity provider. When a user is deprovisioned in your IdP, their MCP server access is revoked within [timeframe]. We support Okta, Microsoft Entra ID, Google Workspace, and any standard SAML/OIDC-compliant IdP."
Why it matters for your org: IdP integration isn't just a convenience feature. It's the mechanism that makes your existing governance policies enforceable. Without it, your MFA mandate, your conditional access policies, and your automated offboarding workflows stop at the edge of the vendor's system. For guidance on how this integration should work architecturally, see SSOJet's breakdown of OIDC and SAML in multi-tenant deployments.
Question 3: How Are Agent Identities Managed Separately from Human Identities?
What the CISO is really asking: When an AI agent calls your APIs, can we tell it apart from a human? Can we revoke it independently?
This is the question most SaaS vendors aren't ready for yet. AI agents operating as non-human identities need their own credential lifecycle: creation, scoping, rotation, and revocation, all independent of the human user who authorized them. If an agent's credentials are indistinguishable from a human user's session token, your SOC team can't tell during an incident whether they're looking at a user action or an automated pipeline.
What a good answer looks like:"AI agents authenticate using OAuth 2.0 Client Credentials flow, separate from the user OAuth flow. Each agent identity is issued a distinct credential with a documented scope, a defined lifetime, and a revocation endpoint. Agent-initiated API calls are tagged with a non-human identity marker in all audit logs. Admins can revoke agent credentials without affecting the associated human user session."
Why it matters for your org: The OWASP GenAI Security Project identifies agent identity management as a core security domain. Without distinct agent identities, you can't scope permissions correctly, can't revoke cleanly, and can't reconstruct agent activity in a forensic review.
Question 4: What OAuth Scopes Does Your MCP Server Request, and Can They Be Restricted?
What the CISO is really asking: Is this server requesting the minimum permissions it needs, or is it asking for everything because that was easiest to configure?
Over-scoped OAuth grants are one of the most common MCP security failures. A server that requests read:all write:all admin when it only needs read:calendar gives a compromised or manipulated AI agent a blast radius far beyond what the use case requires. And because agents operate autonomously, a broad scope doesn't just affect one session. It affects every session that agent ever runs.
What a good answer looks like:"Our MCP server requests the minimum OAuth scopes required for each tool function. Scopes are documented per tool in our security overview. Enterprise customers can restrict available scopes at the tenant level through our admin portal. We implement Resource Indicators (RFC 8707) to bind tokens to specific resource servers, preventing token reuse across services."
Why it matters for your org: Least-privilege scoping is the difference between a contained incident and a full breach when an agent is manipulated. Ask the vendor for their scope documentation. If they can't produce it, that's your answer.
Question 5: How Does Your Platform Prevent Prompt Injection Attacks Through MCP Tool Results?
What the CISO is really asking: If our employees use your AI tools and an attacker poisons a data source your agent reads, what stops the agent from being hijacked?
Prompt injection in MCP environments is SQL injection for the AI age. An attacker who can insert content into a source that your agent reads (an email, a support ticket, a web page, a document) can instruct the agent to take actions the authenticated user never authorized. In mid-2025, Supabase's Cursor agent processed user-supplied support ticket content as executable commands, leaking sensitive tokens into a public thread. Real incident. Real damage.
What a good answer looks like:"Tool results from external or user-supplied sources are sanitized before re-entering the agent's instruction context. We apply output encoding to tool results and strip patterns that match credential formats. High-risk tool invocations (data export, permission changes, external communications) require explicit human confirmation before execution. Our agent pipeline separates the data plane from the control plane."
Why it matters for your org: If a vendor's answer to this question is blank or vague, their MCP server is a prompt injection target. Pynt's research found that 13% of MCP implementations accept untrusted inputs from sources like web scraping and inbound email without sanitization. Ask for a specific technical description of their input handling. Vague commitments don't protect your data.
Question 6: What Is the Token Lifetime Policy for MCP Sessions, and How Is Rotation Handled?
What the CISO is really asking: If a token is compromised, how long does the attacker have a valid credential, and how quickly can we invalidate it?
Long-lived tokens are one of the most persistent security anti-patterns in API design. In MCP environments, where tokens may be issued to AI agents operating unattended for extended periods, unrotated long-lived tokens represent a standing risk. A token that never expires and never rotates is a credential waiting to be stolen and used indefinitely.
What a good answer looks like:"Access tokens issued for MCP sessions have a maximum lifetime of [X] minutes. Refresh tokens are rotated on each use. Tokens are bound to the originating session and cannot be transferred. Administrators can invalidate all active tokens for a user or agent identity from the admin console, with revocation taking effect within [timeframe] across all active sessions."
Why it matters for your org: Short token lifetimes limit the blast radius of a credential theft. Refresh token rotation means a stolen refresh token can only be used once before it's invalidated. Ask specifically about the default lifetime values and whether your security team can configure them. Many vendors have long defaults that were never revisited after initial configuration.
Question 7: What Does Your Audit Trail Cover for Agent-Initiated Actions?
What the CISO is really asking: When something goes wrong and our IR team needs to know what an AI agent did over the past 72 hours, can your platform tell them?
Most SaaS audit logs were designed for humans clicking through a UI. Agent-initiated API calls often bypass the UI action layer entirely, which means they bypass the logging hooks that capture user activity. If your vendor's audit log only captures human sessions, every agent action is a forensic blind spot.
What a good answer looks like:"Every MCP tool invocation is logged in our immutable audit trail, regardless of whether it was initiated by a human user or an AI agent. Log entries include: authenticated identity (with human/machine tag), tool called, input parameters (sanitized), response status, and timestamp. Logs are retained for [X] days on Enterprise plans and are exportable via API and our admin console. We support SIEM integration with Splunk, Datadog, and Elastic."
Agent audit coverage is now appearing in standard enterprise security questionnaires. SaaS vendors who have built this capability with SSOJet's identity and audit infrastructure arrive at those reviews with a concrete answer rather than a gap. The SSOJet enterprise SSO requirements checklist maps exactly what enterprise buyers look for in this area.
Why it matters for your org: GDPR, SOC 2, and most enterprise security policies require audit trail coverage of all access to sensitive data, whether by humans or automated systems. An agent that can read your data but isn't logged is a compliance gap and an IR liability.
Question 8: How Does Your MCP Server Handle Cross-App Access and Token Audience Validation?
What the CISO is really asking: Can a token issued for your product be accepted by a different vendor's service, intentionally or by accident?
The confused deputy attack in MCP environments works by exploiting the absence of token audience validation. An attacker tricks an MCP server acting as a proxy into using its own elevated credentials for a request that should have been scoped to the user's permissions. Or they present a token issued for one service to a different service that doesn't validate the aud claim. Either way, the access control boundary breaks.
What a good answer looks like:"All tokens issued by our authorization server include an aud claim scoped to our specific resource server identifier. Our MCP server validates the audience claim on every inbound request and rejects tokens with a mismatched or absent aud. We implement Resource Indicators (RFC 8707) to ensure tokens cannot be reused across different resource servers. Our server never forwards tokens received from MCP clients to upstream APIs; it obtains separate, independently scoped tokens for each downstream service."
Why it matters for your org: Audience validation is a one-line check that prevents an entire class of token reuse attacks. The fact that many MCP servers skip it is not a spec ambiguity. The June 2025 MCP specification explicitly prohibited token passthrough. Any vendor still doing it is running a known-vulnerable configuration.
Question 9: Do High-Risk Actions Require Human-in-the-Loop Confirmation?
What the CISO is really asking: Is there a human checkpoint before an AI agent does something irreversible, like deleting data, sending an email, or modifying permissions?
This is the governance question that separates "AI tools we can deploy to the enterprise" from "AI tools that will eventually cause an incident." Autonomous agents are valuable precisely because they don't require human approval for every action. But some actions carry enough consequence that human confirmation should be mandatory, not optional.
What a good answer looks like:"Our platform distinguishes between read-only and write/destructive tool operations. Write operations, communications to external parties, permission changes, and data exports require explicit user confirmation before execution. The confirmation requirement is configurable by tenant administrators. Our tool annotations follow the MCP spec's read-only and destructive flags, which are surfaced to agent orchestrators to enforce appropriate approval flows."
Why it matters for your org: The MCP March 2025 spec introduced Tool Annotations (readOnly, destructive, idempotent) specifically to give orchestrators the metadata they need to apply appropriate human oversight. Any vendor who hasn't implemented these annotations or doesn't expose them to your security configuration is giving you less control than the spec allows.
Question 10: What Is Your Incident Response Path When an MCP Session Is Compromised?
What the CISO is really asking: If we call you at 2am because something is wrong, what happens? Who does what, and how fast?
Incident response for MCP compromises is different from a traditional credential theft. An agent compromise may have been running for hours before detection. The blast radius may span multiple tool integrations. And the initial vector may be a prompt injection that leaves no obvious credential theft signature in your logs.
What a good answer looks like:"We maintain a documented incident response process specific to MCP session compromises. Immediate actions available to tenant admins include: single-click revocation of all active tokens for any user or agent identity, session termination across all active MCP connections, and export of the complete audit trail for the affected identity. We commit to notifying affected customers within [48/72] hours of confirming a breach. Our security contact is reachable at security@[vendor.com] 24/7. We publish our incident response SLA in our MSA."
Why it matters for your org: The ability to contain an MCP compromise depends entirely on the vendor's revocation speed and your team's ability to reconstruct the timeline. A vendor who can't tell you the revocation latency, or who doesn't have a 24/7 security contact, is a containment liability.
The Vendor Scorecard
Use this when evaluating any SaaS vendor with MCP server exposure. Score each question: 2 points for a clear, specific answer; 1 point for a partial answer; 0 for "we're working on it" or no answer.
|
Question
|
Score
1
|
OAuth 2.1 + PKCE authorization model
|
/2
|
|
2
|
IdP integration and deprovisioning
|
/2
|
|
3
|
Agent identity management
|
/2
|
|
4
|
Least-privilege scopes and restriction
|
/2
|
|
5
|
Prompt injection prevention
|
/2
|
|
6
|
Token lifetime and rotation
|
/2
|
|
7
|
Agent-aware audit trail
|
/2
|
|
8
|
Cross-app access and audience validation
|
/2
|
|
9
|
Human-in-the-loop for high-risk actions
|
/2
|
|
10
|
Incident response path
|
/2
|
|
Total
|
|
/20
|
16-20: Strong security posture. Proceed with standard procurement process.
10-15: Meaningful gaps. Request a technical security review and remediation commitments before approval.
Below 10: Do not enable in production environments until gaps are resolved. Flag for CISO escalation.
Frequently Asked Questions
What Is an MCP Server in Enterprise Security Context?
An MCP (Model Context Protocol) server is an external service that AI agents connect to in order to use tools, access data sources, or call APIs. In enterprise deployments, MCP servers act as integration points between AI assistants (like Claude, Copilot, or custom agents) and business systems. Because they operate with delegated user permissions and often process untrusted external content, they introduce authentication and authorization risks that require explicit security governance.
Why Are These Questions Different from Standard SaaS Security Reviews?
Standard SaaS security reviews focus on how humans access a system. MCP security reviews add a second principal: the AI agent. Agents operate autonomously, process untrusted inputs, and can take actions at machine speed without human review. This creates attack surfaces like prompt injection and confused deputy vulnerabilities that don't exist in human-only access models. The ten questions above specifically address the agent-native threat model.
Which of These Ten Questions Are Most Likely to Surface Gaps?
Questions 3 (agent identity management), 7 (agent-aware audit trail), and 9 (human-in-the-loop for high-risk actions) surface gaps most often because they require MCP-specific engineering work that many vendors haven't done yet. Questions 1 and 8 (OAuth 2.1 and audience validation) are gaps in older implementations built before the March and June 2025 MCP spec updates.
Can B2B SaaS Vendors Use This Document as a Sales Asset?
Yes. That's one of the intended uses. A vendor who can answer all ten questions with specific, accurate responses has a meaningful security posture advantage over competitors who can't. Sharing this document with enterprise prospects as a "here's what you should ask every MCP vendor, and here's how we answer each one" asset is a legitimate and effective enterprise sales motion.
If You're a SaaS Vendor: Close These Gaps Before the Next Deal
Every question in this document maps to a control. Some are configuration changes. Some are documentation gaps. Some require engineering work. But none of them require rebuilding your auth system from scratch, if you have the right infrastructure underneath.
SSOJet directly addresses the identity layer questions in this guide: IdP integration
(Question 1), agent identity management
(Question 2), least-privilege scopes
(Question 3), agent-aware audit logging
(Question 4), and token lifecycle controls
(Question 5). It ships as an add-on layer to your existing auth system.
Most teams are live in under a week.
The enterprise buyers using this checklist are making a binary decision: approve or escalate. A vendor who arrives at that conversation with complete answers moves forward. A vendor who arrives with gaps gets a remediation request and a 60-day hold.
Start with the SSOJet enterprise SSO and identity checklist to see where you stand today.
Top comments (0)