Before a tool reads client text

A subcontractor wants a new tool to read the client's text. Before that tool is allowed on, three things, and you do them. You have opened the vendor the text will reach, in an account the agency or the client administers, and you can name who else is a member. You can say, in one sentence you could forward, what the tool sends and what that vendor is allowed to keep. You can turn the tool off without turning off the product the client already bought. If any of the three is "the partner said it is fine," the tool stays off. A sentence you cannot check is not a control. It is a status line.

This is the hour before a new provider exists. It is not the review of a diff the partner already wrote, which asks whether you can explain a change that is about to ship under your name. It is not the list of what a person may touch in the client's cloud. A human account and a tool that copies text to a company the client has never heard of fail in different places, and closing one does not close the other. It is not the decision about the model organization you already hold. That organization is the account for the model you sold. A tool added on a Thursday is a second account, with its own terms, its own retention, and its own admin. Treat it as a new vendor or do not connect it.

The control catalogues already assume you do not operate the outside service yourself. NIST SP 800-53 Rev. 5, control SA-9, External System Services, tells the organization to do three things. Require that providers of external system services "comply with organizational security and privacy requirements and employ" an organization-defined set of controls. "Define and document organizational oversight and user roles and responsibilities with regard to external system services." And employ organization-defined processes "to monitor control compliance by external service providers on an ongoing basis." The discussion is the part an agency can use without pretending to be a federal system: "External system services are provided by an external provider, and the organization has no direct control over the implementation of the required controls or the assessment of control effectiveness." The responsibility "remains with authorizing officials." A chain of trust "requires that organizations establish and retain a certain level of confidence that each provider in the consumer-provider relationship provides adequate protection," and "organizations document the basis for the trust relationships so that the relationships can be monitored" (NIST, SP 800-53 Rev. 5, September 2020, updated 10 December 2020, SA-9).

The blanks in that control are the point. "Organization-defined" means the agency writes the list. NIST does not name your client's tool, and it does not fill in the roles. If the only place the vendor's name appears is a Slack message from the partner, you have not documented the basis for the trust. You have repeated theirs. No direct control means you will not get to patch their service. What you can do is refuse to send the client's text until you have seen the account, the terms, and the off switch. That refusal is the oversight role SA-9 asks you to write down. It is not a certification, it is not legal advice, and it is not a claim that a commercial agency is the kind of organization the catalogue was drafted for. The shape of the duty is what transfers. Someone on your side is the person who may accept the provider. The partner's engineer is a user of a service you accepted, or they are not a user of it at all.

There is a measured number for supply-chain failure in ordinary software, and the page that prints it does not agree with itself. OWASP's 2025 Top 10 ranks Software Supply Chain Failures as A03. The background says the category "was top-ranked in the Top 10 community survey with exactly 50% respondents ranking it #1," and that "when tested and reported in the contributed data, this category has the highest average incidence rate at 5.19%." The score table on the same page prints a different average. Average incidence rate 5.72%. Maximum incidence rate 9.56%. Maximum coverage 65.42%. Average coverage 27.47%. Total occurrences 215,248. Total CVEs 11. CWEs mapped 6 (OWASP, A03:2025 Software Supply Chain Failures). Quote the table when the prose and the table disagree. The prose's 5.19% is not the cell labeled average incidence. This article does not decide which of those two averages is the one OWASP would stand behind, and it does not recompute the other nine categories to test the word "highest."

Read the rest of the page before you borrow the number for a chatbot plugin. 50% is a share of survey respondents who ranked the category first. It is not an incidence rate, and the page's own grammar is "50% respondents," which is a ranking vote. Coverage is not incidence. 65.42% maximum coverage is the highest coverage in the contributed sets, and 27.47% is the average coverage. A sentence that quotes 65.42% alone has quoted the maximum. 215,248 is occurrences in that testing data. It is not 215,248 AI tools, and it is not a count of agencies. 11 CVEs is the page's count of CVEs tied to the related weaknesses, and the page says the category is hard to identify for that reason, so a small CVE count is not a small risk in their telling. The background names four weaknesses, including CWE-477 labeled "Use of Obsolete Function." The mapped list at the bottom has six entries, and it labels CWE-447 with the same words, "Use of Obsolete Function." Two identifiers, one phrase, one page. Do not treat them as a single confirmed weakness until you have opened the CWE catalogue yourself. The page's attack stories are a compromised software vendor, a wallet-software theft it prices at $1.5 billion, and a package worm. Those are supply-chain failures. They are not a measurement of the tool your partner wants to switch on this week, and the dollar figure is the page's figure for that theft, not a loss you should paste into a client email.

The AI-specific catalogue is a list of ways a model supply chain fails, and it is not a rate. OWASP's 2025 entry on LLM supply chain says traditional software vulnerabilities "focus on issues like code flaws and dependencies," and "in ML the risks also extend to third-party pre-trained models and data." Item 9 is the one that matches a tool you have not read: "Unclear T&Cs and data privacy policies of the model operators lead to the application's sensitive data being used for model training and subsequent sensitive information exposure." The prevention line beside that family of risks says to "carefully vet data sources and suppliers, including T&Cs and their privacy policies, only using trusted suppliers," and to review them again so a change in terms does not arrive as a surprise (OWASP, Top 10 for LLM Applications 2025, LLM03:2025). This is a list of risks the project chose to publish. It does not say the tool in the partner's pull request is training on your client. It says unclear terms are the path by which that happens, which is why "the partner uses it" is not a vetting. A model card, the same entry notes, offers "no guarantees on the origin of the model." A logo on a settings screen is even less than a model card.

Walk the three checks against the actual tool, not against the category. Open the vendor. Create nothing in the partner's tenant. The account that will receive the client's text is one you can log into, or one the client can log into, and the partner's people are members you can remove. If the free trial they started on a laptop is the only account, that trial is the production path until you replace it, and a free trial whose terms allow training on inputs is a decision you have already made by leaving it in place. Write the sentence. Name the fields that leave your network, the vendor's legal name, and whether inputs are used to train, retained, or both, using the page you opened rather than a paraphrase from memory. If the page is ambiguous, the sentence is "we cannot say," and the tool stays off. Ambiguous is a result. It is not a delay. Then find the off switch that is not the whole product. A configuration flag, a credential you can revoke, a route that stops calling the tool while the rest of the feature still answers. If the only way to stop the tool is to unplug the feature the client is paying for, you do not have a switch. You have a coupling, and SA-9's monitoring duty is how you notice it before the first real document is sent.

What you refuse, even when the demo looked useful. A tool whose only administrator is the subcontractor. A browser extension on a machine you do not control, pointed at a production export. A "temporary" key that can read the client's rows, pasted into a notebook so the prototype can be shown on Friday. A second model vendor slipped in beside the one you already contracted, because the new one is cheaper on a benchmark you have not run. The account you already decided to keep, the production keys, and the evaluation you can run without the partner, are what to keep when you subcontract AI. A new tool does not inherit that decision. Human access to the repository and to production write is what access to give a subcontractor. The tool is the grant that list does not cover, in the same way the model account was the grant that list did not cover. The acceptance sentence the client was sold, which is what this tool is supposed to change, belongs in what a white-label brief must hold. If the brief never named a tool, adding one is a change of scope, not a library update.

The code review still happens, and it does not replace the three checks. A diff can show the function that calls the vendor. It cannot show you the terms, the retention, or the admin list, unless those are in the diff, which they almost never are. Read their change before it ships is the hour you spend on the diff, including a prompt or a tool definition that is about to ship under your name. Do that hour. Then do this one. A pull request that adds an endpoint and a comment reading "uses Vendor X" has given you a name. The name is the start of the sentence, not the sentence. Shipping the endpoint because the diff was small is how a provider arrives in production without anyone opening the account. Small is a property of the patch. It is not a property of the trust decision.

What a tool you can re-open looks like is a record outside the partner's laptop. Inflectiv Helios is a multi-assistant platform we built under our own name, with prompt monitoring on a dashboard. It is not a white-label engagement and it should not be read as one. Nothing in that description is a headcount, a duration, or a result figure. The shape is the point: something that reads text in production is something you can look at after the person who added it has closed their editor. A subcontracted tool that exists only as a URL in a chat thread is the object this article refuses, because you cannot open it twice, and you cannot remove a member you cannot see. Engagements of the agency kind sit under the same non-disclosure we would sign with you, so they are not on this site as case studies. A partner willing to paste last client's documents into a new tool in order to win the demo will paste this client's in order to win the next one.

There is a version of the request where hiring a review is the wrong purchase. The work is not sold, so there is no client's text to protect. That is a sales question. The client has asked to meet the people who would add the tool. That is a disclosure decision, and it is not a reason to skip the vendor page or to pretend the tool is yours. The room only has a slide. There is no account to open and no sentence to write, and a review of a picture is a meeting. The tool is the model organization you already named, with no new provider and no new retention, and the only change is a member list. That is the account article, and the action is to remove or add a member, not to start this checklist from zero. Or the buyer only wants you to walk a fixture while they watch. The hour before the client sees the product is a demo check. Do not substitute the demo for the terms. A tool can impress a room and still be an account you cannot administer on Monday.

Before you tell the client the tool is in, do the three checks and write down which one failed. Open the vendor as yourself. Write the sentence about what leaves and what is kept, or write that you cannot. Find the off switch that leaves the rest of the product up. If you cannot do the first one, you are about to put your name on a provider you have not seen. A white label software development partner that expects this will put the new account in your organization, or in the client's, before the first document is sent, because the reading takes them nothing they were not already doing for the model they sold. One that can only offer a login on their laptop is telling you who the vendor will call when the terms change. Where the next slice is a single capability and the acceptance sentence already names the tool, an AI integration sprint is the shape that can require these three checks as the definition of done. The number you will later be asked to stand behind, if the tool changes what the system returns, is the same discipline as AI evaluation and observability: a result you can re-run after the provider is connected, on cases you froze before they could tune to it. The vendor page is how you notice a new company is in the path. It is not a substitute for having run the cases.

If you do not yet know whether the client's data can be sent anywhere at all, the engagement that fits is shorter than a build. A two-week AI readiness assessment maps the systems and the copies, and the findings are yours whether or not anyone connects the tool. Those are the terms. They are not a promise that every new library is a supply-chain incident, and they are not a rate. The 5.72% on OWASP's table is a testing average for a software category. It is not your client's probability. Your client's probability is whatever you can observe after you have opened the account. Until you have opened it, the honest number is that you do not have one.