Before an existing AI agent gets access to a new tool or system, a team should submit a tool connection request. It records who is asking, which operations the agent needs, at what depth, what data it will touch, what it must still refuse, and who approves. No tool is connected without one.
Why should tool access need a request?
Every tool an agent can call widens what it can do. A new read tool changes what the agent knows; a new write tool changes what it can break. Treating access as a request, rather than a configuration change, puts a decision and a name behind each widening. If the concept of tools is new to your team, start with what tool use is.
The deeper reason is that every tool call is a decision. An agent that can call a tool will, at some point, call it in a situation nobody pictured. The request forces the requester to picture some of those situations in advance.
The request is separate from, and comes before, the technical integration design. It answers "should the agent have this?"; the design answers "how exactly?".
How do you complete each field?
The requester fills in most of the form. Risk and the system owner add their assessment. Keep answers short and specific.
- Agent and brief version. The request must reference the current brief in the agent brief template. If the brief does not already describe the capability, it will need to change too.
- Business reason. What the agent cannot do today, and what that costs customers or staff. "Customers wait for a person to check delivery status" is a reason. "It would be useful" is not.
- Operations requested. Name each one. Read and write listed separately.
- Depth requested. Per operation. If any operation would raise the agent above its current depth for a capability, also file an autonomy change request.
- Data touched. Personal data, payment data, special category data. Say which.
- Refusals that must survive. What the agent will still decline even with the tool. This is the field reviewers most often find empty.
- Reversibility. For each write, can it be undone, by whom, and how fast.
- Certification impact. Whether new cases are needed and whether a re-run is required before go-live.
The tool connection request template
| No. | Field | Entry |
|---|---|---|
| 1 | Request reference and date raised | |
| 2 | Requester and agent owner | |
| 3 | Agent name and brief version | |
| 4 | Tool or system requested, and its owner | |
| 5 | Business reason | |
| 6 | Capability in the brief this serves | |
| 7 | Operations requested (read / write) | |
| 8 | Depth requested per operation | |
| 9 | Data touched and its classification | |
| 10 | What the agent does today without the tool | |
| 11 | Refusals that must survive the connection | |
| 12 | Reversibility of each write | |
| 13 | Worst plausible misuse and its effect | |
| 14 | Certification impact | |
| 15 | System owner assessment | |
| 16 | Risk assessment | |
| 17 | Decision: approved, approved in part, declined | |
| 18 | Approver names and conditions |
A filled example: support agent and order system
A retailer's support agent wants access to the order management system.
| No. | Field | Entry |
|---|---|---|
| 5 | Business reason | Customers asking "where is my order" wait for a person to look it up |
| 6 | Capability served | Answer order and delivery questions |
| 7 | Operations requested | Get order status (read); get tracking reference (read); cancel unshipped order (write) |
| 8 | Depth requested | 1; 1; 3 |
| 9 | Data touched | Name, delivery address, order contents |
| 10 | Today | Agent tells customer a person will reply by email |
| 11 | Refusals | No address changes after dispatch; no cancellation for a caller who has not passed identity checks |
| 12 | Reversibility | Cancellation of an unshipped order cannot be reinstated; customer must reorder |
| 13 | Worst misuse | Agent cancels an order on a request from someone who is not the customer |
| 14 | Certification impact | New cases for order queries; cancellation needs its own set |
| 17 | Decision | Approved in part |
| 18 | Conditions | Both reads approved. Cancellation approved at depth 2 only: the agent drafts, a person confirms, until the cancellation set passes |
The partial approval is common and healthy. The reads were low risk. The cancellation could not be reversed, so it went to depth 2 until evidence existed. Field 11 also shapes how the agent declines; how an AI support agent should refuse a request covers the wording.
Where Pryme fits
In Pryme, a tool connection is added to the agent's brief as one or more capabilities, each with its own depth. The connection cannot be used above depth 1 until Attest has certified that capability on your cases. Requests and approvals sit alongside the brief history in the governed agentic operating system.
Questions people ask
Can several agents share one tool connection request?
Each agent needs its own request, because the depth and certification attach to the agent. A shared business case is fine, but the decision is recorded per agent.
What if the tool vendor changes the operations it offers?
Treat new operations as unapproved until a request covers them. Your integration should expose only the operations named in the approved request, so a vendor update does not quietly widen access.
Should read-only access need a request?
Yes, a lighter one. Reading can expose personal data and shapes what the agent tells customers, so the reason and the data touched should still be recorded.