For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale
Theme

Coffres-forts

Stockez des secrets pour les connexions MCP ou les requêtes envoyées depuis le bac à sable.

Un coffre-fort stocke les identifiants d’authentification séparément des instructions et de la configuration de votre agent. Associez-le à une session avec vault_ids pour que celle-ci puisse utiliser ces identifiants.

Choisissez le type d’identifiant en fonction de l’origine de la requête :

Requête Type d’identifiant Utilisation de l’identifiant par la session
Connexion MCP depuis OpenAI static_bearer ou mcp_oauth OpenAI s’authentifie auprès du serveur MCP configuré.
Requête API depuis un bac à sable hébergé par OpenAI environment_variable Le code utilise une variable d’environnement qui contient une valeur de substitution. Un proxy réseau remplace cette valeur par le secret pour les hôtes autorisés.

Par exemple, un bac à sable peut utiliser un secret du coffre-fort pour appeler l’API REST de GitHub. Suivez les étapes de la section Utiliser les secrets d’un coffre-fort pour les requêtes API depuis un bac à sable.

Lorsque vous récupérez un coffre-fort ou un identifiant, la réponse ne contient aucune de ses valeurs secrètes. Pour les autres connexions MCP, consultez les options d’authentification MCP.

Autorisations

Pour une clé d’application à accès restreint, accordez les autorisations suivantes :

  • api.vaults.read pour lister et récupérer les coffres-forts et les identifiants.
  • api.vaults.write pour les créer, les mettre à jour ou les supprimer.

Créer et utiliser un coffre-fort pour les secrets MCP

Utilisez votre client API, l’URL du serveur MCP (mcp_url) et un jeton d’accès à ce serveur (access_token). Les exemples utilisent les outils GitHub.

Commencez par créer un coffre-fort :

Créer un coffre-fort
const vault = await client.beta.agents.vaults.create({
  name: "GitHub credentials",
  metadata: {
    external_user_id: "user_123",
  },
});

Enregistrez l’ID du coffre-fort dans vault_id, puis ajoutez le jeton. Le champ mcp_server_url associe l’identifiant d’authentification à ce serveur :

Stocker un jeton au porteur
// Replace the illustrative IDs and URLs below with your own resource values.
const vaultId = "vault_123";
const mcpUrl = "https://api.githubcopilot.com/mcp/";
const accessToken = process.env.GITHUB_TOKEN;

const credential = await client.beta.agents.vaults.credentials.create(vaultId, {
  name: "GitHub access token",
  auth: {
    type: "static_bearer",
    mcp_server_url: mcpUrl,
    token: accessToken,
  },
});

Enregistrez l’ID de l’identifiant d’authentification dans credential_id pour les mises à jour ultérieures.

Lors de la création d’une session, passez l’ID du coffre-fort dans vault_ids. Utilisez la même URL de serveur dans la configuration MCP :

Associer le coffre-fort à une session
// Replace the illustrative IDs and URLs below with your own resource values.
const mcpUrl = "https://api.githubcopilot.com/mcp/";
const vaultId = "vault_123";

const session = await client.beta.agents.sessions.create({
  agent: {
    model: "gpt-6-astra",
    tools: [
      {
        type: "mcp",
        server_label: "github",
        transport: {
          type: "http",
          server_url: mcpUrl,
        },
        allowed_tools: ["search_issues", "issue_read"],
        required: true,
        connection_origin: "service",
      },
    ],
  },
  environment: {
    type: "none",
  },
  input: "Find open bugs reported in the last week.",
  vault_ids: [vaultId],
});

L’API Agents sélectionne un identifiant qui correspond à l’URL du serveur. Si plusieurs identifiants associés à la session correspondent à cette URL, renseignez le champ credential_id de l’outil MCP pour choisir lequel utiliser.

Utiliser les secrets d’un coffre-fort pour les requêtes API depuis un bac à sable

Utilisez un identifiant de type environment_variable pour fournir un secret lors des requêtes API envoyées depuis un bac à sable hébergé par OpenAI. Le bac à sable reçoit une valeur de substitution dans la variable d’environnement spécifiée. Le secret lui-même reste en dehors du bac à sable.

Ce workflow nécessite un environnement de type openai_hosted. Il ne fournit pas d’identifiants aux environnements auto-hébergés ni aux outils de type fonction exécutés par l’application.

Stocker le jeton d’API

Créez un coffre-fort comme indiqué plus haut. Envoyez ensuite une requête de création d’identifiant à POST /v1/vaults/{vault_id}/credentials avec les champs suivants :

Champ Valeur pour un jeton d’API GitHub
name GitHub API token
auth.type environment_variable
auth.secret_name GITHUB_TOKEN
auth.secret_value Le jeton que votre application lit dans une variable d’environnement secrète.
auth.networking.type limited
auth.networking.allowed_hosts ["api.github.com"]

secret_name indique le nom de la variable d’environnement que lit le code exécuté dans le bac à sable. secret_value contient la valeur réelle de l’identifiant. Ne l’incluez pas dans les prompts, les fichiers sources ou les journaux.

Dans allowed_hosts, indiquez les noms d’hôte exacts, sans schéma, chemin, port ni caractère générique. Le proxy fournit les secrets uniquement aux destinations HTTPS sur le port 443 ou 8443.

Associer le coffre-fort à une session hébergée

Ajoutez les champs suivants au même niveau que agent lors de la création d’une session. Remplacez vault_123 par l’ID du coffre-fort renvoyé par l’API :

{
  "vault_ids": ["vault_123"],
  "environment": {
    "type": "openai_hosted",
    "network": {
      "access": "restricted",
      "allowed_domains": ["api.github.com"]
    }
  }
}

Les deux listes d’hôtes ont des rôles distincts. allowed_domains autorise le bac à sable à se connecter à un hôte. Le champ allowed_hosts de l’identifiant autorise le proxy à fournir le secret à cet hôte.

Si l’accès au réseau est restreint, incluez dans allowed_domains tous les hôtes autorisés par les identifiants. Ne réglez pas network.access sur disabled pour une session qui utilise des identifiants de type variable d’environnement.

Chaque identifiant de type variable d’environnement associé à la session doit avoir un secret_name unique. Ne définissez pas ce même nom dans environment.env.

Appeler l’API depuis le bac à sable

Envoyez un message à l’agent pour lui demander d’exécuter cette commande dans le bac à sable :

curl https://api.github.com/user \
  -H "Authorization: Bearer $GITHUB_TOKEN"

La commande lit la valeur de substitution dans GITHUB_TOKEN. Le proxy la remplace par le jeton réel avant d’envoyer la requête à api.github.com. Si la requête aboutit, elle renvoie au format JSON les informations du compte GitHub de l’utilisateur authentifié. Si vous affichez la variable dans le bac à sable, vous verrez uniquement la valeur de substitution.

Transmettez la valeur de substitution telle quelle dans l’en-tête de la requête HTTPS. Elle ne donne pas accès au secret réel pour un calcul local, comme la signature d’une requête. Pour ces tâches, conservez l’identifiant dans votre application et rendez l’opération accessible via un outil de type fonction.

Utiliser des identifiants OAuth

Votre application gère le processus d’autorisation et de consentement du fournisseur. Stockez l’autorisation obtenue avec auth.type: "mcp_oauth". Si vous connaissez la date d’expiration du jeton d’accès, indiquez-la dans expires_at sous forme d’horodatage au format RFC 3339.

L’exemple suivant utilise les valeurs issues du processus OAuth de votre fournisseur. Incluez refresh pour permettre à l’API Agents de renouveler le jeton :

Stocker une autorisation OAuth
// Replace the illustrative expiry with your access token's actual expiry.
// Replace the illustrative IDs and URLs below with your own resource values.
const vaultId = "vault_123";
const mcpUrl = "https://mcp.example.com/mcp";
const accessToken = process.env.OAUTH_ACCESS_TOKEN;
const expiresAt = "2030-01-01T00:00:00Z";
const tokenEndpoint = "https://auth.example.com/oauth/token";
const clientId = "example-client-id";
const refreshToken = process.env.OAUTH_REFRESH_TOKEN;

const credential = await client.beta.agents.vaults.credentials.create(vaultId, {
  name: "Example MCP OAuth credential",
  auth: {
    type: "mcp_oauth",
    mcp_server_url: mcpUrl,
    access_token: accessToken,
    expires_at: expiresAt,
    refresh: {
      token_endpoint: tokenEndpoint,
      client_id: clientId,
      refresh_token: refreshToken,
      token_endpoint_auth: {
        type: "none",
      },
    },
  },
});

Pour le point de terminaison de jeton, utilisez la méthode d’authentification exigée par votre fournisseur. L’exemple utilise none. L’API prend également en charge client_secret_basic et client_secret_post. Pour connaître les champs disponibles, consultez la référence sur la création d’un identifiant.

Si le renouvellement d’un jeton expiré échoue, remplacez-le par un jeton valide. L’expiration du jeton ne supprime ni l’identifiant ni son coffre-fort.

Renouveler ou supprimer des identifiants

Mettez à jour un identifiant pour remplacer son secret sans modifier son ID ni son type d’authentification. Pour les identifiants MCP, l’URL du serveur reste également la même. Pour OAuth, utilisez les valeurs enregistrées de vault_id et credential_id avec le jeton de remplacement et sa date d’expiration :

Renouveler un jeton OAuth
// Replace the illustrative expiry with your access token's actual expiry.
// Replace the illustrative IDs and URLs below with your own resource values.
const credentialId = "cred_123";
const vaultId = "vault_123";
const accessToken = process.env.OAUTH_ACCESS_TOKEN;
const expiresAt = "2030-01-01T00:00:00Z";

const credential = await client.beta.agents.vaults.credentials.update(
  credentialId,
  {
    vault_id: vaultId,
    ...{
      auth: {
        type: "mcp_oauth",
        access_token: accessToken,
        expires_at: expiresAt,
      },
    },
  }
);

Incluez expires_at si le jeton de remplacement a une date d’expiration. Si vous fournissez un nouveau jeton d’accès sans date d’expiration, l’API efface la date enregistrée. Vous pouvez aussi l’effacer en indiquant explicitement null.

Pour un identifiant de type variable d’environnement, envoyez auth.type: "environment_variable" et la nouvelle valeur de auth.secret_value à POST /v1/vaults/{vault_id}/credentials/{credential_id}. Créez une nouvelle session pour utiliser cette valeur. La mise à jour du coffre-fort ne modifie pas l’identifiant déjà configuré dans un bac à sable existant.

Pour modifier secret_name ou networking, créez un nouvel identifiant.

Supprimez un identifiant lorsque vous n’en avez plus besoin. Supprimez un coffre-fort pour le supprimer avec tous les identifiants qu’il contient.

La suppression des identifiants stockés ne révoque pas les jetons d’origine auprès de leurs fournisseurs et n’interrompt pas les sessions en cours. Votre application gère la révocation auprès du fournisseur et l’annulation de la session.