Answer target
How do AI products collect and hold their customers' credentials?
Updated June 25, 2026
Short answer
Across 17 AI products reviewed from public documentation in July 2026, intake is almost always copy-paste: the customer generates a key or connection string in the source system and pastes it into the product. What happens after the paste is rarely documented. Of the 17, exactly one publicly documents its credential custody architecture. The rest say nothing about where credentials live, what can read them, or how they are revoked.
What to do now
If your product asks customers for their credentials, work out which of the six common patterns you use, then check whether you document what happens after intake. Most products document intake and stop there.
- Identify how each integration collects the credential: paste, OAuth, or the customer's own login.
- Check whether you publicly document custody after intake.
- Note which credentials are long-lived static keys versus expiring tokens.
- Decide where a security reviewer would find your custody answer.
Better pattern
The products that hold up under review can name where a credential lives, what can read it, how it is scoped, and how it dies. Documenting intake is common; documenting custody is rare, and it is the thing buyers increasingly ask about.
Avoid
Avoid assuming an OAuth handshake at intake answers the custody question, storing pasted connection strings in application tables without a custody story, and describing security only in terms of certifications while the credential path stays undocumented.
Example
One product in the set, TextQL, publishes that credentials are stored encrypted in its vault and injected at the network layer by an egress proxy, with per-domain allowlists. It is the exception, not the norm: the other 16 document intake and stop.
Pattern 1: intake is copy-paste, almost everywhere
From seed-stage tools to a large analytics platform, the standard connection journey is the same: the customer generates a key or credential in the source system and pastes it into the vendor's app. Omni, a BI product valued at 1.5 billion dollars, has customers paste a standard connection URI of the form dialect://username:password@host:port/database after preparing a database user and allowlisting the vendor's IPs. Paste-based intake scales all the way up.
Pattern 2: what happens after the paste is undocumented
Of the 17 products reviewed, exactly one documents its custody architecture. The rest say nothing about where credentials live, what can read them, or how they are revoked. This is the central finding of the survey: intake is visible, and custody is not.
Pattern 3: the exception builds, the rest stay silent
TextQL, an AI data analyst, is the exception. Its public FAQ states that credentials are stored encrypted in its vault and injected at the network layer by an egress proxy, that admins whitelist each domain, and that the sandbox fails closed. No other product in the set documents anything comparable.
Pattern 4: catalogs cover the head, not the acting credentials
Basedash routes app-data sources through Fivetran, so those credentials go to Fivetran rather than to Basedash. Its core live-database path still takes pasted connection URIs directly. The outsourced credential layer covers analytics sync; the runtime path an agent actually uses does not.
Pattern 5: marketplaces are tightening at the head
Some marketplaces are adding controls. Guesty issues partner keys that expire in four hours if unused and publishes third-party access upgrade docs. Certified-OAuth-only programmes are appearing. Static keys are getting more controlled at the head while remaining the norm in the tail.
Pattern 6: the no-API tail is the rawest shape
Where a system has no API, such as some payer portals or property software, products operate through the customer's actual login. The vendor holds a raw username and password and automates the session in a browser. This is the rawest custody shape in the set, and it is common in operational niches.
Documents intake only vs Documents custody too
Frequently asked questions
How many of the products document custody after intake?
One of the 17. The rest document how they collect the credential and stop there. That gap is the survey's main finding.
What is the most common intake method?
Copy-paste. The customer generates a key or connection string in the source system and pastes it into the product. It appears from seed-stage tools up to a 1.5 billion dollar analytics platform.
What happens where a source system has no API?
The product typically uses the customer's own login, holding a raw username and password and automating the session in a browser. It is the rawest custody shape in the set.
Get the field notes: how 17 AI products handle customer credentials
Leave your email and we will send the field notes, compiled from public docs with sources. Alan, the founder, may ask one question about how your product holds credentials today. No list, no spam.
Where ScopeHold fits
ScopeHold is the custody layer this survey keeps finding missing. It stores customer credentials with KMS-wrapped envelope encryption, types them including login credentials, grants each agent only what it needs with expiry and revocation, resolves values at runtime through scopehold run, and logs every access including denials. It is aimed at products that document intake but have no custody answer yet.