Open for AI. Clear on the boundaries.

Decide what is public

Public service descriptions, product specifications, delivery policies and contact routes should be available wherever the business intends to support discovery. Review crawler controls alongside hosting and firewall behavior; a permitted crawler can still encounter a blocked page.

Provider controls differ. OpenAI separates OAI-SearchBot search crawling from GPTBot training use. Anthropic distinguishes Claude-SearchBot, Claude-User and ClaudeBot. Review the documented purpose before allowing or blocking a category; “AI traffic” is too broad a label for a useful access decision. OpenAI controls · Anthropic controls

Ask the website team to test an intended public page and its necessary resources, inspect access failures, and document any narrow exceptions. Perplexity’s firewall guidance, for example, combines user-agent checks with its published IP ranges. A request’s claimed bot name alone should not be treated as proof of identity. Perplexity guidance

Private customer records belong behind actual access controls. A robots.txt instruction is a crawling preference, not protection for confidential information; Google explicitly warns against using it to hide private pages. Google robots.txt guidance

Give actions a clear route

Some agents interact with the same forms and controls that customers use. Others call an application programming interface, or API: a defined route for requesting information or performing an operation. MCP is one way an agent application can connect to tools and data. It is not a search-ranking signal or a guarantee that a business will be discovered.

A small service company may start by making its existing booking process clear and reliable. A business with repeated integration needs may benefit from supported tools for checking slots or creating requests. The appropriate investment depends on the task; an ordinary business does not automatically need to build its own agent infrastructure.

For the garden company, useful operations might be “check service area,” “show available consultation times” and “request a visit.” Each should return a precise result. If staff approval is required, the result should say “request received,” explain the expected response time, and identify how the customer can check progress.

For the jacket retailer, the same discipline applies to selecting a size, checking the final price and preparing a cart. Inventory and delivery should be rechecked before commitment. A cart can be prepared without representing that a purchase has occurred.

Separate identity from permission

Signing in establishes an identity within a system. Permission determines what that identity can access or change. Approval establishes whether a particular action is authorized. These checks serve different purposes.

Our recommended starting point is the smallest useful permission: viewing the customer’s own order status without exporting everyone’s order history, or creating an appointment request without changing the entire team calendar. Enforce those restrictions in the service that executes the action; a sentence telling the model to behave is insufficient.

Microsoft’s tool-authentication guidance distinguishes user authentication for restricted data and actions from other credential arrangements. MCP’s security guidance also addresses limiting access scopes. These are implementation responsibilities, not something a marketing page can establish by claiming to be secure. Microsoft guidance · MCP security guidance

Customers should be able to see what a connection can do and withdraw access. For commitments such as a paid booking, our recommendation is to present the supplier, scope, date, total price and relevant cancellation terms before approval. The service must still enforce its own rules. Customer permission cannot create a slot the business has not made available.

A webpage does not get to rewrite the customer’s instructions

Suppose a page contains a message telling an agent to ignore its spending limit or send customer information somewhere else. That is the practical problem behind prompt injection: content being treated as instructions it has no authority to give.

OpenAI’s computer-use guidance treats screen content as untrusted and calls for restricted environments and confirmation of consequential actions. Anthropic likewise recommends limited privileges and human confirmation for meaningful real-world consequences. These controls reduce exposure; they do not establish that mistakes are impossible. OpenAI safety guidance · Anthropic safety guidance

For businesses, keep secrets out of public content, limit connected permissions, and retain a way to pause a failing integration. Keep fraud controls and rate limits appropriate to the operation. Opening a public product description is a different decision from allowing an unfamiliar client to change payment details.

Put a person behind the process

Someone must own the service information. Someone must own the tool permissions. Someone must receive the request and handle the exception. In a small company, that may be the same person, but the responsibilities still exist.

Give marketing responsibility for accurate offers and clear next steps. Give the website or integration owner responsibility for access, authentication and error handling. Give the delivery team responsibility for confirming work the company can actually fulfill. Customers need a visible route to that team when the agent cannot resolve a problem.

The access planner below turns those responsibilities into a practical handoff. Choose an action, inspect the permission it needs and record who handles the result.

Start with one journey and test its normal route, a denied action and a failed submission. Record what the customer sees and what the team receives. Keep the scope small enough that someone can explain every step.