Consider ZK password proof protocol: at enrollment (password set / change) the server -or a third party it trusts- knows the password and computes a verifier, while at login time the server uses the verifier to validate that the client knows the password but without the client revealing the password to the server. The client could perhaps have found an alternative password that matches the same verifier, but the ZKPP's security characteristics are supposed to make that exceedingly difficult. Meanwhile, the ZKPP is also supposed to make it exceedingly difficult to recover the password from a ZKPP exchange that any eavesdropper could record.

A non-augmented ZKPP protects the password from eavesdroppers, but the server's verifier is a password-equivalent (though it isn't the password, just a one-way function of it).

A ZKPP is the simplest ZKP application, but others work similarly.

In other words: you're missing everything about ZKPs.

But it’s not working that way, there is a third party like attestation that provides the data to client to generate zk proof