This article explains what changes for administrators upgrading the Cequence Unified API Protection (UAP) platform from release 8.x to release 9.1. It applies whether Cequence performs the upgrade for a SaaS tenant or your team performs an on-premises upgrade.

Release 9.1 introduces a new generation of the API Security engine that brings meaningful improvements in scale, functionality, and effectiveness. Because the underlying data model changed, the upgrade from release 8.x is not a transparent, drop-in update. This article walks through what carries forward, what changes, what's new, and what's temporarily deprecated, so you can plan the upgrade with no surprises.

Data loss. Some of the changes described in this article are disruptive. Inventory and risk data do not carry forward automatically from release 8.x.

Data-plane prerequisites

Release 9.1 requires your data plane to be current before you upgrade the control plane. Your Defender must be on release 6.3 or later. Your Network Sensor must be on release 5.2 or later, and the Cequence Bridge, eBPF sensors, and sensor-bridge plugins should also be current. A newer platform release works against an older Defender, but an older Defender does not honor release 9.1's new parameterization behavior, so the data plane needs to lead rather than follow. Verify your current platform and Defender versions with Cequence Support for a SaaS tenant, or check your on-premises deployment manifests, before scheduling your upgrade window. If you are not yet on release 8.7 with Defender 6.3, plan for the intermediate hop first.

Specs, ticketing configuration, sensitive data expressions, and IP ranges carry forward automatically as part of the upgrade. You do not need to re-enter these.

What carries forward unchanged

The following continue to work exactly as they do today, including your existing configuration.

• Sensitive Data Expressions (SDEs). Both custom and system expressions carry forward.
• Ticketing integrations. Your Jira and ServiceNow connectors and their configuration carry forward.
• Specifications. Your uploaded or generated API specs migrate automatically.
• Reports.
• Authentication types and scopes. System-defined types and scopes are preserved and applied correctly after the upgrade. Custom authentication types are handled differently.

Specs migrate through a one-time, automatic migration step that runs immediately after the upgrade completes. The step is safe to run again if needed and is idempotent, so running it again does not create duplicate specs. If an individual spec fails to migrate, the platform logs it for follow-up rather than dropping it silently.

What's changing

Your endpoint inventory, risk findings, and issues do not carry over from release 8.x. They rebuild from live traffic after the upgrade. Cequence's internal testing shows inventory and risk posture returning to a representative state within roughly two days of traffic flowing, though the timing depends on your traffic volume and patterns.

API inventory

Release 9.1 re-architects the inventory to scale to millions of endpoints and thousands of specs. Three effects follow.

• Inventory is now defined as method, host, and path. A single path served on five different hosts, previously shown as one endpoint, now appears as five distinct endpoints. This is expected. It is not a data-loss gap, and it means your total endpoint count is likely to look larger than before once traffic repopulates it.
• The relative path field is retired. Each endpoint now carries only a full path.
• You can track repopulation progress under Settings Diagnostics System Usage (the Usage Dashboard, introduced in release 8.6).

By default, release 9.1 also filters invalid endpoints out of inventory. See Invalid endpoints filtered out of inventory by default under New in release 9.1, later in this article.

Terminology change. "Published" is now Documented. "Discovered" is now Undocumented. "Shadow" is unchanged. See the terminology quick reference at the end of this section.

This data-model change is also what enables Cequence to layer richer threat context on top of visibility and risk in an upcoming release. The near-term disruption buys long-term capability.

Parameterization

Release 9.1 introduces a new parameterization engine with capabilities beyond what release 8.x offered.

• Host-based parameterization. Parameterize at the host level, for environments such as IoT or device fleets, where the variable element lives in the hostname or subdomain itself rather than the path.
• Preceding-element parameterization. Parameterize whatever comes after a specific keyword, regardless of path depth. For example, a rule targeting the element after /users/ correctly collapses /api/users/bob and /api/v2/accounts/users/alice alike, without needing a separate rule for each path shape.
• Exclusions. Add exclusions to any parameterization rule for paths that should be left alone even if they would otherwise match.
• Preview impact. Before you save a new rule, see which existing endpoints it would affect, up to roughly 1,000, so you are not guessing at the blast radius.

What you'll need to redo. Recreate any custom parameterization rules from release 8.x in the new interface. They are not migrated automatically. System, or built-in, rules do not need to be recreated.

Behavior change. Unlike release 8.x, release 9.1 does not parameterize Shadow endpoints. This is intentional. Parameterization is now governed by the associated API specification, so a parameterization need on a Shadow endpoint signals that the endpoint should be documented, rather than a gap to patch around.

Risk posture rules

A new rules interface, built on CEL (Common Expression Language) for writing conditions, replaces the release 8.x risk engine.

• You can now test rules against sample traffic before enabling them, and suppress or clear issues in bulk directly from the rule. See Clear all issues associated with this risk under New in release 9.1, later in this article.
• Release 9.1 ships with more than 260 built-in rules across roughly 25 categories, but only the Security Posture category, which contains two rules (Sensitive Data Exposure and No Authentication Detected), is enabled by default, regardless of how many rules you had enabled in release 8.x.

Why only two rules by default. This is a deliberate, staged-rollout design, not an oversight. Many other rules, including the OWASP API Top 10, depend on you configuring these two foundational rules correctly first: setting up authentication types and tuning sensitive data expressions. Enabling everything at once before that groundwork is done tends to misfire. Triage findings from the two default rules, get authentication and sensitive-data detection right, and then enable additional categories deliberately.

Issues. The new rules engine replaces the release 8.x risk engine entirely. As a result, issues generated under release 8.x, including any you marked In Progress or False Positive, are not viewable in release 9.1 once the upgrade completes. Those issues were tied to release 8.x risk rules that no longer exist in the new engine, so there is no mechanical way to carry them forward as they were.

Issue history loss. This is a real change for teams that track issues day to day, and this article states it plainly rather than let you discover it after the fact. Nothing is permanently lost. Once you enable the equivalent release 9.1 risk category and matching traffic flows through, the same underlying condition regenerates the issue under the new engine. You are not starting from zero, only from a clean slate. That clean slate brings a real benefit. The new rules engine scales further, is easier to tune, and enables you to test a rule against sample traffic before it goes live, so the issues you see going forward better reflect genuine findings, with fewer false positives to sift through.

What you'll need to redo. Recreate custom risk rules from release 8.x in the new rules engine. The new interface's test capability makes this more reliable than before. You can validate a rule's behavior before turning it on.

Tickets. Tickets created in Jira or ServiceNow under the old rules continue to exist in those ITSM systems as before, but the links to those tickets from the release 9.1 Issues interface are no longer available. If you have tickets still in progress under release 8.x rules, plan to track their resolution directly in your ITSM system rather than through the platform Issues view.

Authentication types

System-defined authentication types carry forward automatically, as noted earlier in this article. However, any custom authentication types you configured in release 8.x are not migrated. Recreate them manually in the release 9.1 interface after the upgrade completes.

Until you recreate custom authentication types, traffic that used to match those custom auth patterns is evaluated as if no matching authentication type exists, which can trigger false positives on the No Authentication Detected rule. Recreate custom authentication types early in your post-upgrade triage, before you enable risk categories beyond the default Security Posture set.

Spec generation

• Spec generation is simplified, with one tradeoff in the short term: a generated spec can specify only one host. If your API spans multiple hosts, add the additional hosts through the spec-update process afterward. This is an extra step for now. Automatic multi-host generation and management is targeted for a future release.
• Deleting a spec no longer deletes its endpoints. Endpoints associated with a deleted spec transition from Documented back to Undocumented rather than disappearing. This supports re-parameterization workflows for large environments. If you use Cequence-generated specs and need to adjust parameterization, delete the spec (optionally deleting its associated risk issues too), re-run parameterization rules, and regenerate the spec once the Undocumented inventory reflects the parameterization you want.
• Bulk spec upload and deletion are not yet available in release 9.1 and are planned for a future release. Specs are added one at a time for now.

APIs for integration

Release 9.1 replaces the limited set of GUI-only APIs from release 8.x with a full set of documented, versioned APIs, supporting both headless or automated operation and traditional use cases such as data export.

What you'll need to redo. Custom integrations built against the old release 8.x APIs fail against release 9.1. Rebuild them against the new API surface. The built-in AI Assistant or MCP-based tooling is a good candidate to accelerate this work. See the AI Assistant section later in this article.

Posture Management dashboard

Some widgets present in the release 8.x Posture Management dashboard do not carry over in this release. Replacement and expansion of dashboard widgets is planned for a future release based on customer feedback.

Before you upgrade

The items below apply whether Cequence runs your upgrade for a SaaS tenant or your team runs it for an on-premises deployment. They reflect your own configuration and business context, so only you can provide these inputs. Cequence Customer Success and Support are available to help coordinate, especially for SaaS tenants.

New in release 9.1

Beyond the upgrade-specific changes described earlier in this article, this section covers everything new in release 9.1. Release 9.0 was only ever offered to new customers, so all of this is new ground for anyone upgrading from release 8.x.

Invalid endpoints filtered out of inventory by default

What changed. Release 9.1 holds Undocumented and Shadow endpoints to a stricter default standard before adding them to inventory. Only response codes that indicate a real endpoint (2xx or 3xx) qualify. Documented endpoints (those matched to a spec) are unaffected and continue to accept any response code.

Why it matters. This keeps automated scanners and probes hitting nonexistent paths from polluting your inventory counts, so what you see in Undocumented and Shadow inventory more likely reflects real, reachable API surface.

Automatic inventory cleanup on parameterization

What changed. When you upload a spec or create a custom parameterization rule, the platform now automatically collapses and removes the previously seen raw, unparameterized endpoints. Counts update immediately across the inventory, executive summary, and posture dashboards.

Why it matters. This collapses enumerated endpoints for cleaner API inventory. Previously, cleanup was a manual, easy-to-forget step: you would parameterize but still see stale, duplicate entries. This closes that gap automatically.

Clear all issues associated with this risk

What changed. A new bulk action enables you to clear every issue tied to a misconfigured or noisy risk rule in one step. The confirmation dialog shows the issue count before and after the action, so you can see the impact before you commit.

Why it matters. When a rule is mistuned, it can flood you with false-positive issues. You can now reset issues in bulk and re-tune the rule with a clean slate, instead of clearing them one at a time.

Issue-creation cap per risk rule

What changed. Once a single risk rule crosses 1,000 open issues, new issue creation pauses for that rule. The risk itself stays visible. Only new issue creation stops. An in-UI indicator prompts you to tune the rule (through parameterization, authentication, or specs) or manually resume issue creation.

Why it matters. This protects Risk Posture from a single misfiring rule overwhelming it with repetitive findings that bury real findings underneath.

Granular RBAC for Risk Posture

What changed. Release 9.1 introduces new, dedicated Risk Posture Admin and Viewer roles, separate from the existing Inventory Admin and Viewer roles.

Why it matters. This enables you to restrict who can see risk findings versus who can see inventory data, which is useful for organizations such as financial services and telecom companies that separate security-posture visibility from general API-catalog access.

Built-in MCP server

The platform now exposes its capabilities through MCP (Model Context Protocol), the same interface the built-in AI Assistant uses internally. Any MCP-compatible client or agent can connect directly, using the same credential model as any other API integration (a client ID and secret). This opens the platform to automation and tooling beyond a GUI or fixed API surface, including custom reporting workflows. See the AI Assistant section later in this article for more detail.

25 risk categories

Beyond the OWASP API Top 10, release 9.1 organizes its more than 260 rules into roughly 25 categories spanning industry compliance (PCI DSS, HIPAA, GDPR, SOC 2, ISO 27001) and regional frameworks (CDR and APRA for Australia, SAMA for Saudi Arabia, and others). A rule can belong to more than one category, so a single finding may map to OWASP, PCI DSS, and GDPR at the same time. Expect overlap between categories by design, not duplication in error.

New roles for specification and Risk Posture management

Building on the Risk Posture RBAC described earlier in this article, release 9.1 enables you to assign roles so that one group of users can manage API specifications without being able to view Risk Posture issues, and vice versa. This separates who catalogs the APIs from who sees the security findings, where your organization requires that separation.

Ability to clear risk issues in bulk

Several release 9.1 workflows now include a built-in way to clear risk issues that were only ever noise from a misconfiguration, recovering cleanly from a misfiring rule or sensitive data expression without manual, issue-by-issue cleanup.

• Collapsing enumerated endpoints into a single parameterized endpoint.
• Viewing or deleting a spec.
• Creating a new parameterization rule, which also automatically removes the raw, unparameterized endpoints from inventory. See Automatic inventory cleanup on parameterization earlier in this article.
• Viewing or editing a risk rule.

Deprecated in release 9.1

The following capabilities are temporarily unavailable in release 9.1.

Expected back within the next couple of months

• Labels.
• Sensitive Data Exposure dashboard.

No committed return date

Availability depends on customer demand.

• Export to CSV. Cequence plans to enhance and reintroduce it in a future release. There is no committed date yet.
• The Endpoints Discovery sub-pages: Auth Types, Sensitive Data Exposed, and API Hosts views.
• Spec groups. These may return in a future release depending on demand.

The AI Assistant

The AI Assistant is a preview and beta capability in release 9.1. It is genuinely useful today, but still evolving, and this article sets that expectation up front rather than let you find rough edges as a surprise.

The Assistant currently covers API Security use cases only. Bot Management support is planned for a future release.

Built-in agent (SaaS and on-premises)

• SaaS. Uses Cequence's built-in, Bedrock-hosted Anthropic model by default, at no extra setup cost, with a monthly usage allowance per tenant.
• On-premises. The Assistant is disabled by default. Enabling it requires outbound HTTPS access from the platform cluster to Anthropic's API endpoints, or your chosen model provider, configured through a firewall rule, and the Helm flag aiAssistant.enabled: true. If your environment restricts outbound access, contact Cequence Customer Success to assess feasibility before your upgrade.
• Bring your own key (BYOK). Both SaaS and on-premises customers can supply their own Anthropic API key, directly, through Bedrock, or through another accessible model provider, under Settings Integrations AI Configuration. This lifts the default usage allowance and applies your own provider's costs and limits instead.

Example uses for the built-in Assistant

The following are example prompts you can give the built-in Assistant.

• What are the highest-risk APIs in my environment right now?
• Which endpoints expose sensitive data without authentication?
• Write me a custom rule that flags any endpoint with sensitive data in the response and no authentication.
• Generate a PCI DSS compliance report for the last 30 days.

The Assistant is also a practical way to work through the API rebuild required by the custom-integration change described earlier in this article. Ask it to help translate an old custom API call into the new documented API.

Third-party agents

If you already use your own AI agents or tools, such as Claude Desktop, Cursor, or any other MCP-compatible client, you can connect them directly to the platform's MCP server using your existing model of choice. There is no Anthropic key or Helm configuration involved on your side for this path. You authenticate the same way you would for any other API integration.

Custom reporting. By supplying your own report templates to a third-party agent, or to the built-in Assistant, you can generate custom API Security reports, including tailored compliance packages, in your organization's own format rather than a fixed built-in template.

Sample prompt: template-driven custom reporting

Using my Cequence API Security 9.0.x connector, generate a compliance report for <framework> as an HTML file. Reporting window: <date range>. Pull getRiskPosture (pageSize 100), getAssistantContext, and getIssueTrends. Filter client-side to the framework string, for example "GRC: SAMA CSF." Use the cequence_compliance_report_TEMPLATE.html template and Cequence_Logo.png.

Swap the connector version, framework string, date range, template, and logo file for your own environment.

Before, during, and after the upgrade

• Rollback is supported. For a SaaS tenant, trigger rollback from the Ops portal (Actions Platform Upgrade, then select the prior version). For an on-premises deployment, redeploy the applicable 8.6.x or 8.7.x release you upgraded from. In both cases, custom discovery patterns and risk posture rule configurations are restored on rollback, and traffic sent while on release 9.1 is preserved and reflected once you are back on the prior release.
• Release 8.x data is not deleted, only not surfaced. Legacy indices are retained, not deleted, at release 9.1, and cleaned up in a later release. This is what makes rollback safe, and it preserves your release 8.x data for the record even though release 9.1 does not show it in the UI.
• Known post-upgrade UI quirk. If inventory table columns you had previously customized do not display correctly right after the upgrade, this is typically a stale browser preference, not a data issue. Clear the endPointColumnPref entry from your browser's local storage (DevTools Application Local Storage) and reload the page to resolve it.

Terminology quick reference

A phased approach to API security

Rolling out release 9.1's risk engine well is less about flipping every switch on day one, and more about sequencing: proving out the fundamentals first, then expanding coverage deliberately. This section summarizes the Cequence-recommended approach. The full playbook, with the reasoning and detail behind each step, is available as a companion document, "Cequence Platform 9.1: Operationalizing API Security as a Program."

The recommended sequence, in brief, is as follows.

• Start narrow. Enable only the two default Security Posture rules first: No Authentication Detected and Sensitive Data Exposure.
• Maximize discovery. Connect every traffic source you have, and keep adding new ones as they appear.
• Calibrate validity. Verify which response codes should count as a real endpoint for your environment.
• Build and maintain specs. Whether you generate them or Cequence does, keep them current and scope risk rules to approved specs.
• Expand risk coverage gradually. Add the OWASP API Top 10 and GRC categories one at a time once Security Posture is clean.
• Operationalize remediation. Route validated issues to ticketing with clear ownership and audit trails.
• Keep inventory and issues tidy. Use Clear Risk when tuning rules or retiring endpoints and specs.

This is an iterative loop, not a one-time setup. Your traffic, specs, and risk categories keep evolving, and the sequence above is designed to be revisited as they do. Your Cequence Customer Success contact can walk through this playbook with your team and help tailor the pacing to your environment.

Observability and supportability

This section is a placeholder pending finalized observability and supportability guidance for release 9.1. Candidate topics include what to monitor during the post-upgrade inventory and risk rebuild window (the System Usage dashboard cadence and the expected repopulation curve), the support escalation path for failed spec migrations (the spec-migration-status index) or AI Assistant connectivity issues on-premises, the telemetry Cequence Support requests when troubleshooting a release 9.1 upgrade, and any service-level agreements around the rebuild window.