Access Keys and Policies

Access Keys are what your client applications actually authenticate with when calling the AI Gateway. Policies let you control what each key is allowed to do.

Access Keys

Create an Access Key from the Access Keys page in the SocketXP Web Portal. Give it a name and description, and optionally attach a Policy.

The raw key, in the format sxp_<id>_v1_<secret>, is shown to you exactly once, right after creation. Copy it somewhere safe at that point — SocketXP doesn't store the raw key, so it can't show it to you again after that.

A key without a Policy attached can be used for anything: any provider, any model. If that's broader than you'd like a particular integration to have, attach a Policy when you create the key, or create a new key scoped down for that purpose.

There's no way to update or revoke an existing key. A key is either present or deleted. That's a deliberate product decision rather than a missing feature, so if a key needs to change scope, the right move is to delete it and create a new one.

Access Key Policies

A Policy restricts an Access Key along two dimensions, independently of each other:

• Providers, via ProviderIds. This can include custom providers, built-in providers, or a mix of both.
• Models, via ModelIds.

Leaving either list empty means "allow all" for that dimension. So a Policy that only sets ModelIds restricts which models a key can call, but leaves it free to reach any provider that serves one of those models, and vice versa.

The same Policy logic applies whether the resolved provider turns out to be custom or built-in. It's checked against whichever provider and model the gateway resolves a given request to, so the Policy always sees the actual provider and model being called, not just what the client asked for by name.

Policies support the usual create, list, get, update, and delete operations, so you can build out a set of policies for different use cases, say a read-only integration limited to one model, versus an internal tool with broader access, and assign Access Keys to whichever policy fits.

Putting them together

A practical pattern is to create one Access Key per integration or environment, each with its own Policy scoped to only what that integration actually needs. A staging environment might get a key scoped to a cheaper model, while a production key is scoped to the model you've actually validated. Since keys can't be edited after creation, only deleted and replaced, it's worth thinking about this scoping upfront rather than starting broad and narrowing later.