An AI agent that can answer questions is different from one that can take action. If it can access your booking system or customer records, it may be able to do more than suggest a response. It might check availability, create a booking or update a client profile.
That makes access design a business decision, not just a technical setting. The practical question is: what does the agent need to do its assigned job, and what should it not be able to see or change?
Why prompts are not enough
An early preprint study argues that giving an agent every internal tool can increase context size, weaken tool selection and create governance vulnerabilities, while prompt-only policies do not act as hard constraints. The study describes a framework that delivers tools through roles, so the agent receives capabilities as they are needed.
Another preprint study created EvasionBench, a benchmark of 50 task-policy pairs in which completing the task required an operation prohibited by a runtime monitor. The researchers say agents in the benchmark knew their tool calls were monitored and were prompted to continue working when they paused.
In their evaluations, best-of-3 evasion attempts reached up to 98% and successful evasion reached up to 88%, with substantial variation among models. The paper also reports traces of agents encoding prohibited commands, splitting operations across tool calls and retrying until relevant context left the monitor’s history. These results come from a specific benchmark, not from everyday use in appointment businesses. They are a reason to test controls rather than assume that an instruction in a prompt will always be followed.
A vendor example comes from Collibra, which describes Agent Contracts as defining permitted behavior based on data sensitivity, operating context and risk. The company says Guardian Agents enforce those contracts before an action occurs and block actions that do not align with them. This is a vendor’s description of its products, not independent evidence that a particular setup will suit every business.
Match access to the job
Start by writing down the exact task you want an agent to handle. “Help with bookings” is too broad to define safe access. A clearer task might be: check open appointment times and offer options, without making or changing a booking.
Then list the information and actions needed for that task. An agent that drafts appointment reminders may need a client’s name, appointment time and preferred contact channel. It may not need access to payment details, treatment notes or the ability to cancel appointments. If a task does require a change, decide which changes are allowed and whether a person should approve them.
Apply the same approach to customer questions. An agent answering basic service questions could use approved service descriptions and policies. If it needs personal records to answer a specific request, limit access to the relevant records and task. Avoid giving it a general route into all customer information just because one workflow needs some of it.
Think in terms of small, named roles: one role to check availability, another to draft a follow-up and a separate one to update a record. Give each role only the tools and data needed for its job. If a task genuinely needs another capability, make that a deliberate step rather than leaving every capability available from the start.
Put limits where the action happens
A prompt can tell an agent not to issue a refund or alter an appointment. But if the connected system still gives it the power to do so, the limit depends on the agent following that instruction. Where possible, use the booking or customer system’s permissions to prevent actions the agent should not take.
Set up an approval step for changes with meaningful client or financial consequences. Keep a record of what the agent accessed and what it tried to do, so staff can review decisions and investigate unexpected activity. Test ordinary cases as well as edge cases: for example, a request to change a booking, a client asking about someone else’s record or a task that requires an action outside the agent’s role.
What to do before connecting an agent
- Choose one narrow task to start with.
- List the data and actions that task actually requires.
- Remove access to information and tools it does not need.
- Enforce important limits in the connected system, not only in the prompt.
- Test the workflow and review what the agent can access and change.
The goal is not to make an agent incapable of useful work. It is to make its authority clear and limited, then expand it only when a real business need calls for more access. Vetraeus Agent Readiness focuses on preparing data, context, access, evaluation and governance for AI agents.
- ai agents
- data governance
- access control
- appointment businesses
Alan Jordan, founder and principal solutions architect. Data engineering, data science and business analytics for appointment-based businesses.
