How to Write an AI Agent Subprocessor Disclosure Statement

What an AI Agent Subprocessor Disclosure Statement Is

In the context of an AI agent, a subprocessor is any model provider, tool, connector, or downstream service that the agent calls on to complete a task and that, in doing so, processes data on the organization's behalf. A subprocessor disclosure statement is the record that names those parties and explains what each one is allowed to see and do.

A complete disclosure answers four questions: which foundation models the agent calls, which tools and connectors it invokes, what categories of data pass to each of those parties, and which permission scopes or roles authorize that access. Because agents can chain multiple calls together in a single task, these four elements need to be documented together rather than as separate, disconnected lists.

Why Static Subprocessor Lists Don't Fit Autonomous Agents

Traditional subprocessor disclosures were written for a fairly stable set of vendors: a company signed a contract with a payment processor or an email service, and that relationship was reviewed and updated on a fixed schedule, often once a year. That model assumes the list of subprocessors changes slowly and predictably.

An AI agent does not behave that way. The same agent can invoke a different combination of models and tools depending on the task it is given, the connectors that have been enabled for it, and the way it chains calls together to reach an outcome. A tool that was never used in January may be invoked routinely by March simply because a new connector was added to the agent's toolset. A disclosure written from a fixed, manually maintained list will drift out of date the moment the agent's behavior changes, even if no one updates the contract paperwork.

This is why the disclosure needs to be grounded in evidence of what the agent actually does, meaning the runtime logs of every model call, tool call, and permission grant, rather than in a document assembled from memory or from procurement records alone.

Aligning Disclosure Structure With Governance Frameworks

Most organizations already have a vendor risk management or third-party governance process that reviews subprocessors on a recurring basis. An agent subprocessor disclosure should plug into that existing process rather than replace it, but the underlying evidence needs to come from the agent's own runtime activity so the review is checking something accurate.

In practice, this means structuring the disclosure around the same four elements described above and keeping each one traceable back to a source of record:

• Model invocations traced to the agent's call logs, including provider and version.
• Tool and connector calls traced to the agent's identity and the specific API or connector endpoint used.
• Data categories traced to what was actually observed in request and response payloads, not just what a connector is theoretically capable of accessing.
• Permission scopes traced to the roles and grants that authorized each call in the first place.

When each line of the disclosure can be traced back to a log entry or a permission record, the document becomes something a governance or legal reviewer can verify rather than simply accept on trust.

Building and Maintaining the Disclosure

Producing an accurate disclosure statement is less a writing exercise than a data pipeline exercise. The steps below outline how to build one from runtime evidence and keep it current as the agent's toolset evolves.