---
title: How to manage access to your dedicated Generative APIs deployments
description: This page explains how to manage and restrict access and authentication for your dedicated Generative APIs deployments
tags: generative-apis-dedicated-deployment ai-data ip-address
dates:
  validation: 2026-04-15
  posted: 2024-03-06
---
import Requirements from '@macros/iam/requirements.mdx'

import apiAuthentication from './assets/scaleway-api-authentication.webp'

<Message type="important">
The **Allowed IPs** feature via ACLs is no longer available for Generative APIs - Dedicated Deployment. We recommended using one of the alternative methods detailed in this document to restrict access to your dedicated Generative APIs deployments.
</Message>

You can manage and restrict access to your dedicated Generative APIs deployments via the following methods:

- Enable or disable authentication by API key
- Use [IAM](/iam/) features to control which API keys are accepted and under what conditions (including IP-based restrictions)
- Remove your deployment's public endpoint, and allow controlled access only via Private Networks

Read on for full details.

<Requirements />

  - A Scaleway account logged into the [console](https://console.scaleway.com)
  - A [dedicated Generative APIs deployment](/generative-apis/how-to/create-deployment/)
  - [Owner](/iam/concepts/#owner) status or [IAM permissions](/iam/concepts/#permission) allowing you to perform actions in the intended Organization

## How to enable or disable authentication by API key

By default, when you create your dedicated Generative APIs deployment, authentication by API key is automatically enabled. This means that when the deployment is accessed via either its public or private endpoint, a valid Scaleway API key must accompany all requests.

You can disable API key authentication at any time, for either the public endpoint, the private endpoint, or both.

1. Click **Generative APIs** in the **AI** section of the side menu in the [Scaleway console](https://console.scaleway.com/) to access the dashboard. The list of models displays.
2. Select the **Deployments** tab.
3. From the drop-down menu, select the geographical region containing your deployment.
4. Click the deployment whose authentication you want to manage. The deployment's dashboard displays.
5. Click the **Security** tab.
6. In the **Authentication** panel, use the toggles <Icon name="toggle" /> to enable or disable authentication by API key for the public and/or private endpoint.

<Lightbox image={apiAuthentication} alt="A screenshot of the Scaleway console shows the toggles for API key authentication first for public endpoints, then for private endpoints" /> 

## How to manage access to a deployment with IAM

When [authentication by API key](#how-to-enable-or-disable-authentication-by-api-key) is enabled, a valid [Scaleway API key](/iam/concepts/#api-key) must accompany all requests sent to your deployment's endpoint.

An API key is considered valid to access a deployment when:

- It belongs to the [Owner](/iam/concepts/#owner) of the Organization which owns the deployment, or
- It belongs to a [Member](/iam/concepts/#member) or [Application](/iam/concepts/#application) of the Organization which owns the deployment, and the Member/Application has appropriate [IAM permissions](/iam/reference-content/permission-sets/).

There are two IAM permission sets specific to Generative APIs - Dedicated Deployment (formerly known as Managed Inference): `InferenceFullAccess` (allowing access to create, read, update, and delete a deployment) and `InferenceReadOnly` (allowing read-only access). Alternatively, wide-scoped permission sets such as `AllProductsFullAccess` will also allow access.

<Message type="important">
  Due to a product name change, the permission set names `InferenceFullAccess` and `InferenceReadOnly` are also changing. If you are automatically provisioning IAM policies (using Terraform, CLI, or APIs) with permission sets `InferenceFullAccess` and `InferenceReadOnly`, then you should edit your existing scripts and replace these permissions with `GenerativeApisFullAccess` and `GenerativeApisModelAccess`, respectively. 

  For now, both `InferenceFullAccess` and `InferenceReadOnly` will remain available at least until 1 June 2026. If you may be impacted by the permission set name update, you will receive a dedicated communication including the definitive End Of Life date for these permission sets.
</Message>

Permissions are attributed via [policies](/iam/concepts/#policy), which are then attached to a Member or Application. 

You can further restrict access by imposing **conditions** when defining a policy. This enables you to allow access only to authorized API keys when presented by specific user agents (e.g., Terraform), from certain IP addresses, or during defined dates and times.

### How to manage deployment access as an Organization Owner or Administrator

<Message type="note">
If you only want to access the deployment yourself, and you are the Owner of the Organization that created the deployment, simply [generate an API key](/iam/how-to/create-api-keys/) for yourself, and it will automatically have full rights to access and manage the deployment.

Read on if you want to manage access to your deployment for others.
</Message>

1. [Invite Members](/iam/how-to/manage-members/) (other humans) to your Organization, or [create Applications](/iam/how-to/create-application/) (non-human users).
2. Create and attach a [policy](/iam/how-to/create-policy/) to the Member or Application, defining the permissions they should have in your Organization by selecting permission sets (e.g., `InferenceFullAccess`). If desired, define [conditions](/iam/concepts/#conditions) as part of the policy, to further restrict access based on user agent type, date/time or IP address.

<Message type="important">
  Due to a product name change, the permission set names `InferenceFullAccess` and `InferenceReadOnly` are also changing. If you are automatically provisioning IAM policies (using Terraform, CLI, or APIs) with permission sets `InferenceFullAccess` and `InferenceReadOnly`, then you should edit your existing scripts and replace these permissions with `GenerativeApisFullAccess` and `GenerativeApisModelAccess`, respectively. 

  For now, both `InferenceFullAccess` and `InferenceReadOnly` will remain available at least until 1 June 2026. If you may be impacted by the permission set name update, you will receive a dedicated communication including the definitive End Of Life date for these permission sets.
</Message>

All API keys generated by the Member, or for the Application, will automatically inherit the permissions you defined, and can be used to access a dedicated Generative APIs deployment's endpoint depending on those permissions.

You can revoke access to a deployment at any time by [modifying or deleting the policy](/iam/how-to/manage-policies/) attached to the Member or Application in question.

### How to access a deployment as an Organization Member

Your access to dedicated Generative APIs deployments owned by an Organization in which you are a Member depends on the IAM permissions attributed to you by the Organization's Owner or administrators.

Your permissions will be automatically applied to any API keys you generate for yourself in the Scaleway console. Check with your Organization Owner if you are unsure that you have the right permissions to access a dedicated Generative APIs deployment.

1. Log into the [Scaleway console](https://console.scaleway.com) and [generate an API key for yourself](/iam/how-to/create-api-keys/).
2. Use this API key for authentication when sending requests to a dedicated Generative APIs deployment.

## How to restrict access over Private Networks

For enhanced security, you can remove your deployment's public endpoint, attach it to a Private Network, and allow access only via its private endpoint. Only resources within the Private Network's VPC will be able to access the deployment, and they must have downloaded the resource's TLS certificate.

You can still require API key authentication via the private endpoint, and use the methods described above to fine-tune API key restrictions and access. In addition, you can also use VPC features such as Network ACLs for enhanced control and security.

1. [Create your deployment](/generative-apis/how-to/create-deployment/) without checking the **Allow public connections** box, or remove the public endpoint via its **Overview** screen in the console if you already created it with a public endpoint.
2. Ensure the deployment is [attached to a Private Network](/generative-apis/how-to/dedicated-deployment-with-private-network/#how-to-attach-a-private-network-to-a-dedicated-generative-apis-deployment).
3. Transfer the deployment's [TLS certificate](/generative-apis/how-to/dedicated-deployment-with-private-network/#how-to-send-inference-requests-in-a-private-network) to the resources in the VPC that need to access the deployment.
4. (Optional) Ensure that API key authentication is enabled, and use [policies](/iam/how-to/create-policy/) to define IAM-based rules and conditions for access.
5. (Optional) Use VPC features such as [Network ACLs](/vpc/reference-content/understanding-nacls/) to place IP-based restrictions on which resources in the VPC can access the deployment.
6. Follow the instructions in the [dedicated documentation](/generative-apis/how-to/dedicated-deployment-with-private-network/#how-to-send-inference-requests-in-a-private-network) for sending requests to your deployment in a Private Network.

<Message type="tip">
If your VPC has a Public Gateway advertising a default route, external resources can still access the deployment via the Public Gateway (with correct authentication). [Read more about Public Gateways](/public-gateways/).
</Message>