Argo Workflows runs Kubernetes-native workflows and can expose their state, logs, and execution controls through an Argo Server. A public or cross-network server changes the meaning of an otherwise internal workflow engine. The server's authentication mode determines whether the deployment relies on Kubernetes client identity, an SSO provider, or a configuration intended for local use.
A ZoomEye query for app="Argo Workflows" returned 1,716 matches on 28 October 2026, using sub_type=all and a page size of one. A title query returned nine. The difference is consistent with a fingerprint that can identify an application without requiring a standard page title, but neither result establishes whether a matching service is unauthenticated. It only gives a bounded starting set for ownership and configuration checks.
Authentication is a server boundary
Argo Workflows security documentation describes three layers and recommends enabling an authentication mode so unknown users cannot run workflows. The server auth-mode documentation says the server can be configured with one or more --auth-mode flags. In client mode, authentication delegates to the Kubernetes API server. In SSO mode, it uses the configured identity provider. A deployment that sets an authentication mode still needs Kubernetes authorization and workflow-level controls around it.
For every Argo Server, capture the exposed URL, the authentication mode, the identity provider, the Kubernetes namespace, and the workload which can be started by each user. Then check the path from the server to the Kubernetes API. An SSO account with broad workflow-creation rights may be able to launch privileged pods or mount credentials that the user never sees in the UI. Server authentication does not replace least-privilege service accounts, admission policy, and namespace isolation.
Review automation separately
CI systems often call the Argo API with a token or through the Kubernetes API. Those identities need their own inventory. Short-lived tokens and workload identity are preferable to long-lived bearer tokens, but the duration is only part of the control. A compromised pipeline can create workflows even when a user-facing SSO login is well protected.
Use the Argo Workflows measurement as a repeatable inventory query, not as an authorization test. Compare results against DNS and cloud inventories. Look for management servers on public addresses, mismatched certificates, unexpected hostnames, or legacy deployments that no account owner recognizes.
Test a workflow from an unauthenticated browser session, from a low-privilege identity, and from the approved pipeline identity. Confirm each receives a different, intentional result. Check that logout and token revocation invalidate access. If the server uses client mode, verify that a client certificate from a different service cannot create workloads merely because it can reach the endpoint.
The practical deliverable is a small table with each server, owner, authentication mode, Kubernetes identity, allowed workflow scope, and next review date. Argo's orchestration power makes the control plane worth tracking directly. A ZoomEye count can find candidates, but Kubernetes and identity configuration decide whether access is appropriate.