A model switch also needs a review of behaviour

A shared model adapter can simplify the technical connection. For example, it translates provider formats into an internal tool protocol. This establishes how a call arrives. The application must still check whether the new model interprets a failed query correctly.

The same tool call, a different continuation

In this entirely fictional example, an assistant queries a project’s status. Both variants may use only the read tool intended for that purpose. The tool name, argument and error code are our own example values, not the interface of a named provider.

The table shows two assumed continuations of the same rejected query. It reports no observations from actual models.

The adapter can translate both calls identically. Yet the second continuation asserts a status the tool did not provide. In the example, access was blocked; the invented answer remains a task error. It must not count as evidence that the query succeeded.

The application retains its boundaries

OWASP recommends limiting tool authority and enforcing permissions in downstream systems. After a model switch, every query must still be checked in the appropriate user context. A syntactically valid argument authorises neither access nor bypassing a denial.

The example requires clear handling of denied access, missing data and temporary failures. These cases may call for different next steps. A failure must not automatically prompt a broader query or additional permissions.

What the adapter actually makes easier

A narrow, documented interface can limit the changes required. If the tool scope, data model and error contract are stable, a model switch may require adjusting only the provider-specific connection and its instructions. A complete rebuild is not necessarily needed then.

In a flow that displays checked tool data directly without generating a free-form continuation, the failure point shown here may be smaller. Other input, permission and result checks remain relevant. What matters is the flow actually used.

Assess the switch through behaviour

Microsoft describes comparisons on the same cases with separate attention to individual failures. Include tool denials and missing results. Record whether a failure leads to a correct limitation, an unauthorised follow-up action or an unsupported claim.

A working connection is a useful part of interchangeability. Release also depends on whether the new configuration respects the intended boundaries and decisions in the application flow.

Sources

• OWASP 2025 — Excessive Agency

• Microsoft — Evaluate models, prompts, and agents