# Tune how a provider handles request parameters

Stop a provider rejecting request fields it doesn't recognise by denying, replacing or permitting them. Change this only when a provider rejects requests because of an extra field. The default works for most providers.

## Before you begin

- You need the Admin or Owner role.
- You have a provider. If not, [add one](https://docs.atlas.ilionx.dev/guides/admin/providers-and-models-add-provider.md).
- You have a request that fails or behaves oddly because of an extra field. For example, a strict upstream rejects a `permissions` field sent by an agent client.

## Set the policy and rules

1. Find the offending field. Open the failed request in **Statistics** > **Audit log**. For more information, see [Search the audit log](https://docs.atlas.ilionx.dev/guides/admin/usage-and-audit-search-audit-log.md). The detail lists dropped fields, and the upstream's error names the rejected one.
2. Open **Providers** and select the provider.
3. Open the **Request Handling** tab and switch to edit mode with the lock control in the header.
4. Under **Parameter Policy**, choose how ATLAS treats unrecognised parameters:
   - **Passthrough** (default): ATLAS forwards them unless a rule denies them.
   - **Strict**: ATLAS removes them before they reach the provider unless a rule allows them.
5. Select **Add rule** and set, for each row:
   - The action: **Deny** (never send), **Allow** (send, enforced only in **Strict**), or **Replace** (send under another name).
   - The parameter key, and the replacement key for **Replace**.
   - **Applies to**: one or more models, or **All models**.
6. Select **Save** in the header. Selecting the lock again discards staged changes.

For example, to deny `permissions` for every model on a provider whose upstream rejects it, add a row. Set the action to **Deny**, the key to `permissions` and **Applies to** to **All models**, then **Save**.

## Result

The gateway applies the rules within seconds. The offending field no longer reaches the provider, or reaches it under the new name. ATLAS doesn't fail the request. It lists the removed keys in an `atlas_stripped_parameters` array in the response, and the audit detail of affected requests shows them too.

## Related

- [Gateway: unknown parameters](https://docs.atlas.ilionx.dev/concepts/gateway.md#unknown-parameters)
- [Gateway reference](https://docs.atlas.ilionx.dev/reference/gateway.md)
