Extend GraphQL Field-Based Permissions to support Input Types (⁠INPUT_OBJECT⁠)

Is your feature request related to a problem? Please describe. Currently, Tyk's GraphQL Field-Based Permissions (allowed_types and restricted_types) only apply to Output Types (the selection set). There is no native way to restrict fields within INPUT_OBJECT types or arguments.

In B2B multi-tenant APIs, this is a significant security gap not just for query filtering, but especially for Mutations (Creates, Updates). I am always frustrated when I cannot block restricted input fields at the gateway layer. For example, if a client submits an UpdateUser mutation, I want to prevent them from passing admin-only input fields like role, tenantId, or status. Because Tyk allows all input fields to pass through, these potentially malicious payloads reach the downstream server, forcing the backend to manually parse and reject invalid inputs to prevent privilege escalation.

Describe the solution you'd like I would like Tyk's GraphQL Field-Based Permissions to be extended to support INPUT_OBJECT types.

If a policy restricts a specific field on an input type, Tyk should inspect the incoming GraphQL query and its associated variables JSON object. If the restricted input field is present (whether in a Query argument or a Mutation payload), Tyk should drop the request and return a 400 Bad Request with a GraphQL error before the request ever reaches the upstream server.

Describe alternatives you've considered

1. Downstream Validation: Currently, I am forced to delegate this security concern to the backend application (e.g., using custom schema directives like @restrictInput or request interceptors in Java/Spring GraphQL). While this works, it pollutes application logic with gateway-level security concerns and adds unnecessary load to the upstream server.
2. Custom Tyk Plugin: Writing a custom Tyk middleware plugin (via JS/Go) to manually parse the request body, extract the variables JSON, and map it against the schema to block specific keys. This is highly complex, prone to edge-case bugs, and duplicates the GraphQL AST parsing that Tyk already does natively for output types.

Additional context In enterprise and multi-tenant architectures, securing the input graph is just as critical as securing the output graph. Without input field restrictions at the edge, APIs are vulnerable to Mass Assignment or over-posting attacks if the downstream server forgets to strip protected fields. Adding this feature would make Tyk a much more comprehensive security gatekeeper for complex GraphQL APIs.