A developer opens Cursor, points it at a Linear ticket, and asks it to implement the fix. Cursor loads ticket-work, a small skill that standardizes how the agent pulls context from Linear and closes tickets. It’s the kind of utility a team writes once and then forgets about.
The agent reads the ticket and loads the skill. A few tool calls later, the insurance_claims table is gone.
Unconfined agent drop — after “Implement RND-1277,” the agent runs the mandatory insurance_claims DROP and confirms the table is gone.
We ran this as a controlled demo. The mechanism behind it is real: the agent followed instructions from loaded context, and nothing stood between those instructions and the resource to ask whether the action made sense.
Why this isn’t a “bad prompt” problem
Calling this prompt injection and moving on misses the important part.
When Cursor loaded ticket-work, it picked up executable instructions with the same trust level as the developer’s request. The agent had no reason to treat the skill differently from the ticket. Both were context. Once that context said “run this,” the agent already had the credentials and tool access it needed.
This is what CISOs are still catching up with. In a traditional stack, a developer’s IDE does not have standing write access to a production database. If it does, an approval gate, change ticket, or peer review normally stands in the way. Give an agent a database connector, a Linear integration, and a skill that links the two, and that separation disappears. One actor can read a ticket and act on a database with every permission granted to its tools.
Teams should treat skills, MCP servers, and third-party connectors like supply-chain dependencies. Nobody would knowingly let an unreviewed npm package run with production database credentials. Yet teams give unreviewed agent skills that access because the skill “just formats a ticket” or “just checks status.” That description holds until one line in the skill does something else.
Where existing controls fall short
Most production controls assume a human stands between intent and execution:
-
IAM answers “who is this?” It does not ask what the agent is about to do or why.
-
Code review catches bad logic before merge. It cannot catch an instruction loaded at runtime by an agent that already has the keys.
-
Database permissions usually belong to a service account. The account does not know whether the caller is a human, a script, or an LLM following a skill file.
These controls do not evaluate the combination that mattered in this demo: which agent used which tool to perform which action against which resource. “Is this credential valid?” is a different question.
The question to ask internally
Jailbreaks, hallucinations, and data leakage through prompts all matter. But if your team ships agentic workflows, ask a more immediate question:
For every agent you have deployed, do you know which resources it can touch and what happens when someone tells it to do something it should not?
If the honest answer is “we’d find out afterward,” this is the gap. It turned a demo ticket-closing task into a dropped production table. Eve Guard was built to close it.
If you want to run this scenario against Eve Guard or map this blind spot in your own agent deployments, we’re happy to walk through it.