Vercel WAF AI Rules: How Do You Protect a B2B SaaS Site?

Vercel shipped two infrastructure updates this week that matter for any B2B SaaS site running a Webflow marketing layer in front of a Vercel-hosted product. On May 12, 2026 Vercel Firewall added natural-language WAF custom rule generation. On May 13, 2026 Vercel shipped Trusted Sources, an OIDC-based replacement for long-lived Protection Bypass for Automation secrets. For Phoenix Studio's typical B2B SaaS clients, the marketing site lives on Webflow and the API endpoints behind it live on Vercel. The form leads from the marketing site post to those endpoints. The rate-limit and auth boundary lives in Vercel Firewall, which is why this week's updates matter even for clients I would describe as Webflow shops. In this piece I walk through what changed and the practical migration pattern.

What did Vercel ship on May 12 and 13, 2026?

Vercel shipped two infrastructure features this week. On May 12, 2026 Vercel Firewall added natural-language WAF custom rule generation, letting users describe the desired rule in plain English and have the dashboard build the underlying regex. On May 13, 2026 Vercel shipped Trusted Sources, an OIDC-based authorization mechanism that replaces long-lived Protection Bypass for Automation secrets with short-lived tokens.

Both features are documented in the Vercel Changelog. The Vercel Firewall docs and the Trusted Sources documentation cover the implementation details. For B2B SaaS sites that have shared Protection Bypass for Automation tokens across CI environments for months, the May 13 release is the higher-priority change because the migration removes a real long-lived secret from the deployment pipeline. The May 12 release is a quality-of-life improvement on rule authoring that matters most for teams writing new rules this month.

How does natural-language WAF rule generation actually work?

Natural-language WAF rule generation works by accepting a plain-English description of the desired rule behavior and producing the underlying regex or condition syntax that Vercel Firewall executes. The user describes the rule, the dashboard generates the implementation, the user reviews and edits if needed, and the rule is saved. The AI generation is a Vercel-managed feature backed by an OpenAI model.

The practical pattern is to describe a rule in clear, specific language. "Rate-limit POST requests to /api/leads to 60 per minute per IP" produces a different rule from "slow down lead form submissions." The first is specific and produces a clean rule. The second is vague and produces a rule that needs significant editing. The discipline I am developing this week is to write the rule description as if writing a clear ticket for a junior engineer, not as a casual request. The AI-generated rule is the starting point, not the final artifact.

Why should I audit the AI-generated rule before saving it?

Audit the AI-generated rule before saving because the dashboard's regex or condition syntax may not exactly match the intent described in natural language. The most common discrepancy is over-broad matching, where the rule blocks more traffic than intended. The second most common is under-specified scope, where the rule misses the specific endpoint or method intended. Both errors are easy to catch in review and expensive to debug in production.

For Phoenix Studio's B2B SaaS clients, the audit pattern is to read the generated regex line by line and confirm it matches the natural-language description. If the regex includes a wildcard where a specific path was intended, edit it. If the method matcher is missing or wrong, fix it. The 60 seconds spent on audit prevents the 3-hour debug session when a marketing form starts failing at 2 AM because the WAF rule was too aggressive. This is the same discipline I covered in the broader Webflow security header pattern, applied to a different edge configuration.

What is Trusted Sources OIDC and how does it differ from Protection Bypass?

Trusted Sources is a Vercel feature that uses OpenID Connect tokens to authorize automation requests, replacing the long-lived Protection Bypass for Automation secret. The OIDC tokens are issued by trusted identity providers like GitHub Actions, GitLab CI, and other CI vendors that support OIDC. The tokens are short-lived and scoped, which means a compromised CI environment exposes a token that expires quickly rather than a static secret that lives forever.

The structural difference matters for security operations. A Protection Bypass for Automation secret is a long-lived string that grants the same permissions as long as the secret is valid. If the secret leaks, the bypass is open until someone rotates it. An OIDC token is a short-lived string that is verified against an identity provider on each use. If a token leaks, the exposure window is minutes to hours, not the months that Protection Bypass secrets often persist. The OpenID Connect specification at openid.net documents the underlying protocol.

How does this connect a Webflow marketing site to a Vercel-hosted product API?

The connection between Webflow marketing and a Vercel-hosted product API typically runs through form submissions. A contact form, demo request, or trial signup on the Webflow site posts to a Vercel-hosted API endpoint. That endpoint validates the submission, stores the lead, and triggers downstream actions like CRM updates or welcome emails. The traffic between Webflow and Vercel passes through the Vercel Firewall, which is where the WAF rules and the Protection Bypass or Trusted Sources authorization apply.

For Phoenix Studio's B2B SaaS clients with this architecture, the May 12 and May 13 updates affect two parts of the integration. The WAF rule generation makes rate-limiting the form endpoint easier to author. The Trusted Sources migration removes a long-lived secret that the Webflow-to-Vercel integration may have been using if the CI pipeline deploys both sides. The piece I wrote on Webflow Premium's expanded Cloud limits covers the Webflow side of related infrastructure changes from the same week.

Should I migrate off Protection Bypass for Automation this sprint?

Yes, if your CI environment shares the Protection Bypass for Automation secret across multiple deploys or has held the secret for more than 90 days. The migration to Trusted Sources is a small operational lift, typically one pull request and one configuration change in the Vercel project settings. The security benefit is real and immediate: the long-lived secret is replaced with short-lived OIDC tokens that limit blast radius if the CI environment is compromised.

For Phoenix Studio's clients, the migration pattern is to enable Trusted Sources in the Vercel project settings, configure the trusted identity providers used by the CI pipeline, update the CI workflow to use OIDC tokens instead of the bypass secret, verify the workflow continues to deploy successfully, and then disable the Protection Bypass secret. The full migration takes about 30 to 60 minutes per project, and the rotation calendar that tracked the bypass secret can be deleted afterward. The simpler operational posture compounds across the client portfolio.

When does natural-language WAF make sense vs hand-written rules?

Natural-language WAF makes sense for new rules that have clear, specific intent and a small number of conditions. It struggles with complex rules that need to combine multiple conditions, depend on context across multiple requests, or use advanced regex features like lookahead and lookbehind. Hand-written rules remain the right choice for complex security logic and for rules that need to be auditable by external security teams.

The practical pattern for B2B SaaS sites is to use natural-language generation for the simple cases that make up 80 percent of new rules (rate limiting, IP allow-listing, method enforcement) and to write the remaining 20 percent by hand. The natural-language tool is a productivity boost for the simple cases and a distraction for the complex ones. Knowing which case the current rule fits into is the discipline that earns the time savings without creating new debugging burden.

Does the AI Gateway Claude Opus 4.7 fast mode change anything for forms?

Vercel's AI Gateway has added support for Claude Opus 4.7 in a fast mode optimized for low-latency responses. For Webflow marketing forms that include an AI-powered acknowledgment or follow-up after submission, the fast mode reduces the time between form submission and AI-generated response. The change matters for forms with conversational follow-up, not for forms with simple thank-you pages.

For Phoenix Studio, the practical implication is that any client running an AI acknowledgment on a Webflow form gets faster perceived performance without code changes if the underlying API calls go through Vercel's AI Gateway. The migration is configuration-only on the Vercel side. The Webflow form submission flow remains unchanged. The piece on the Code with Claude product stack covers the broader Anthropic agent surface that connects to the AI Gateway architecture.

How does Vercel Firewall compare to Cloudflare's May 15 Logpush update?

Vercel Firewall and Cloudflare's edge security products serve overlapping but distinct purposes. Vercel Firewall is tightly integrated with Vercel-hosted applications and provides WAF, rate limiting, and authorization within the Vercel deployment context. Cloudflare's security suite is broader, covering DNS, CDN, WAF, and more, and is provider-agnostic. The May 15 Cloudflare Logpush update improved the observability side of Cloudflare's security suite.

For B2B SaaS sites that run Webflow in front of Vercel, the typical pattern is to use Cloudflare for DNS and the broader CDN layer, and to use Vercel Firewall for the application-specific security at the Vercel edge. The two products complement rather than compete. The May 12 and May 13 Vercel updates and the May 15 Cloudflare update together suggest the edge security tooling is improving across vendors in parallel, which is good news for sites running multi-vendor stacks.

Will agentic deploys make these rules go stale faster?

Possibly, yes. Agentic deploy systems like the ones shipped at Code with Claude 2026 generate deployments at a faster cadence than traditional human-driven CI workflows. Rules that worked for a weekly release cadence may become stale faster when deploys happen multiple times per day. The discipline of regularly reviewing WAF rules and OIDC trust configurations becomes more important, not less.

The practical pattern at Phoenix Studio is to audit WAF rules quarterly for any client on a fast-moving deploy cadence, and to revisit Trusted Sources configurations when CI pipeline changes happen. The audit takes 30 minutes per quarter and prevents the common failure pattern where a rule that worked six months ago has drifted out of usefulness without anyone noticing. The piece on domain and edge-routing context covers the broader edge configuration discipline that pairs with WAF rule management.

If you are running a B2B SaaS site with Webflow marketing in front of a Vercel-hosted API and want to talk through the May 12 and 13 update migration plan for your specific stack, drop me a line and tell me what your current WAF and bypass configuration looks like. I will share the Trusted Sources migration pattern I am running on Phoenix Studio client sites this week. Let's chat.