# 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:

- [ ] Database / warehouse
- [ ] Source code repository
- [ ] Internal API
- [ ] Ticketing / support system
- [ ] Queue / event stream
- [ ] Filesystem / document store
- [ ] Other:

## 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:

- [ ] Tool placement decision
- [ ] Command handler source
- [ ] Generated runtime permissions
- [ ] Credential storage and rotation notes
- [ ] Network egress list
- [ ] Data-boundary table
- [ ] Telemetry / audit event list
- [ ] Revocation procedure

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.