The TrustyAI Service (TAS) deployment, reconciled by trustyai-service-operator, exposes its backend API without authentication to any pod on the cluster network, bypassing the kube-rbac-proxy sidecar that is meant to front it.

Vulnerable mechanism:
- controllers/tas/templates/service/service-internal.tmpl.yaml (trustyai-explainability/trustyai-service-operator) creates a ClusterIP Service mapping port 80 -> targetPort 8080 directly to the TAS backend container, alongside a separate port 443 -> 8443 path that does go through kube-rbac-proxy.
- controllers/tas/services.go:20 hardcodes UseAuthProxy: false for TAS. Unlike gorch and NemoGuardrails, TAS has no annotation-driven opt-in to route exclusively through the proxy.
- The TAS backend itself (the explainability-service Quarkus module in the red-hat-data-services/trustyai-explainability downstream fork, published as the odh-trustyai-service-rhel9 container) sets quarkus.http.host=0.0.0.0 in explainability-service/src/main/resources/application.properties, with no QUARKUS_HTTP_HOST override anywhere in the operator's deployment template, and no application-level authentication filter of any kind in the Java source (no @RolesAllowed/SecurityIdentity/JsonWebToken usage found anywhere in the endpoints package).

Confirmed present in the exact source commits the Red Hat manifests database (build_sources) shows pinned for each of the following shipped builds:
- rhoai/odh-trustyai-service-rhel9 v2.25.7 (RHOAI 2.25) - commit 08e7ca16fc1a75650699fdc6425affa15a7c6dae
- rhoai/odh-trustyai-service-rhel9 v3.3.5 (RHOAI 3.3) - commit b3b2ef70c2264956ea6815cf118ca109376c55b6
- rhoai/odh-trustyai-service-rhel9 v3.4.2 (RHOAI 3.4) - commit 3cfcf07ea04962eee79c72e533f79395706756ba

All three pin quarkus.http.host=0.0.0.0 with no restricting override.

Trigger / impact: any pod on the cluster network (no credential, no token, nothing TAS-specific) can reach the internal Service on port 80 and call the backend's full API directly. This is not read-only. Confirmed unauthenticated endpoints on the real backend include:
- GET /metrics/{type}/requests - enumerate every currently scheduled fairness/drift computation (with UUIDs) for that TAS instance
- DELETE /metrics/{type}/request - delete any scheduled computation by UUID, i.e. fully disable a tenant's automated monitoring
- POST /data/upload - inject arbitrary data into the instance's stored dataset
- POST /consumer/kserve/v2 - inject fabricated inference request/response payloads into the live model-monitoring ingestion path

Since TAS instances are deployed per-namespace/tenant and this Service has no NetworkPolicy restricting which pods can reach it, any pod in any other namespace on the same cluster can read, tamper with, or wipe another tenant's TAS monitoring data and configuration.

Attribution: Red Hat Product Security Project Glasswing (Mythos) security audit, finding FIND-002, tracked in RHOAIENG-69540.