I defined a Jenkins pipeline job with a Node parameter JENKINS_PARAM_RUN_NODE and the following script,

pipeline {
    agent none
    stages {
        stage('Run') {
            agent {
                label "${env.JENKINS_PARAM_RUN_NODE}"
            }
            steps {
                script {
                    echo 'Hello World'
                    sh 'export -p'
                }
            }
        }
    }
}

This showed JAVA_HOME of the Windows master despite selecting a MacOS agent.

...
+ export -p
...
export JAVA_HOME="C:\\Program Files\\Java\\jdk1.8.0_211"

Blanking the env variable exposes the MacOS agent's value,

            environment {
                JAVA_HOME = ''
            }

...
+ export -p
...
export JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home"

As an added bonus unrelated to Jenkins, MacOS's /usr/bin/java seems to interpret the unexpected Windows notation in JAVA_HOME by selecting the latest installed (I suppose) java.home,

type -a java
java -version
jh=$(java -XshowSettings:properties 2>&1 | sed -ne 's/^[[:space:]]*java\.home = \(.*\)/\1/p')
echo "java.home=\"${jh}\""

+ type -a java
java is /usr/bin/java
+ java -version
java version "10.0.2" 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)
++ java -XshowSettings:properties
++ sed -ne 's/^[[:space:]]*java\.home = \(.*\)/\1/p'
+ jh=/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home
+ echo 'java.home="/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home"'
java.home="/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home"

I do not expect JAVA_HOME of master to override the agent's environment. As for the blanking env var work-around, I am not sure if this agrees with the expected semantics of the "environment" DSL clause because instead of unsetting the variable, it appears to expose the agent's variable.