An agent runs whatever the builds on it run, so a compromised build can take over the agent. The remoting channel (Remoting and JNLP4) must then stop the agent from taking over the controller. Since Jenkins 2.326 8,793 this agent-to-controller protection is always on: the controller runs only the few callbacks it expects from an agent and refuses the rest, reading its files included. You can test it from agent-ssh's own Script Console (Nodes > agent-ssh > Script Console), whose Groovy runs on the agent:
def controller = hudson.remoting.Channel.current()
println "running on: ${InetAddress.localHost.hostName}"
try {
def f = new hudson.FilePath(controller, '/var/jenkins_home/secrets/master.key')
println "read ${f.readToString().size()} characters"
} catch (e) {
println "${e.class.name}: ${e.message}"
}running on: a57e5b16171e java.io.IOException: Failed to deserialize response to UserRequest:hudson.FilePath$ReadToString@7b1f5... See https://www.jenkins.io/redirect/security-144 for more details
The trimmed middle reads SecurityException: Sending hudson.FilePath$ReadToString from agent to controller is prohibited. The protection covers only agents: a build on the built-in node runs inside the controller with access to secrets/, which is why it has 0 executors here (Controller-Agent Trust). Give each team its own agents, and patch plugins promptly: a plugin may add callbacks of its own.