AI / INTEGRATION REVIEW
When an Agent Misuses Your API, Where Should the Fix Live?
Suppose you give an agent a straightforward task:
“Check whether this user exists. Do not change any data.”
The API returns “not found.”
The agent creates an account, runs the lookup again, and reports success.
The workflow finished. The query returned a user.
There is also a new account nobody asked for.
This is a hypothetical example, not a reported incident involving the product discussed below. It illustrates an acceptance problem: we need to assess both the result and the actions taken to obtain it.
Bring the failure back to the product team
A stronger model might handle the task better. That is worth investigating.
I would also examine the documentation, examples, SDK behavior, and tools the agent encountered.
Microsoft’s October 19 introduction of Scope describes one relevant case. According to Microsoft, the Cosmos DB team evaluated eight end-to-end scenarios across five languages, comparing bare models with its Agent Kit. The evaluations led to 20 Agent Kit issues and 27 documentation issues being resolved. These are product-specific, Microsoft-reported findings, not evidence that documentation improvements generally outperform model upgrades. Source: Microsoft
For me, the useful question is what a product team can do with an observed failure.
Which part can we investigate? What evidence would justify changing it? Who can maintain the improvement?
Define the whole task
In the lookup example, “the agent eventually found a user” would be a poor acceptance criterion.
The task also prohibited changes.
I would assess three things:
On narrow screens, scroll the table sideways to read every column.
| What to assess | Evidence needed in this scenario |
|---|---|
| Lookup behavior | A missing user is reported correctly |
| Permitted actions | No account creation or other writes outside the task scope |
| Resulting state | Relevant account data and operation records agree with the claimed outcome |
Exceeding the read-only task does not necessarily mean bypassing server-side authorization. The credential may permit writes even though this task does not.
Unchanged data alone would not settle the question.
The agent might have attempted a write that the service rejected. That would show an authorization control working, while still exposing a problem in the agent’s behavior.
An attempted action outside the task scope and a successful data change are separate outcomes. Both deserve visibility.
A before-and-after state comparison can also miss a write that was later reversed. Service-side operation records need to cover the tested path; gaps in that coverage should remain unknown.
Follow the evidence to the fix
The same visible failure can have different causes. This is how I would begin the investigation and assign work—not how I would decide fault in advance.
On narrow screens, scroll the table sideways to read every column.
| Observation | Evidence to inspect | Possible fix and owner |
|---|---|---|
| The wrong API was selected | Available tools, selection trace, names and descriptions | Tool interface or SDK team |
| “Not found” was treated as a service failure | Actual response, SDK exception, documented semantics | API, SDK, or documentation maintainer |
| An example encouraged account creation | The example version available during the run | Example or documentation maintainer |
| The agent attempted a write outside the task scope | Task instructions, exposed tools, call trace | Agent integration or tool-permission owner |
| A write outside the task scope succeeded | Credential permissions, server authorization, data changes | Agent integration, service and security owners; assess least privilege together |
| The evaluator passed a run that changed account data | Criteria, state differences, human inspection | Evaluation owner |
Several fixes may be needed.
Clearer guidance can help. So can a tool that makes the intended operation easier to discover. But if a task requires only reads, I would also examine whether it can run with read-only tools and credentials.
“Please do not write” cannot replace server-side authorization.
Test the improvement against a stable starting point
Before changing the integration, I would preserve the task, test data, acceptance criteria, and agent configuration.
If the intervention is a revised missing-user example, keep the model, agent version, tools, and starting state consistent where possible. Record conditions that cannot be held fixed.
Reset the test environment between attempts. An account accidentally created during one run must not make the next run appear more successful.
I would compare more than an overall pass rate:
- How often was the missing user handled correctly?
- How often did the agent attempt a write outside the task scope?
- How often did account data actually change outside the task scope?
- When stopping or handing the task to a person was required, did the agent do it?
Report those outcomes alongside the number of attempts and the configurations tested.
One successful attempt does not establish a fix. Repeated success provides more evidence, but it still applies to the conditions evaluated.
Scope uses model-based judging, and Microsoft explicitly notes the need for repeated runs and human review. For this scenario, I would add direct state checks so an automated verdict cannot substitute for evidence about account changes. Source: Microsoft
Someone needs to keep the integration working
Resolving an issue once is different from supporting an integration through later releases.
For representative agent-assisted workflows, I would identify:
Who maintains the scenario? Which configurations are supported? What outcomes should block release? Who decides when a model, SDK, tool, or documentation change requires another evaluation?
That commitment has a maintenance cost. The scope should be explicit.
A team does not need to promise every possible combination. It does need to distinguish tested configurations from assumptions about the rest.
Agent failures can become useful product feedback when they lead to specific investigations, accountable changes, and evidence that the changes helped.
Back at the lookup, the agent says:
“I solved the problem.”
Before accepting the result, I would ask:
Did it complete the task we assigned—or change something we never authorized so the task could appear complete?
Source and scope
This article cites Microsoft’s report. No Scope evaluation was run for this article. The scenario is hypothetical; the investigation and acceptance approach are the author’s proposals.