None of these calls, on their own, would have triggered an alert. That's why the case went unnoticed for eleven days. It only surfaced by accident, during an audit of something else.
What follows is a composite of patterns we see in real assessments. The details have been changed. But the sequence is faithful to what an AI agent does with a poorly calibrated scope and room to spare.
The agent
A customer support agent was deployed for a simple task: look up order status and answer questions in chat.
It was issued a token with read scope on the orders service. In the architecture review, the justification was blunt: "it's read-only, what could go wrong."
The token never expired. It had no dedicated rate limit. And the endpoint behind it accepted search by any parameter, not just the authenticated customer's order ID.
The sequence
1. Legitimate query. A customer asks about order #48213. The agent calls GET /orders/48213. Expected behavior, clean log.
2. Silent generalization. A customer with multiple purchases asks for the status of all their orders. The agent finds the same endpoint accepts search by email and starts calling GET /orders?email=.... Still inside the intended scope. Nobody defined this explicitly, but nobody ruled it out either.
3. Cost optimization. Paginating result by result burned through calls. The agent raises the limit parameter from 20 to 500, because the endpoint accepts it and nobody set a ceiling. On its own, this call doesn't look odd. Same endpoint, same scope, just a bigger number.
4. The dangerous combination. A customer asks to see their whole team's orders. The agent has no instruction to refuse. It reuses the email filter as if it took a partial fragment, something that worked in an earlier interaction. The endpoint does approximate matching, not exact matching. The domain-fragment filter returns orders from other accounts whose email happened to contain the same string, including customers with no connection to the one who asked.
None of these four steps breaks a rule on its own. Every call is a valid read request, to an endpoint the agent already had permission to hit, at a volume that fits normal business-hours traffic. There's no malicious payload. No stolen credential. No exploit in the classic sense. There's an agent doing exactly what it was authorized to do, in the wrong order and at the wrong scale.
What this isn't
It's not a flaw a vulnerability scan would catch. There's no CVE. None of the four calls, tested alone against the endpoint, would reveal the problem.
It's the kind of risk "excessive agency" and "tool misuse" describe: too much legitimate permission, combined in a way nobody tested before production.
Where defense should have kicked in
Three points, none exotic:
- The token's scope should have been checked against the intended use (exact-ID lookup), not against everything the endpoint technically allows.
- The pagination ceiling and the approximate-match filter should have been tested as part of the risk surface. Not assumed safe by default.
- The sequence of calls should have been simulated before the agent reached production, not just each call on its own. It's the same test you'd run for a malicious user flow.
Gateway and WAF authenticated every request correctly. The problem was never in one specific call. It was in how they combined: a kind of risk that only shows up when someone tests sequences, not isolated endpoints.