Tested on sudo on Nightingale. It can prevent sudoing based on just the user-editable files, but you have to be super explicit about it:

{ lib, ... }:
{
  security.pam.services.sudo = {
    sshAgentAuth = lib.mkForce false;
    sshAgentAuthNoHome = true;
  };
}

otherwise you get 2 auth_sufficient lines in /etc/pam.d/sudo. That's because nixos/modules/security/sudo.nix enables it for convenience. That is a usability problem in my opinion. This raises the question of what the config generator should do if both sshAgentAuth and sshAgentAuthNoHome are set. I would say it should either inhibit sshAgentAuth and use the stricter setting, or perhaps fail an assert.

Tested on sudo on Nightingale. It can prevent sudoing based on just the user-editable files, but you have to be super explicit about it:

{ lib, ... }:
{
  security.pam.services.sudo = {
    sshAgentAuth = lib.mkForce false;
    sshAgentAuthNoHome = true;
  };
}

otherwise you get 2 auth_sufficient lines in /etc/pam.d/sudo. That's because nixos/modules/security/sudo.nix enables it for convenience. That is a usability problem in my opinion. This raises the question of what the config generator should do if both sshAgentAuth and sshAgentAuthNoHome are set. I would say it should either inhibit sshAgentAuth and use the stricter setting, or perhaps fail an assert.

note optionalString cfg.sshAgentAuthNoHome not (config.security.pam.enableSSHAgentAuth && cfg.sshAgentAuth) so you don't need to have config.security.pam.enableSSHAgentAuth enabled and you don't get the double entry.

I absolutely dislike the current solution and my solution, I would only have cfg.sshAgentAuth boolean and cfg.sshAgentAuthPath listOf str, but that would break backwards compat, so I proposed this more conservative solution that bypasses the current config.

I guess there is backwards compatible solution of making

     ${optionalString cfg.sshAgentAuth
          "auth sufficient ${pkgs.pam_ssh_agent_auth}/libexec/pam_ssh_agent_auth.so file=${lib.concatStringsSep ":" cfg.sshAgentAuthPaths}"}

where default paths would be the old paths and for new style config you would just unset config.security.pam.enableSSHAgentAuth and set paths and boolean however you needed

this would only break configs that had noop config of cfg.sshAgentAuth for some security.pam.services.name, but not config.security.pam.enableSSHAgentAuth, which would be inert

This new revision would be my preferred solution (apart from completely dropping config.security.pam.enableSSHAgentAuth completely and the entry on sudo module).

It's to my understanding perfectly backwards compatible apart from people who have only enableSSHAgentAuth = true specified and expect it to have no effect, which is just silly.

I see this commit has been sufficiently fixed in ba1fa0c for me.

already fixed by another commit