Architecture
Every tool call needs a boundary.
Defining a tool is one step. Connecting it to a real system requires decisions about identity, authority, execution boundaries and the record that remains afterwards.
Connect the resource
Keep system credentials behind a defined resource boundary. Identify the database, internal API or external service a tool may reach, the environment it belongs to and the operations it may expose.
Resolve authority before execution
Evaluate the caller, the permitted action and the scope of the request before using system credentials. A model choosing an action is not the same as an authorised person approving it.
Bound the execution
Set time limits, input validation and failure behaviour. For actions that change a system, consider approval, idempotency and recovery before treating retries as harmless.
Retain useful evidence
Record the tool, outcome, decision and correlation identifier. Logging should be designed around investigation needs and data minimisation, rather than storing every sensitive input and output.
Discussion outputs
- Resource and action inventory
- Identity and permission model
- Failure and recovery scenarios
- Deployment boundary and evidence requirements
Bring one concrete operation