authorize_sitters and deauthorize_sitters never checked whether the session was a sitter session. Someone logged in with an empire's sitter password could grant sitter access on that empire to any other empire, and could expire every sitter the owner had authorized. Every other method that controls access to the account already refuses sitters with error 1015: change_password, view_profile and edit_profile (which is where the sitter password itself is set), and enable/disable_self_destruct. Sitters cannot change who holds the sitter password, so they should not be able to change the sitter list either. Use the same guard in both methods, in the $session->is_sitter form that Entertainment.pm uses, ahead of the captcha check as Embassy's accept_invite does. Both methods act on the session's own empire_id and ignore any empire_id option, so a sitter reaches them for someone else's empire only through a sitter-password session. An empire sitting through a sitter authorization calls them as itself, is not a sitter there, and is unaffected. The regression test logs in with the sitter password, solves the captcha, and checks that both calls return 1015 and leave the list unchanged, and that the owner can still deauthorize. Against the previous code the sitter's authorize_sitters succeeded and deauthorize_sitters expired the owner's sitter.