Applied AI
Define safe boundaries for AI tool actions
Connecting an assistant to a tool changes the risk from an incorrect answer to an incorrect action. Define narrow operations, enforce authorization outside the model, and specify how execution is verified and interrupted.
A tool-enabled assistant can affect records, messages, and business processes beyond the chat window. Decide its authority before choosing an agent framework. The useful question is not whether the assistant can call a tool. It is which operation it may request, on whose behalf, against which target, and under what conditions.
Write a capability contract
Describe each allowed operation in business terms. Separate reading a record, drafting a change, applying a change, and deleting a record. OWASP identifies excessive functionality, permissions, and autonomy as root causes of excessive agency.[4] One broad administrative connection can therefore create a very different risk from a narrow lookup.
For each operation, specify allowed inputs, target scope, maximum effect, and required approval. Prefer a dedicated action such as creating a draft appointment over a general command interface. Remove tools that are no longer needed. A tool description explains intent, but the implementation must enforce the actual boundary.
Authorize at the execution boundary
OWASP recommends validating downstream requests against security policies and executing actions in the appropriate user context with minimal privileges.[4] Do not delegate the authorization decision to generated text. Check both the caller and the target when the action reaches the application service.
Reject invalid identifiers, disallowed destinations, and values outside the operation’s permitted range. Recheck relevant business conditions immediately before a write. A user may have lost access, or the record may have changed since the assistant prepared its proposal. Treat model output as a request for validation, not as a trusted execution instruction.
Review the action boundary
Use this checklist for each tool rather than approving the agent as a single unrestricted component. Test denied requests as well as successful ones.
- Separate read-only credentials from identities that can modify data.
- Restrict target records and destinations to the requesting user’s authorized scope.
- Require explicit approval for operations with significant external consequences.
- Set limits on repeated actions and provide a way to disable execution.
- Record the requested action, validation decision, execution result, and verified target state.
Hypothetical example: a scheduling assistant
A hypothetical equipment service company lets an assistant propose appointments. The assistant can inspect available slots and create a draft, but cannot cancel unrelated appointments or change service eligibility. A customer confirms the exact slot before the scheduling service validates and applies the request.
If a timeout leaves the result unclear, the application checks the appointment record before attempting another booking. It does not assume that no response means no change. If the check remains inconclusive, the request moves to an operator rather than permitting another unattended attempt.
Decide what happens when controls block work
A narrower tool set may require extra handoffs and cannot support every request in one conversation. Make those limits visible. Offer a manual route when validation fails, and preserve enough context for the authorized operator. Expand capabilities one operation at a time only after its failure cases and recovery path are understood.
