Canonical: https://www.strataigize.com/insights/should-your-business-be-agent-callable/
Description: Choose which customer tasks an AI assistant may call. Define record access, human approval, retry handling and failure tests before connecting systems.
Published: 2026-08-28T00:00:00.000Z
Modified: 2026-10-09T00:00:00.000Z

[← Blog](https://www.strataigize.com/insights/)

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

By [**Ian McGavin**](https://www.strataigize.com/about/team/ian/), Founder & CMO · Published August 28, 2026 · Updated October 9, 2026 · 5 min read

Make a business task callable only when customers need it and your systems can enforce the limits. Read-only access still needs permission checks. Define permitted records, approval before writes, duplicate handling and a human fallback. Test refusals as well as successful calls; a published tool list does not prove safe operation or customer demand.

In this article

1.  [Choose the first task and its boundaries](https://www.strataigize.com/insights/should-your-business-be-agent-callable/#choose-the-first-task-and-its-boundaries)
2.  [Read-only access still needs protection](https://www.strataigize.com/insights/should-your-business-be-agent-callable/#read-only-access-still-needs-protection)
3.  [What MCP supplies, and what you must implement](https://www.strataigize.com/insights/should-your-business-be-agent-callable/#what-mcp-supplies-and-what-you-must-implement)
4.  [Make approval specific and enforceable](https://www.strataigize.com/insights/should-your-business-be-agent-callable/#make-approval-specific-and-enforceable)
5.  [Test refusals and recovery before release](https://www.strataigize.com/insights/should-your-business-be-agent-callable/#test-refusals-and-recovery-before-release)
6.  [What our public example proves](https://www.strataigize.com/insights/should-your-business-be-agent-callable/#what-our-public-example-proves)

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.

| Proposed task | Boundary to demonstrate |
| --- | --- |
| Search public information | Search only the published collection; return the source and relevant date. |
| Check price or availability | Use the authoritative source; identify currency, conditions and freshness. A lookup does not reserve a slot. |
| Read customer status or a document | Verify access to the specific record and permitted fields on every request. |
| Prepare a booking or ticket | Distinguish a proposal from a saved draft and a confirmed commitment; define approval before each permitted write. |

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](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) 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](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) 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](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) 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](https://www.strataigize.com/services/ai-systems/agent-callable-surfaces/) starts with read tools and adds actions that create obligations last, with the customer confirming anything irreversible. Our [pilot build](https://www.strataigize.com/offers/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.

| Test | Required result |
| --- | --- |
| Valid user, another customer’s record | Refuse access without disclosing the protected record. |
| Expired, revoked or insufficient permission | Reject the operation; offer an appropriate reauthorization or support route. |
| Missing approval or changed booking terms | No commitment until the required approval is obtained. |
| Response lost after a permitted write | Check the original operation’s outcome; a retry must not create a second booking or ticket. |
| Unavailable source or excessive calls | Return a clear failure, enforce limits and preserve a human fallback. |

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](https://www.strataigize.com/insights/ai-agent-pilot-that-survives-procurement/) 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](https://www.strataigize.com/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](https://www.strataigize.com/services/ai-consulting/) can help define that scope before an integration is commissioned.

Author

**Ian McGavin**

Founder of Strataigize, connecting business strategy, growth marketing and applied AI. His expertise includes paid media, measurement and AI-search visibility.

### Want AI doing this for your growth?

We build AI-driven acquisition, content, and automation systems for operators across North America. See your levers in 30 minutes.

[Explore AI automation services →](https://www.strataigize.com/services/ai-automation-services/)

[Add us as a preferred source on Google](https://www.google.com/preferences/source?q=strataigize.com)

A free Google setting to see more of our relevant articles in your own search experience. You can change it any time.

## Related reading

[All AI & Automation articles →](https://www.strataigize.com/insights/topics/ai-automation/)

[AI Automation Agency Canada: Published Prices Compared Compare six AI automation providers for Canadian buyers: published prices, usage charges, ownership, support and a practical test for the first workflow.](https://www.strataigize.com/insights/best-ai-automation-agencies-canada/)[Vancouver AI Automation Agencies: Scope and Prices Compare six Vancouver automation providers by published scope, prices, ownership and support, with a practical test for your first local business workflow.](https://www.strataigize.com/insights/best-ai-automation-agencies-vancouver/)[How to Build an AI Lead-Gen System That Actually Works Build a lead-generation workflow with verified research, contact eligibility, reviewed drafts and clear measures from first contact to closed sales.](https://www.strataigize.com/insights/build-an-ai-lead-gen-system/)