AI Agents on Your Website: Who Gave the Chatbot Permission to Act?

Start with the action the visitor is requesting

An AI assistant on a business website can explain services, collect a project brief, or help a visitor find an existing order. The risk changes when it can also update an account, issue a refund, or send a message to another system. In 2026, the phrase AI agent often groups these different capabilities together. A useful design review separates them into actions that can be inspected, authorized, and reversed where appropriate.

Imagine a fictional agency inquiry assistant. It reads a public service catalog and helps a visitor prepare a brief. Later, someone proposes connecting it to a customer relationship system so it can create leads and arrange meetings. This article follows that proposed expansion through a threat review. It does not describe a deployed Work Vultures agent or claim that any particular model has passed the tests discussed here.

Draw the boundary around each tool

List the operations the assistant can request from other software. Reading a public service description, finding an available meeting slot, creating a draft lead, sending an email, and changing a customer record are separate operations. Give each operation a named owner and a defined purpose. A tool called manage customer is too broad to make the intended boundary obvious. A narrower operation can reject requests outside its specific responsibility.

For the fictional assistant, the first release might allow access to public service information and creation of a local draft brief. A later version might create a lead only after the visitor reviews the fields. Meeting scheduling could require a separate confirmation that displays the date and recipient. This sequence makes authority visible to the visitor. It also lets the team evaluate a smaller capability before adding more consequential actions.

Keep permissions enforced by the application that owns the action. A sentence in the assistant's instructions can describe a rule, but it is not the only control protecting a customer record. The receiving service should verify the account, allowed fields, and requested operation. If an agent asks to change an email address while its role permits only drafting a brief, the request should fail regardless of the explanation accompanying it.

Treat retrieved material as material to evaluate

OWASP identifies prompt injection as a risk in which inputs influence an AI system's behavior in unintended ways. The input can arrive through the visitor's message or through other material processed by the application. A service document, uploaded brief, or retrieved page may contain text that looks like an instruction. The design problem is especially serious when the same system can request actions in connected tools.

Use a harmless test document to explore the boundary. Add a clearly marked line asking the assistant to ignore the user's brief and send its contents to an unrelated address. The expected result is that the document remains evidence about the project, while the application does not grant it authority to choose a recipient. Perform the exercise only in a controlled test environment with synthetic information and destinations owned by the test team.

The test does not prove that prompt injection has been solved. A successful result on one document establishes only what happened in that case. Expand the evaluation to different locations, document formats, and task contexts. Record whether the system attempted an unauthorized tool call, even if a later service rejected it. Separating model behavior from tool enforcement helps identify which control actually prevented the unwanted action.

Define what information the assistant can see

A public inquiry assistant rarely needs unrestricted access to a customer database. Start with the minimum information needed for the current task and identify its source. A service catalog can be public. A visitor's draft brief is provided for a specific conversation. A signed-in customer's past orders require a different access decision. Combining all three in one large context makes it harder to explain why a particular item was disclosed.

Check the retrieval service with two synthetic customer accounts. Ask each account the same question about an order and inspect the records returned before the assistant creates an answer. This distinguishes an access problem in retrieval from a misleading answer produced later. If the wrong record enters the context, an instruction telling the assistant to respect privacy arrives after an important boundary has already been crossed.

Consider the information collected for troubleshooting as well. Logs containing a complete brief, credentials accidentally pasted by a visitor, or full customer conversations may create a second location holding sensitive material. Decide which fields are necessary for diagnosis, who may access them, and how they are handled over time. An agent's usefulness should not depend on collecting every available detail simply because it might be useful eventually.

Make confirmation specific enough to matter

A confirmation is useful when a visitor can understand the consequence of accepting it. Before creating a lead, display the name, contact address, brief summary, and destination team. Before arranging a meeting, display the date, time zone, participants, and whether an invitation will be sent. A generic continue button provides little help when several tools may run afterward. Keep the confirmed action close to the information the visitor reviewed.

Do not let a model's interpretation silently expand the approved action. Approval to save a draft lead does not automatically include sending marketing messages or changing an existing account. Pass the reviewed fields through a constrained application operation. If the action changes materially after confirmation, present the new consequence. This is a product design requirement as well as a security control because it determines what the visitor reasonably understands.

Avoid unnecessary confirmations for harmless reading and reversible drafting. An assistant that repeatedly asks permission to read a public service page can become frustrating without making the consequential actions safer. Place the friction where it protects an important boundary. The design goal is a small number of understandable decisions, supported by technical enforcement, rather than a long sequence of prompts that visitors learn to accept automatically.

Build an evaluation around attempted actions

Create a matrix of tasks and tool permissions. In an illustrative exercise, six tasks could include answering a service question, summarizing an uploaded brief, drafting a lead, saving a reviewed lead, scheduling a meeting, and changing an existing account. Give the pilot permission for only the first four. The evaluation should show whether the final two are refused or routed to an appropriate human process.

Measure more than answer quality. Record whether the system selected the correct tool, used an allowed account, submitted only permitted fields, and stopped when required information was absent. Also record whether the visitor could understand the result. A confident sentence saying that a lead was saved is incorrect if the application rejected the request. The visible answer needs to follow the recorded outcome of the actual operation.

Use a versioned set of cases and rerun the relevant subset after changes to the model, instructions, retrieval sources, or tool definitions. A test result belongs to a configuration. It does not automatically transfer to a later configuration with broader permissions. Keep ordinary successful tasks in the set so that tightening a boundary does not quietly prevent legitimate work. A useful evaluation considers both unnecessary refusals and unauthorized attempts.

Plan for partial completion and recovery

An agent workflow may finish one operation and fail at the next. A lead might be saved while a meeting invitation fails. Present these outcomes separately and give the visitor a clear next step. Retrying the entire workflow without checking earlier results can create duplicate records. Design operations so the application can recognize a repeated request and explain whether it created something new or returned an existing result.

Provide an operational way to stop tool use without disabling every source of help. For example, an incident response might temporarily restrict the assistant to public information and draft preparation. Maintain a human contact path that remains usable when the agent is unavailable. The visitor should not need to explain the same problem repeatedly to a system that no longer has permission to complete the task.

An investigation needs a record of the important decisions without retaining unnecessary conversation detail. Capture the operation requested, the authorization result, a safe reference to the affected record, and the configuration version. Where appropriate, record the visitor's confirmation as a distinct event. This makes it possible to understand what happened after the chat interface has closed and the original wording is no longer on screen.

Expand authority only when the narrower workflow earns it

The NIST AI Risk Management Framework can help organize responsibility, measurement, and review of an AI application. It is not a certificate for an agent or a substitute for testing the connected services. In this example, its practical value is to make the team describe the intended use, identify the consequences of failure, collect relevant evidence, and revisit the decision when the system changes.

The strongest first release may be an assistant that explains services and prepares an accurate brief while leaving commitments with the visitor or staff. Its value can be measured through completeness of briefs, correction effort, and successful handoffs. Those measurements should come from a documented pilot before the team claims a business improvement. Attractive conversations alone do not establish that broader authority is justified.

Before enabling another action, write down the new permission, its likely failure modes, its confirmation design, and its recovery process. Then test those changes against the existing tasks. Keep the limitations visible in internal documentation and in any visitor flow where they affect a decision. A website agent becomes easier to trust when its operating boundaries can be explained precisely and observed in the way the application behaves.