When trust-on-first-use is enabled (host_key_auto_add on the libssh plugin, or AutoAddPolicy in pylibssh), a host that is already in known_hosts but now presents a different key is accepted without warning: the controller authenticates to it, runs the play there, and appends the new key to known_hosts. Defaults are not affected - with host_key_checking on and host_key_auto_add unset, non-interactive runs fail closed. Root cause: pylibssh Session.verify_knownhost() passes SSH_KNOWN_HOSTS_CHANGED and SSH_KNOWN_HOSTS_OTHER to the same missing_host_key() policy hook used for unknown hosts. The hook name and the bundled AutoAddPolicy/RejectPolicy classes follow paramiko, where that hook is consulted only for absent hosts and a mismatched key raises BadHostKeyException. ansible.netcommon's MyAddPolicy, documented as "Based on AutoAddPolicy in paramiko", therefore adds changed keys as well. libssh's own tutorial stops the connection on both states. Verified on ansible-pylibssh 1.4.0 / libssh 0.12.0; ansible-core 2.21.5, ansible.netcommon 8.7.1 (ansible 14.5.0); ansible.netcommon.libssh and network_cli with ssh_type=libssh. Reporter: Satriyo Utomo (aleens-labs).