Enabling Oblivious Access Control via Function Encryption
Potential Solution?

Using Functional encryption, a trusted authority with a master secret key ($msk$) and public key ($pk$) would generate a "functional decryption" key ($sk$) from a participant's policy ($k$). Each participants would be provided the $pk$ and relative $sk$, where $sk$ is bound to the participant's public identity via a signed document.

For a client and server session between two participants, the client would first use $pk$ to encrypt its own intended API request ($x$) to generate the ciphertext ($c$). After securely connecting and receiving the server signed document, the client would verify the server's ownership of $sk$. Next the client would check the server is authorized to receive the API by using the server's $sk$ to calculate a policy function of the request $c$ encrypts. If the function returns True, then the server is authorized to receive the API request, otherwise False is returned. If True, the client then transmits $x$ and its own $sk$ document for the server to verify similarly, checking the client is authorized to send the API request before fulfillment.

Extension?

To prevent recipients of a participant's $sk$ from probing what additional API permissions where provisioned within, e.g. by brute force enumeration of API requests, perhaps either the encryption or decryption algorithms could altered require a third argument ($sk'$). While also generated from $k$, $sk'$ is instead kept secret to the owner, while additionally remaining a non-substitutable argument for (public) $sk$ and vice versa. The result being that a return of True could only occur if the policies in $sk$ and $sk'$ coincide such that the permissions for the intended client and server for the API request $x$ are all permissible, otherwise False is returned.

This would prevent a malicious actor from gaining any more knowledge about the permissions of other participant's, aside from what could already be inferred from authorized exchanges using the identity and $sk'$ from the participant it has already compromised. Perhaps a another approach could necessitate some sub key or token from the other participant that would authorize the policy "background" check upon the received $sk$ for only the permission relevant for the API in question. However this would require the client to divulge the API request to the server to receive such a token before even vetting the server, itself a circumvention of access control that would perhaps negate the advanage.

In lieu of three argument function encryption algorithms unfeasible, perhaps a similar effect could be achieved by necessitating a cascaded calculating of function upon $c$ and then $c'$ using $sk$ and $sk'$ once in either of the two stages? E.g.

$$
(pk,msk) \leftarrow Setup(1^{\lambda}) \\
sk \leftarrow Keygen(msk, k) \\
{sk}' \leftarrow Keygen(msk, {k}') \\
c \leftarrow Enc(pk,x) \\
{c}' \leftarrow Dec({sk}',c) \\
F(({k}',k),x) \leftarrow Dec({sk}',{c}')
$$