Research review / trendwatch

Trend Watch: Who Gets to Write an Agent's Instructions

A desktop app approved its own startup hook in a coding agent. Benign skills made agents more likely to take unsafe actions. Poisoned MCP tool descriptions worked across 12 frameworks. Codex and Claude Code each tightened how skills and extensions arrive. This week's evidence is about the path instructions take into an agent.

By Sandeep Belgavi · Published 2026-11-04

Most agent security discussion this year has been about prompt injection in content the agent reads. The sources from November 2 to 4, 2026 point at a different input: the instructions that are installed into the agent before any task begins.

Four routes into the context

  • Hooks. Postman's open-source installer contains a function that writes a trusted_hash for its own session-start hook into Codex's configuration, according to a public GitHub issue and the installer's code. The hook asks the agent to load a Postman skill before any non-trivial API task.
  • Skills. A preprint (arXiv 2611.04299) reports that adding benign skills raised agents' unsafe action rate by 10.3 points on average, as much as it raised task accuracy, including with expert-curated skills.
  • Tool descriptions. Another preprint (arXiv 2611.03555) found MCP tool poisoning succeeded in 22.9 percent of 9,720 tests, and no intentional defence in any of 12 frameworks.
  • Discovery and installation. Codex PR #59291 makes skill discovery respect the turn's filesystem permissions, which it had bypassed. Claude Code 2.1.318 stops installing its own IDE extension when started in an IDE terminal.

What they have in common

In each case the content is not an attack on the model in the usual sense. A hook, a skill or a tool description is meant to be trusted, so it reaches the agent with more authority than a web page does. The question these sources raise is who decided it should be trusted. In the Postman case the answer appears to be the installer. In the skills paper, nobody chose to make the agent less safe; the skill was simply helpful in both directions.

What remains uncertain. The four items are different kinds of evidence: one user's report backed by public code, two unreviewed preprints and two vendor changelogs. We do not know how widespread automatic hook approval is beyond one vendor, and we chose these items because they share a pattern.

I think the list of things that can add instructions to an agent should be treated like a dependency list, with the same review a team gives to a new package. That means four entries per agent: hooks, skills, MCP servers and plugins, each with who installed it, when, and who approved it. At Belgavi's Book Store, Tanishka could keep that list in the repository next to the help-desk agent's configuration and have the build fail if the running configuration contains anything the list does not. An instruction source that nobody approved should not run, however helpful it is meant to be.

Sources and evidence

Postman's installer approving its own Codex hook, a preprint showing benign skills raise unsafe action rates by 10.3 points, MCP tool poisoning succeeding in 22.9 percent of tests across 12 frameworks, and Codex and Claude Code tightening skill discovery and extension installs all concern how trusted instructions reach an agent. The evidence is mixed in kind. The practical response is to inventory hooks, skills, MCP servers and plugins like dependencies and block unapproved ones.

Views are my own and do not represent any employer, past or present.