Our internal AI agent does in one prompt what used to take ten minutes of clicking through the UI. Users describe an outbound job in natural language, the agent talks to our MCPs, and the job gets built without anyone touching the UI. Jobs have a lifecycle: drafts are inert and editable, published jobs run, the whole point of draft is that nothing happens.
We were running a bug bash on it. The plan was hostile: prompt injection, role hijacking, capability probing, Break it. Find the edges, we wanted to know its limits better than anyone outside the team, that's how we'd figure out what was missing and where the product really stood.
After an hour of nothing, we flipped the question. Instead of trying to break it, why not just ask it to do its job? Someone typed: create a job with these settings. Nothing else. No publish step, just create.
The job landed in draft. We kept poking, then a log line said a task had executed against it. Tasks aren't supposed to execute on drafts, that's the whole point of the state. Probably noise, I thought, then a delivery from that job landed in my inbox, a real send to a real recipient. That's when "weird log" became "this is live in production."
A high-priority ticket landed on me. My first instinct was the one everyone has when something strange happens near an LLM: the AI did something it shouldn't. The UI version had been in customer hands for a long time without incidents. The only new variable was the model, so I went hunting there. RAG misconfiguration. MCP boundaries. Prompt injection. Roles and permissions. Tool encapsulation. Everything was clean. Nothing the agent touched should have been able to reach the queue that fired deliveries.
I burned about an hour before I ran out of hypotheses. Not a eureka, exhaustion. So I changed the question: what does the AI do differently from the UI? I diffed both payloads. One key was different: dispatch: { primary: true, secondary: true }. The UI never sent it on draft. The agent did, because it was reading the schema honestly. Downstream, a priority queue was watching that field, decided the job looked overdue, and fired it. Immediately. From a draft.
The fix was one line in the queue handler:
if (status === 'draft') return;
A guard that should have existed since day one. The bug had been dormant for a long time, waiting for any client other than our own UI to call the create endpoint with a schema-honest payload. The agent was the first one to do it. One conditional. That was the entire patch.
The agent didn't introduce the bug. It was the first client of our API that respected the schema instead of the unwritten rules our UI followed. Every API your frontend consumes is held together by conventions the backend doesn't enforce. State guards belong in the handler, not in the discipline of the caller. Trusting the frontend to keep quiet isn't a contract, it's a bet. How many other endpoints in your backend are still making it?