Copyable resource

Private-data agent tool placement worksheet

A worksheet for deciding where AI agent tools should run when data is private or network-local.

Private-data agent tool placement worksheet

Use this before building an enterprise agent connector. The question is not "can the model call the tool?" The question is where the tool can run without breaking the customer's network, data, or security review.

Product:

Customer / segment:

Tool:

Private system reached:

1. Placement test

Question	If yes	Answer
Does the tool need to query a database, repo, queue, or API that has no public endpoint?	Run the tool in the customer's environment.
Would copying input data to your cloud trigger legal, residency, or contract review?	Keep the lookup local and return a derived result.
Does the tool need credentials owned by the customer?	Store credentials in the customer's vault and link them to the worker.
Would a stale copy make the agent wrong or dangerous?	Query at execution time instead of replicating.
Does the customer need to inspect what the agent can do?	Make each action a named command handler, not a tunnel.
Do you need to improve the model loop every day?	Keep orchestration central; keep private data access local.

Decision:

Tool can run centrally.
Tool must run in the customer's environment.
More of the agent loop must run in the customer's environment.
Do not offer this tool to this customer yet.

2. Data boundary

Document exactly what can leave the customer's environment.

Input / source	Raw data leaves?	Derived output returned	Redaction / limit	Reviewer notes

Pass condition:

The handler output is the data boundary.
Raw rows, files, secrets, or source code do not leave unless explicitly approved.
Result size and fields are bounded in code.
The customer can inspect the handler that creates the output.

3. Command contract

List every action the agent can trigger inside the customer environment.

Command	Handler source file	Inputs	Output	Permissions used	Audit event

Rules:

No generic shell endpoint.
No arbitrary SQL endpoint.
No "fetch anything by URL" helper unless the allowed destinations are explicit.
Each command should have one purpose, a typed input, a bounded output, and an audit event.

4. Credential model

Credential	Stored where	Used by	Rotation owner	Can vendor read value?

Pass condition:

Customer-owned credentials remain in the customer environment.
Vendor cannot read secret values through the management path.
Runtime access is scoped to the command handler that needs it.
Revocation is documented.

5. Network model

Inbound access:

None.
Required. Explain:

Outbound access:

Source	Destination	Protocol	Purpose	Can be disabled?

Pass condition:

No VPN or reverse tunnel is required for normal operation.
Pull-mode tools connect outbound over HTTPS if inbound access is not allowed.
Private endpoints stay private.

6. Review packet

Attach these before asking the customer to approve the tool:

Final note:

The goal is not to prove that no trust exists. The goal is to show exactly what code can run, what permission it uses, what data can leave, and how the customer turns it off.

Copyable resource

Private-data agent tool placement worksheet

A worksheet for deciding where AI agent tools should run when data is private or network-local.

Private-data agent tool placement worksheet

Product:

Customer / segment:

Tool:

Private system reached:

1. Placement test

Question	If yes	Answer
Does the tool need to query a database, repo, queue, or API that has no public endpoint?	Run the tool in the customer's environment.
Would copying input data to your cloud trigger legal, residency, or contract review?	Keep the lookup local and return a derived result.
Does the tool need credentials owned by the customer?	Store credentials in the customer's vault and link them to the worker.
Would a stale copy make the agent wrong or dangerous?	Query at execution time instead of replicating.
Does the customer need to inspect what the agent can do?	Make each action a named command handler, not a tunnel.
Do you need to improve the model loop every day?	Keep orchestration central; keep private data access local.

Decision:

Tool can run centrally.
Tool must run in the customer's environment.
More of the agent loop must run in the customer's environment.
Do not offer this tool to this customer yet.

2. Data boundary

Document exactly what can leave the customer's environment.

Input / source	Raw data leaves?	Derived output returned	Redaction / limit	Reviewer notes

Pass condition:

The handler output is the data boundary.
Raw rows, files, secrets, or source code do not leave unless explicitly approved.
Result size and fields are bounded in code.
The customer can inspect the handler that creates the output.

3. Command contract

List every action the agent can trigger inside the customer environment.

Command	Handler source file	Inputs	Output	Permissions used	Audit event

Rules:

No generic shell endpoint.
No arbitrary SQL endpoint.
No "fetch anything by URL" helper unless the allowed destinations are explicit.
Each command should have one purpose, a typed input, a bounded output, and an audit event.

4. Credential model

Credential	Stored where	Used by	Rotation owner	Can vendor read value?

Pass condition:

Customer-owned credentials remain in the customer environment.
Vendor cannot read secret values through the management path.
Runtime access is scoped to the command handler that needs it.
Revocation is documented.

5. Network model

Inbound access:

None.
Required. Explain:

Outbound access:

Source	Destination	Protocol	Purpose	Can be disabled?

Pass condition:

No VPN or reverse tunnel is required for normal operation.
Pull-mode tools connect outbound over HTTPS if inbound access is not allowed.
Private endpoints stay private.

6. Review packet

Attach these before asking the customer to approve the tool:

Final note:

The goal is not to prove that no trust exists. The goal is to show exactly what code can run, what permission it uses, what data can leave, and how the customer turns it off.