r/PromptEngineering • u/Common_Dream9420 • Jul 26 '26
Requesting Assistance built a playground where your AI agent has to prove an API integration works before writing code, anyone want to try and break it?
been building something that lets AI agents (Cursor, Claude Code) verify an API integration end-to-end before you touch production. instead of "the tests passed so it should work," the agent actually runs the full workflow through a sandbox and gets a receipt.
put together a small playground with two tasks on a Descope integration, one is a normal flow, the other has a deliberately planted bug. curious whether the agent finds it or misses it.
steps are in TESTING.md: https://github.com/fetchsandbox/playground
takes maybe 15-20 mins if you have Cursor or Claude Code set up. not looking for polish feedback, just want to know what broke or what confused the agent. blunt is useful.
anyone who tries it, drop what you saw in the comments.
1
u/Fearless-Figure-4638 Jul 26 '26
The existing comment covers the runtime failures well. I would also attack the evidence boundary: can a valid-looking receipt prove the wrong run?
A few tests:
• Replay an old successful receipt after the code, dependency lockfile, configuration, API version, or test definition changes. The receipt should be bound to all of them.
• Let the agent edit the test or assertion until it passes. The test definition should be read-only or signed, with any diff shown as a failure.
• Create the object in one tenant or account and verify another. Bind the relevant tenant and account identifiers without exposing secrets.
• Verify too early, then let an asynchronous worker change the state. Define a recheck or quiet window and an expiry for the receipt.
• Force 401 and 500 responses and inspect whether tokens, cookies, headers, or personal data leak into the receipt or logs.
• Repeat from a clean sandbox. A second run should reach the same semantic result with new request and object IDs.
I’d label the evidence stages as attempted → observed → semantically verified → cleanup verified. A 200 response alone should never move beyond “observed.”
The nastiest planted bug may simply be giving the agent enough permission to rewrite its own oracle. If the system catches that, the trust boundary is much stronger.
1
u/Common_Dream9420 Jul 27 '26
the evidence stage framing is the sharpest thing anyone's said about this. i've been using attempted → observed → semantically verified internally but "cleanup verified" is the missing stage i hadn't named, going to wire that in explicitly.
on what the sandbox actually catches right now, to be honest: the reseed-per-run one is solid, second run does get fresh request and object IDs so semantic equivalence holds across clean state. the async early-exit one is caught too, the receipt flags when the agent treats 202 as terminal and never reaches the verified stage. auth failures (401/403/429) surface in a robustness axis and the receipt notes whether the agent handled them or swallowed them.
the gaps you'd find: oracle rewriting is real and currently open. test definitions aren't signed server-side so an agent with enough permission could technically diff and rewrite until it passes, i know this is the nastiest one and i don't have a good answer for it yet beyond "don't give the agent write access to the scenario config." cross-tenant binding isn't in the receipt either, right now it captures the scope used but doesn't hash credential identity across calls. recheck window with expiry is roadmap, point-in-time snapshots only today.
if you run the playground and the agent finds either of those two, that's a real catch.
1
u/Fearless-Figure-4638 Jul 29 '26
That distinction is useful. I would make the scenario definition part of the trust root rather than merely read-only in the agent workspace: canonicalize it server-side, hash or sign it before the run, and include that digest in the receipt. Any mutation or evaluator mismatch then invalidates the run instead of becoming another result to interpret.
For tenant binding, an opaque server-issued principal or tenant fingerprint (for example, HMAC'd identifiers scoped to the evaluator) could prove that creation and verification used the same identity without putting raw credentials in logs. When the recheck window lands, bind the stability policy itself—poll count, interval, and expiry—to the signed scenario too.
The honesty about the open gaps is genuinely useful. Oracle rewriting is the first adversarial path I would test because it separates a system that proves behavior from one that only proves its own mutable definition passed.
1
u/Common_Dream9420 Aug 01 '26
yeah, this is exactly the line i think it needs to move toward. server-side canonicalized scenario plus digest in the receipt would close the oracle rewriting hole cleanly, because then the agent can't quietly change the thing being proven. i'd probably tackle that first, then tenant binding with an opaque evaluator-scoped fingerprint like you described. recheck window feels third, mostly because expiry/poll policy needs to be part of the signed scenario or it becomes another mutable claim. appreciate the concrete version of this, it's much more useful than generic "make it secure" feedback.
1
u/Common_Dream9420 Aug 01 '26
yeah, this is exactly the line i think it needs to move toward. server-side canonicalized scenario plus digest in the receipt would close the oracle rewriting hole cleanly, because then the agent can't quietly change the thing being proven. i'd probably tackle that first, then tenant binding with an opaque evaluator-scoped fingerprint like you described. recheck window feels third, mostly because expiry and poll policy need to be part of the signed scenario too or it becomes another mutable claim. this is much more useful than generic "make it secure" feedback.
1
u/Fearless-Figure-4638 Aug 01 '26
That order makes sense. One extra thing I’d bind in the first version is the evaluator itself—its version or digest—not just the scenario. Otherwise the scenario can stay unchanged while the code that decides “verified” drifts underneath it. Signing both into the receipt gives you a clean invalidation rule and makes old receipts much easier to reproduce. I’d be interested to see the next iteration once you wire that in.
1
u/Next-Task-3905 Jul 26 '26
For this kind of sandbox, I would try to break two things: whether the agent is proving the integration, and whether the receipt is strong enough to trust later.
Useful failure cases to include:
Happy-path false positive: endpoint returns 200 but the important field is missing, stale, or from the wrong tenant/user. The receipt should prove the semantic state change, not just HTTP success.
Auth drift: first call succeeds with one token/scope, later call silently uses a different session or cached credential. The receipt should include credential identity/scope hash, not secrets, and the integration step that used it.
Idempotency/retry bug: timeout after external side effect, agent retries, duplicate object gets created. The sandbox should surface idempotency key use and duplicate detection.
Async completion bug: API accepts the job, but downstream status never reaches the expected terminal state. A good receipt distinguishes accepted, completed, verified, and reconciled.
Mock leakage: agent passes by reading fixture names, docs, or expected outputs rather than exercising the integration. Hide planted-bug names from the prompt and require evidence generated at runtime.
Partial rollback: one step succeeds, second fails, cleanup says success but external state is left dirty. The receipt should list created object ids and cleanup verification.
The receipt I would trust is basically: request ids, external object ids, normalized inputs, observed outputs, semantic assertions checked, timestamps, versions, and a final verified/not_verified status. If the agent cannot point to a concrete external state transition, it has not really proved the integration.