Skip to main content
The LLM Gateway accepts gateway keys and supported interactive organization sign-in. Both methods resolve to an organization and access profile before Forge checks models, policies, and budgets. A customer IdP token is not automatically a gateway credential. Use the organization sign-in settings shown by Forge for supported interactive clients. Use a configured attribution verifier when an application sends an IdP token alongside its gateway key.

​
Create and rotate a gateway key

  1. In Gateway, configure a provider and an active access profile with the intended routes and model allowlist.
  2. Create a gateway key for that profile. Set its subject and limits for the application or workload that will use it.
  3. Copy the key when it is shown and store it in the application’s secret manager. Provider API keys stay in the provider connection; do not give clients the upstream provider credential.
  4. Test model discovery and a small inference request with the same key.
  5. When rotating, install and test the replacement key before revoking the old key. A revoked key must stop authorizing new requests.
Organization sign-in uses a person’s access token instead of this key. Never put an access token or gateway key in a distributable managed setup file.

​
Interactive sign-in settings

Gateway → Connect an app → Connection details and manual setup shows the values for the selected application and environment. Supported clients use the authorization-code flow with PKCE. The setup file contains public connection settings and no shared employee secret. Each person completes their own sign-in. Refresh behavior belongs to the client and issuer. Forge verifies the token signature, issuer, expiration, audience, registered client, and selected organization. Tokens issued for another API or environment do not grant inference access.

​
Organization and directory identity

Interactive inference requires all of the following:
  • The selected sign-in organization is linked to the Forge organization.
  • The signed-in account is linked to an existing Forge user and organization membership.
  • The membership is linked to an active directory identity.
  • The person’s managed-access identity is active.
  • The effective assignment resolves to an active access profile.
Directory collection and enterprise SSO are separate setup tasks. Connecting the Entra directory integration or Okta directory integration does not by itself configure organization sign-in. Your administrator must complete the organization’s sign-in setup and confirm the user linkage. Forge uses its current directory membership for group access. Arbitrary group claims in a client’s token do not create department assignments.

​
Assignment precedence

Managed access selects an explicit person assignment first, then one matching directory-group assignment, then the organization default. Multiple matching group assignments are ambiguous and block access. An unusable selected assignment does not fall back to a less specific assignment. Use Manage access to resolve overlapping groups or assign an explicit profile to the person. The access profile still determines allowed models, providers, and request types. A completed sign-in does not bypass those limits or an exhausted budget.

​
Gateway-key attribution

An application can send a verified end-user token in X-Forge-Identity-JWT while authenticating with its gateway key. Configure the token issuer, audience, JWKS URL, and claim mappings before relying on that identity. Unverified identity headers do not establish user or group permission. This attribution method is separate from the interactive access token used by Claude Desktop and other supported organization-sign-in clients.

​
Diagnose a denied request

See Connect apps to Forge for client setup and Claude Desktop with Forge for deployment.