Apr 22, 2026

Two related security changes are rolling out together:

1. Connections on Composio-managed auth configs now always redact access_token, refresh_token, and the Authorization header in connected-accounts responses — independent of your project's mask_secret_keys_in_connected_account flag.
2. Auth-config GET responses now redact (for Composio-managed) or mask (for customer-owned) every sensitive credential field.

Auth-config credential redaction is not controlled by mask_secret_keys_in_connected_account. That project flag only applies to runtime connected-account credentials (access tokens, refresh tokens, and the like). Auth-config credentials are developer-owned static fields — client_id, client_secret, developer_token, etc. — and are always redacted or masked regardless of the mask_secret_keys_in_connected_account project flag.

Most integrations need no changes.

• Tool execution through the SDK, Tool Router, and MCP is unchanged. Composio uses the unredacted values server-side.
• Connections on customer-owned auth configs continue to follow your project's mask_secret_keys_in_connected_account setting for runtime tokens.

What is a Composio-managed auth config?

When you connect a user through a toolkit's default integration — for example, Gmail or Slack without registering your own OAuth application — Composio uses an OAuth application it owns and shares across every team on that default. Tokens the provider issues are bound to that shared Composio-owned client.

You can identify a Composio-managed auth config or connection by is_composio_managed: true on the auth-config or connected-account resource.

1. Connected-account tokens

Access tokens, refresh tokens, and all header and query-parameter values are now replaced with the literal string "REDACTED" for Composio-managed connections. No prefix, no suffix — nothing that reveals the underlying value.

Before, with mask_secret_keys_in_connected_account: false on a Composio-managed Gmail connection:

{
  "state": {
    "val": {
      "access_token": "ya29.a0ARrdaM9...full token...",
      "refresh_token": "1//04...full token..."
    }
  },
  "data": {
    "headers": {
      "Authorization": "Bearer ya29.a0ARrdaM9...full token..."
    }
  }
}

After:

{
  "state": {
    "val": {
      "access_token": "REDACTED",
      "refresh_token": "REDACTED"
    }
  },
  "data": {
    "headers": {
      "Authorization": "REDACTED"
    }
  }
}

Connections on customer-owned auth configs are unaffected — token visibility follows your existing mask_secret_keys_in_connected_account setting (xxxx... truncation when enabled, raw passthrough when disabled).

If you were reading Composio-managed access or refresh tokens from these responses — typically because you use Composio for OAuth and then call the provider's APIs yourself — register your own OAuth application with the provider and create a custom auth config against those credentials. Tokens issued against an OAuth application you own belong to you and are returned in full (subject to mask_secret_keys_in_connected_account).

2. Auth-config credentials

GET /api/v3/auth_configs and GET /api/v3/auth_configs/{id} no longer return sensitive credentials in a recoverable form.

• Composio-managed auth configs — every credential field is redacted.
• Customer-owned auth configs — public OAuth identifiers (client_id, consumer_key) still pass through so you can debug OAuth flows. Every other credential field is obfuscated.

If your code reads a secret — for example client_secret or developer_token — out of these responses, you will need to keep that value alongside the code that created the auth config (typically in your own secret manager at upload time).

Why this change

A single OAuth application backs every team on a Composio-managed default integration, and the tokens and client secrets bound to it are shared. If a provider throttles, restricts, or suspends that app in response to misuse of one of its credentials, the integration becomes unavailable for every team on the default at once. Redacting the values keeps them out of API responses; Composio still uses them server-side, so tool execution is unchanged.

For customer-owned auth configs, masking a freshly re-read client_secret or developer_token limits the blast radius of a compromised project API key without breaking your ability to identify which credential was uploaded.

Affected endpoints

Connected accounts:

• GET /api/v3/connected_accounts/{id}
• GET /api/v3/connected_accounts
• POST /api/v3/connected_accounts
• Webhook payloads that include connection credentials

Auth configs:

• GET /api/v3/auth_configs/{id}
• GET /api/v3/auth_configs