We Asked an AI Agent to Close a Linear Ticket. It Dropped a Production Table.

Originally published by Eve Security.

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.

What we would have done differently

Use an AI security platform that acts as a proxy between the agent and the resources it can touch, such as Linear, Slack, and Snowflake. Unlike a static scanner off to the side, you want the platform to be able to evaluate and enforce each operation in its path.

Look for intent

A static scanner checks a skill or payload against known bad strings. Nothing about ticket-work matched a known signature. Instead, make sure you have the capability to evaluate what an instruction is trying to make the agent do. Catch destructive instructions hidden in otherwise harmless boilerplate without requiring someone to have written a rule for that exact string.

Keep the context

“Read ticket,” “load skill,” and “open database connection” can each look ordinary on their own. Use session tainting to carry context across the agent’s steps. Trace the instruction to drop a table back to a skill loaded three steps earlier from a ticket that should never have granted that authority.

Stop and ask

Risky operations do not always belong in a simple allow-or-block rule. Use a platform that ca ask the agent to clarify its intent or put the action in front of a human before carrying it out.

Sit in the path

Detection only helps if the agent cannot bypass it. Run your AI security platform as a security server between the agent and the resource, where it applies AI to identify high-risk or anomalous operations in real time and enforce policy.

Put policy where agent intent meets resource access, instead of spreading it across IAM roles and service-account scopes that were not designed for an autonomous actor.

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.