AI builder now tags credentials with account identity
The AI agent can now see which account a credential belongs to, preventing text classifier and other AI prompts from being tailored to the wrong email context.
The AI agent had no way to know which account a credential belonged to. When list-credentials was called, it returned only id, name, and type — nothing to identify the account. This caused problems: the browser might show one email, but the credential was connected to a different one. Text classifier and other AI-powered steps would then tailor their prompts to the wrong account context entirely.
Credential tools now expose a masked account identifier — something like "al*@gmail.com" — so the orchestrator can match credentials to the correct account. The account information is captured at OAuth connection time by examining token fields, decoding JWT id_token payloads, and inspecting nested user objects. For credentials that were connected before this change, the system falls back to runtime extraction from stored token data and credential fields.
Account identifiers are masked before being exposed to keep sensitive data off the AI's radar. Decryption scope is also minimized to reduce secret payload exposure in memory.
View Original GitHub Description
Summary
- The AI agent had no way to know which account a credential belongs to ...
list-credentialsonly returned{id, name, type}. This caused prompts (e.g. text classifier) to be tailored to the wrong context when the browser showed one email but the credential connected to a different one. encryptAndSaveDatanow extracts and persists anaccountIdentifier(email/username) at OAuth connection time by checking direct token fields, decoding JWTid_tokenpayloads, and inspecting nested user objectslist-credentialsandget-credentialtools returnaccountIdentifierso the orchestrator can match credentials to the correct context- For credentials connected before this change,
getAccountContext()falls back to runtime extraction from stored token data and credential fields