AI Credit Data Privacy: What Your Assistant Sees When It Pulls a Credit Report

Here’s the short version of AI credit data privacy: when an assistant pulls a credit report through our server, the result lands in the conversation, and from that moment it goes wherever the conversation goes. To the model provider. Into chat history. Into a shared link, if someone makes one. The lookup itself is the most controlled part of the trip. Everything after it is up to settings you choose.

That’s not a reason to avoid connecting an assistant. It’s a reason to know the route. So let’s follow one request.

Saoirse Teague manages leasing for a few buildings. An applicant, Bram Holloway, signed the rental application with the credit check authorization. Saoirse opens her assistant, which is connected to our server, and types: “Run a rental check on Bram Holloway, (555) 555-0181. He signed the application today.”

Five things happen, and each one leaves something somewhere.

Stop one: our server

The assistant calls lookup_phone with the number and rental_application as the purpose. It does that with an OAuth access token it got when someone on Saoirse’s team connected it, not with a password or an API key someone pasted into a chat. Access tokens last an hour. We store only hashes of tokens, never the tokens themselves.

On our side, three records come out of this:

• The lookup. We keep it so get_lookup can return it later without charging again. It holds what you’d expect: name, current address, phone details, the FICO® Score 4 and its factors, the credit profile.
• The request log. Time, the tool, status, cost, which connected app made the call, and the last four digits of the number. Not the full number, not the result.
• The bill. $7.50, because someone was found. A no-match would have been free.

The data came from TransUnion as a soft inquiry, so Bram’s score isn’t touched and he gets no alert. None of that changes because an assistant asked instead of a person.

Stop two: the conversation (and the model provider)

The tool result goes back to the assistant as text: a one-line summary and the JSON. The model reads it to write its answer. That means the full result is now part of the conversation, sent to the model provider’s servers the same way Saoirse’s own messages are.

This is the stop people forget. The assistant isn’t a pipe that the data passes through untouched. It’s a reader, and the model provider hosts the reading.

Our server tells the model, in its instructions, that credit data is sensitive and should be shared only with the user who asked and only as much as they need. That’s a reasonable request to make of a model. It’s not a control. Treat it as manners, not as a lock on the door.

What the provider does with conversations after that depends on the assistant and on your plan. Many assistants have settings for how long chats are kept and whether conversations can be used to improve their models, and business or team plans often come with different terms from personal ones. Read yours before connecting anything that returns credit files. If your assistant’s documentation for connectors has a section on data, read that too; Claude’s help page on custom connectors is a good example of the kind of page to look for.

Stop three: chat history and memory

Saoirse closes the tab. The conversation doesn’t go away. It sits in her chat history, searchable, with Bram’s name, address and score in it.

That’s often fine. She’s the person with the permissible purpose, and it’s her account. But think about who else can open it. A shared login at the front desk. A team workspace where admins can see conversations. A laptop that goes home.

If your assistant has a memory feature that carries facts from one chat to the next, think harder. A score that shows up in an unrelated conversation three weeks later isn’t a breach in the dramatic sense, but it is credit data being used outside the purpose it was pulled for. Under 15 U.S.C. § 1681e(a), users of consumer reports certify the purpose they’re getting the report for and that it won’t be used for any other. “The assistant remembered” is not a purpose. For most teams, turning memory off on the accounts that run lookups is the simple fix.

Stop four: wherever people copy it

The assistant writes a nice summary. Someone pastes it into a group chat, a ticket, a CRM note field that thirty people can read, or a shared conversation link sent to a co-worker “so you can see what it said.” Shared links can carry the whole conversation, tool results included, depending on the assistant.

None of this is specific to AI. People have been emailing PDF credit reports to the wrong address for decades. The difference is speed: a chat makes copying feel free. Decide in advance where results are allowed to live (your screening system, your loan file) and say it out loud to the team. We’ve written about the FCRA and AI agents and about permissible purpose if you need the reasoning for the policy.

Stop five: your own systems

Say your property software listens for our webhooks. When the lookup completes, it gets a lookup.completed event with an ID, a status, the cost and your reference. No name, no address, no score. That’s deliberate: webhook payloads never include personal or credit data, so a misconfigured endpoint or a logging proxy in the middle leaks nothing worth having. Your server fetches the details with its own key when it actually needs them. The lead routing build shows the pattern.

Give the assistant less to see

You can’t stop a model from reading what a tool returns. You can control which tools it has and what they’re allowed to do. That’s where the consent page comes in. When someone connects an assistant, they choose:

• Permissions. Running lookups, reading past lookups, adding tradelines, usage, logs, account info, and staying connected (refresh tokens). Only the tools those permissions allow are even listed to the model.
• Live or test. A test connection returns sample people and is free. Great for learning, and for demos where nobody’s real file should appear on a projector.
• How long it lasts. 30 days, 90 days, a year, or until you disconnect.
• A monthly spending limit for that connection, and whether a person approves each paid lookup.

Least privilege here is concrete. An assistant that only explains past lookups doesn’t need to run new ones. One that helps with billing questions needs usage, not lookups. The account-wide spending limit still applies on top of anything per-connection. And one detail worth knowing: list_lookups returns IDs, status, the last four digits, purpose, reference and cost, with no personal details. An assistant answering “how many checks did we run this month?” never has to touch a credit file to do it.

Approvals help privacy too, not just the budget. With “approve each” on, a paid lookup waits until a person clicks approve on Apps & AI, so nobody’s file is pulled because an assistant misunderstood a sentence. The approvals launch post covers how that works.

If your account has an IP allow list, it applies to connected apps by default. Assistants call from their own servers, so the consent page warns you, and an admin can turn IP rules off for apps specifically. Make that choice on purpose rather than by clicking through.

Disconnecting, and what it does and doesn’t erase

Every connection shows on API / Developer, then Apps & AI, with what it spent this month. Disconnect, and it stops immediately: the tokens are cancelled and the next call fails. Refresh tokens also rotate on every use and expire after 30 days unused, and if an old refresh token is ever reused, we cancel the whole connection, on the theory that someone copied it.

What disconnecting doesn’t do is reach into the assistant and delete the conversations that already happened. Those live with the assistant provider, under their retention settings. If a chat holds a file it shouldn’t, delete it there.

Where the GLBA Safeguards Rule fits

If you’re a lender, broker, dealer offering financing, or another non-bank financial institution under FTC jurisdiction, the Safeguards Rule (16 CFR Part 314) already asks for a written information security program, a qualified person in charge of it, access controls, encryption, and oversight of service providers that handle customer information. An AI assistant your staff use to pull and discuss credit files belongs in that program like any other system: who can use it, which accounts are connected, what the provider keeps, and how you’d know if something went wrong. The rule also requires notifying the FTC of certain security events involving the information of 500 or more consumers.

None of this needs a new framework. It needs a line in the inventory and an owner. This isn’t legal advice, and your counsel or security lead should make the call on how your program treats it. Our compliance page covers what we do on our side.

An AI credit data privacy checklist for your team

Short enough to tape to a monitor:

1. One owner. Someone decides which assistants get connected and reviews Apps & AI monthly.
2. Read the assistant’s data settings before the first live lookup: retention, training, sharing, admin access. Write down what you chose.
3. Turn off memory on accounts that run lookups, if the assistant has it.
4. Smallest permissions that work. Read-only for explainers. No lookups for billing helpers.
5. Start in test mode. Switch to live only after the team has done a few practice runs with sample people.
6. Per-connection limits and approvals for shared or new assistants.
7. A purpose before every lookup, stated by the person, never filled in by the model. Keep the signed authorization, like the consent forms we’ve described before.
8. One home for results. Your screening or loan system. Not group chats, not tickets, no shared chat links.
9. Delete chats you don’t need, on a schedule that matches your records policy.
10. Disconnect on day one when someone leaves, along with every other account.

If you’re building your own agent instead of connecting an off-the-shelf one, the same ideas apply in code: keep logs free of personal data, give the model a short tool list, and let your system, not the model, set the purpose. The credit check agent tutorial shows one way. For the broader picture of which tools can do what, see pulling credit reports with AI, and for what the server is in the first place, the MCP server launch post. Longer-term storage of report data is its own topic, which we’ll get to in a post on storing credit report data.

Last practical tip: ask your assistant, in a test connection, to show you exactly what the lookup tool returned. Seeing the raw result once, in the chat window, does more for a team’s habits than any policy document.