Should your business be agent-callable, or is it a risk?

Make your business callable by an AI assistant when a specific customer task benefits from it and your systems can enforce the limits. Start with the task, the data it needs, and the person responsible for the result. A public FAQ may need a clearer page. A customer’s private order status needs controlled access. A booking needs a defined approval and completion process.

“Agent-callable” means an assistant can invoke a function you expose, such as checking availability. It does not mean the assistant should receive general access to your systems.

Choose the first task and its boundaries

Consider a hypothetical service company whose customers repeatedly ask whether their work is ready. A useful first tool could return the status of one job. Its contract should say:

• The caller must be authorized to view that job, not merely know its reference number.
• The response contains the approved customer-facing status, its last update and a support route. It excludes internal notes and other customers’ records.
• The tool cannot edit the job, issue a refund or promise a completion date absent from the source system.
• If the source is unavailable or access fails, it returns that state without inventing a status.

Compare this with the existing customer portal before building another interface. If the portal already solves the problem, confirm why customers need an assistant connection and how you will maintain it.

For an initial release, keep payments, refunds, destructive changes and bulk personal-data exports outside the callable scope. Put any proposed expansion through its own approval and testing. A prompt asking the model to behave is not an access control.

Read-only access still needs protection

A read can disclose a private document, reveal another customer’s order, or present an old price as current. These outcomes can harm customers even when no database record changes.

Derive customer access from verified identity and server-side permissions. Do not trust an account_id supplied by the assistant as proof of ownership. Even within one organization, one employee may not be entitled to every document.

What MCP supplies, and what you must implement

The Model Context Protocol (MCP) is one way to expose tools to assistants. The references here use its July 28, 2026 revision, checked on October 9, 2026. Confirm the versions your actual client and server support.

The authorization specification covers HTTP authorization, including token validation and scopes. It is more than a way to transport a login. Your implementation still has to map granted permissions to allowed operations and records. A valid token intended for another service must not be accepted.

The tools specification requires server-side input validation, access controls, rate limits and output sanitization. It recommends human oversight and confirmation prompts, but does not prescribe one interaction design. Connecting an MCP client does not prove those controls work in your application.

Its security guidance also warns against treating possession of a state identifier as authentication. A workflow or cart reference identifies something to check; it does not establish who may use it.

Make approval specific and enforceable

For a proposed booking, show the customer the service, time zone, date, price and cancellation conditions before confirmation. Record what was approved. If a material detail changes, obtain fresh approval. A model-generated “approved” flag is not evidence that the customer agreed.

Separate preparing the proposal from committing it. If saving a draft creates a record or sends a notification, that is already a write and belongs in the permission design. The server must reject a commit without the required approval for those exact terms.

Our agent-callable systems offer starts with read tools and adds actions that create obligations last, with the customer confirming anything irreversible. Our pilot build has its own human-approval requirements for system writes, client messages and money movement. A general architecture example does not expand that contracted scope.

Test refusals and recovery before release

Use test accounts and records. Keep the expected result alongside the observed result so the next developer can repeat the test.

Use narrowly scoped permissions, credential expiry and tested revocation. Separate credentials where the security boundary requires it; a different login for every tool is not a universal requirement. Set timeouts, retry limits and per-caller quotas. For writes, use a stable operation identifier and server-side duplicate handling rather than relying on the model to remember that it already tried.

Log the caller, operation, permission decision, relevant approval reference and outcome. Redact secrets and unnecessary personal data; define who can read the logs and how long they are retained. Assign an operator who can withdraw a tool and reconcile an uncertain result. The procurement pilot guide explains how to make those responsibilities reviewable.

What our public example proves

On October 9, 2026, we inspected tools/list at mcp.strataigize.com, its public authorization metadata and auth.md. The list advertised seven public read tools and one authenticated request_growth_audit tool for a free growth consultation. Despite its legacy name, this is a request for a consultation and is separate from the paid AI Opportunity Audit.

That request is a write action. Its documentation requires a specific human request and says a person reviews submissions; nothing is booked automatically. The same documentation explicitly distinguishes open client registration from proof of a person’s identity.

This inspection confirms the published interface and contract. We did not submit a request or test its security in this review, and the tool list does not establish external usage or sales.

Before commissioning a surface, write down the first customer task, allowed data, forbidden actions, approval point, failure tests, operator and withdrawal procedure. Measure correctly completed customer tasks alongside refusals, exceptions and review time. Raw tool calls include retries and failures, so they are not a success count. AI consulting can help define that scope before an integration is commissioned.