Umm what's wrong with ssh -AJ ?
You need -A if you're running ssh on the intermediate host, i.e., on the jump host in this case. But -J doesn't run ssh on the intermediate host, it more or less runs two ssh's on your local host. The first from local to the jump, the second from local to the eventual target, through a tunnel forwarding the connecting through the jump[1]. But because all the SSH processing is always local, it always has access to the local ssh-agent: you don't need -A.
And, as someone points out upthread, you need to fully trust the remote machine to pass -A. You usually shouldn't, in most cases that I think people using jump hosts in corporate settings would be interacting with jump hosts: it permits other employees to impersonate you, by abusing your forwarded ssh-agent, if they have sufficient access on the jump host.
[1]: -J in ssh(1) documents this
Not normally, right? Isn't that the whole point of public-key cryptography?
See e.g. https://www.theregister.com/2016/01/14/openssh_is_wide_open_... for when a vulnerability in the openssh client made this possible back in 2016.
If you forward it to a remote host, you are granting access to the remote to do that (i.e., the remote can authenticate as you), thus, you must trust the remote.
From the docs,
> Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent. A safer alternative may be to use a jump host (see -J).
Good side: You can then chain authenticate and say use same SSH agent to authorize sudo, hence getting sudo without password, just secured with your private key. Add hardware token to store said key and you're pretty secure.
Bad side: .... so can any other process with right permissions on the system, therefore compromised system can try to impersonate you.
One way to mitigate is is to make sure servers can't talk to eachother to via SSH, if user can access A and B but A can't access B and vice versa the escalation is limited.
Other way is to set agent to ask every time something wants to use the key which half-solves it (attacker would need to time the attack to occur right before "valid" use") but from what I remember it still doesn't show you what is trying to use your key (at least for gpg-agent's ssh agent functionality) so it's kinda not that useful of a feature.