From the Red Hat edition of November 7, 2026
Red Hat OpenShift AI Self-Managed 3.5 release notes, Chapter 7 Known issues: MaaS gateway route hijacking, silent rate-limit and scheduler bypass, FIPS limits
Red Hat · Cross-sector AI platform (applicable to state, local and higher-education OpenShift AI operators) · Global
- Publisher
- Red Hat Documentation
- Original publication
- Undated documentation page (release notes describe OpenShift AI 3.5.2)
- Source retrieved
- 2026-11-08
What happened
Source finding (vendor-documented defects): Red Hat lists known issues in OpenShift AI 3.5 that affect governed model serving. RHOAIENG-80360: default Gateway settings such as allowedRoutes.namespaces.from: All let a user with standard namespace-level permissions attach an HTTPRoute that intercepts traffic to a legitimate model endpoint, exposing API keys, prompts and responses. RHOAIENG-76586: with Red Hat Connectivity Link 1.4.0/1.4.1, rate limiting for batch gateways silently stops. INFERENG-6962: any extra HTTPRoute on a wildcard listener bypasses the llm-d EndpointPicker, silently disabling prefix-cache and load-aware scheduling. RHOAIENG-71638: MaaS returns HTTP 500/503 under high concurrency due to a 200 ms auth timeout (affects 3.4 and 3.5). RHOAIENG-58765: llm-d prefill/decode disaggregation fails on FIPS-enabled clusters in 3.4 EA2. RHOAIENG-82694: MCP Lifecycle Operator can run out of memory on large clusters, with no workaround. Workarounds are documented for most items.
Why it matters
Directly relevant to state agencies, counties and universities considering OpenShift AI Models-as-a-Service as a shared, multi-department model gateway: the documented route-hijack risk and silent rate-limit failure bear on tenant isolation and chargeback, and FIPS constraints matter for CJIS- or federal-data-adjacent environments. Why now: the 5 Nov Red Hat/NVIDIA AI Factory expansion (archived) promotes a MaaS + AI gateway reference design with access policies and rate limits; these known issues define the operating conditions for that design. Not previously archived.
Evidence and measured results
Vendor product documentation listing defect IDs, symptoms, affected versions and workarounds. No exploitation reports, prevalence data or severity scores are given on this page.
Limitations and uncertainty
Undated living documentation; contents can change as fixes ship. Some items are from early-access builds (EA1/EA2) and may not apply to GA deployments. Vendor-reported; no independent validation or incident data. Severity and exploitability are not rated here.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-07; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Agencies want a shared, governed model service across departments but need assurance that isolation, rate limits and chargeback controls are enforced.
- Stakeholders
- CISO / security architect
- Enterprise AI platform owner
- Department application owners consuming models
- Internal audit
- Discovery questions
- Will multiple departments or tenants share one model gateway?
- Is the cluster FIPS-enabled or subject to CJIS or similar requirements?
- How will rate limits and usage chargeback be verified?
- Which OpenShift AI and Connectivity Link versions are deployed or planned?
- Value hypothesis
- A hardening and validation package reduces the risk of a misconfigured shared model gateway exposing prompts or failing to enforce limits.
- Potential engagement
- A bounded MaaS gateway hardening review and acceptance-test build-out against the documented 3.5 known issues.
- Unsupported claims
- That OpenShift AI MaaS is secure by default for multi-tenant use
- That the issues have been exploited
- That all listed issues affect GA deployments
Pre-sales engineering
Role takeaway
- Fit
- Applies to any OpenShift AI 3.4/3.5 deployment using MaaS, llm-d distributed inference, Connectivity Link or FIPS mode.
- Architecture and integration
- Gateway API configuration for MaaS and llm-d, Kuadrant/Authorino policies via Red Hat Connectivity Link, Istio from OpenShift Service Mesh, and Kueue for training.
- Prerequisites
- Inventory of OpenShift AI, RHCL, OSSM and RHBoK versions
- Namespace labeling scheme
- Load-testing tooling
- Log access for EndpointPicker
- Constraints
- RHBoK 1.3 required for Trainer v2 + Kueue but unsupported and unavailable on OCP 4.22
- MCP Lifecycle Operator OOM has no workaround
- FIPS clusters cannot use P/D disaggregation in 3.4 EA2
- Security
- Enforce label-based route attachment to prevent route hijacking; verify identity filters so rate limits bind to authenticated users.
- Proof of value
- Attempt HTTPRoute attachment from an unlabeled namespace and confirm rejection
- Run the documented 429 rate-limit loop
- Confirm EndpointPicker per-request log activity
- Load test MaaS at target concurrency for 500/503 errors
Delivery
Role takeaway
- Work
- Harden gateway configuration, implement workarounds, and embed verification tests into deployment and upgrade runbooks.
- Dependencies
- Platform and security teams
- Version pinning decisions for RHCL and RHBoK
- Red Hat support for fix timelines
- Ownership
- AI platform operations team, with security architecture sign-off.
- Skills and adoption
- Teams need Gateway API, Kuadrant/Authorino and Istio troubleshooting skills in addition to OpenShift AI administration.
- Governance checkpoints
- Security review of gateway route-attachment policy
- Release-note review before each upgrade
- Post-deployment control-enforcement test sign-off
- Acceptance criteria
- Proposed: unprivileged namespace cannot attach routes to the model gateway
- Proposed: rate limit returns 429 at the configured threshold
- Proposed: no 500/503 errors at planned peak concurrency
- Risks
- Silent control failure after upgrades
- Unsupported component versions pinned for workarounds
- Operator OOM on large shared clusters
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Shared model gateways must use label-based namespace selectors for route attachment, keep non-LLM routes off the inference gateway listener, pin or work around Connectivity Link versions, and raise auth timeouts for concurrency. Kueue-integrated training must stay on an unsupported RHBoK 1.3 for Kubeflow Trainer v2 integration.
Governance
Who approves, reviews and stays accountable for outcomes?
Silent failures (rate limits, intelligent scheduling) mean governance controls can appear configured while not enforced; acceptance testing must verify enforcement, e.g., the documented 429 test.
Security and privacy
What data, permissions and controls need testing?
Route hijacking enables interception of API keys, user prompts and model responses by non-privileged namespace users on a misconfigured shared gateway, a material multi-tenant confidentiality risk.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Raises the skill bar for small public-sector platform teams operating shared AI gateways.
Procurement
What should contracts, pricing and exit terms secure?
Buyers should require vendor or integrator acceptance tests that demonstrate isolation and rate-limit enforcement, not configuration screenshots.
Operating model
Which teams own the service once it runs?
Shared model services need an operator role that tracks known issues and re-verifies controls at each upgrade.
Publication history
- 2026-11-07Red Hat · Issue 093 resources
Stable resource ID: openshift-ai-3-5-known-issues-maas-gateway-llm-d-constraints