Polyaxon is an AI control plane for training, serving, and operating workloads. Its security surface is not limited to a login page. Organizations, projects, teams, agents, queues, API credentials, and audit logs all shape who can run what. An exposure inventory should connect the public endpoint to those internal authorization boundaries.
Measurement
On 2026-11-03 UTC, ZoomEye was queried with page 1, pagesize=1, and sub_type=all. app="Polyaxon" returned 6 observations. title="Polyaxon" returned 21.
The app query is the more precise set. The title query is still useful for discovery, but it can include documentation and product pages. Neither count is a count of vulnerable installations.
Authentication and RBAC are separate layers
Polyaxon's documentation describes password login, two-factor authentication, SSO, and SAML, together with organization and project RBAC. Its security FAQ says SDK and API access can use project API keys as Basic authentication credentials. The keys are created in project settings, hashed before storage, and can be rotated.
That creates two review questions. First, can an unauthenticated user reach a sensitive API or UI route? Second, can an authenticated project member use an API key or project role beyond the intended scope? A public endpoint with strong login can still expose too much if every project member receives broad permissions or if API keys are copied into notebooks and CI jobs.
Inventory the control plane
For each confirmed Polyaxon deployment, list the UI, API, organization, projects, compute agents, queues, and integrations. Record who can create projects, invite members, create API keys, and submit workloads. Review the organization boundary and the project boundary separately.
Look for API keys in notebooks, pipeline configuration, source repositories, environment variables, and CI logs. The documented Basic authentication model means a key pair may travel with every SDK request. Store it in a secret manager, scope it to the project that needs it, and rotate it when a notebook or job is shared outside the intended team.
Correlate exposure with work
The six application observations should be checked against ownership records and network policy. For each owned instance, confirm whether the UI and API are public, private, or behind a reverse proxy. Then inspect audit logs for authentication events, project changes, API-key creation, and workload submissions during the retention window.
Do not test an unknown instance by creating a project or submitting a job. Use a controlled environment to verify that a viewer cannot submit workloads, that a project key cannot access another project, and that revoked users lose access. The results should be recorded as authorization tests, not as evidence about an unrelated internet host.
Practical response
Remove public access that is not required. Enforce MFA through the identity provider where the deployment supports it. Review organization and project roles, then remove API keys that are not tied to an active automation. Add an approval step for project creation and for changes to compute agents or queues.
Audit logs should be retained centrally with the actor, project, action, target, timestamp, and source address. If a key is exposed, revoke it and inspect the actions performed while it was active. A successful rotation does not erase the need to review what the old credential could reach.
The broader lesson
AI platforms concentrate credentials, code execution, and access to expensive compute. A useful exposure count tells an owner where to look. The security decision comes from the authorization model: who can create a workload, which data the workload can read, and which credentials it receives.
The two Polyaxon counts, 6 and 21, should remain separate in the report. The application count is the precise lead; the title count is the broader discovery set. Both are observations, not verdicts.