There are several places in the JGSS-API about "local access policies":

In GSSCredential class:

 * implementations must impose a local access-control policy on callers to
 * prevent unauthorized callers from acquiring credentials to which they
 * are not entitled.

In GSSCredential::add:

     * As always, GSS-API implementations must impose a local access-control
     * policy on callers to prevent unauthorized callers from acquiring
     * credentials to which they are not entitled.

In GSSContext::export:

     * The implementation may constrain the set of processes by which the
     * interprocess token may be imported, either as a function of local
     * security policy, or as a result of implementation decisions. For
     * example, some implementations may constrain contexts to be passed
     * only between processes that run under the same account, or which are
     * part of the same process group.<p>

We need to evaluate if these "local access polices" relate to Security Manager access control or other mechanisms.

Also, section 9 of RFC 8353 mentions the Security Manager and needs update. For example:

The Java language security model historically allowed platform providers to implement policy-based fine-grained access control over resources accessed by applications through the use of the Java Security Manager. However, the Security Manager has been deprecated for removal starting with JDK 17 in 2021 [JEP411] and it has been disabled since JDK 24 in 2024 [JEP486], rendering this approach obsolete. Modern Java applications should be sandboxed in the same way as native applications, using technologies outside the JDK such as containers, hypervisors, and other OS mechanisms.