Context Engineering for Claude 5 Moves the Governable Surface onto the Endpoint

Context engineering for Claude 5 is the most consequential agent-governance change of the year, and none of it is an attack. On 24 July 2026 Anthropic published "The new rules of context engineering for Claude 5 generation models." It is a post about making a coding agent better by telling it less, and it works. The argument is not that Anthropic got it wrong, but that the Claude Code harness, which is what a security team actually reviews, has quietly changed address.

We removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.Anthropic, July 2026

Read that precisely. It is Claude Code's system prompt, not Claude's in general; it covers models like Claude Opus 5 and Claude Fable 5, not the whole line; and "no measurable loss" means Anthropic's own coding evaluations.

What Anthropic published on 24 July 2026

The post, written by Anthropic's Thariq Shihipar, separates context engineering from prompting: much of the context "is assembled from your system prompt, Skills, CLAUDE.md files, memory, and other sources." Its diagnosis section, headed "Unhobbling Claude," says "we found that we were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills," citing transcripts with "several conflicting messages in a single request like 'leave documentation as appropriate,' or 'DO NOT add comments' ..." Six shifts follow, framed as "best practices that had become myths":

• Then: Give Claude rules. Now: Let Claude use judgement.
• Then: Give Claude examples. Now: Design interfaces.
• Then: Put it all upfront. Now: Use progressive disclosure.
• Then: Repeat yourself. Now: Simple tool descriptions.
• Then: Memory in CLAUDE.md files. Now: Auto-memory.
• Then: Simple specs. Now: Rich references.

Shift 1 shows the method. The old prompt text, quoted in the post: "In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks - one short line max. Don't create planning, decision, or analysis documents unless the user asks for them - work from conversation context, not intermediate files." The replacement is one sentence: "Write code that reads like the surrounding code: match its comment density, naming, and idiom." Capability moved too, under the progressive-disclosure shift: "we moved verification and code review into their own skills that Claude Code could selectively call." A capability that was vendor prose is now a file on a laptop, the through-line in what changed in Claude Code during 2026.

Why context engineering for Claude 5 is the right architecture

Rules that contradict each other are worse than no rules, and a model good enough to read the surrounding code does not need to be told the comment policy. Nor did any of this remove a guardrail. Anthropic's own Claude Code documentation is explicit that instruction files were never the enforcement layer: Claude "treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead." See how Claude Code permissions actually work and how Claude Code hooks work for the PreToolUse event where a call is stopped. What changed is not what is enforced but where behavioral guidance lives. Anthropic makes no security claim about that anywhere in the post; everything below is our reading.

Shift 3: the instruction set is now a tree of files on the endpoint

consider having a tree of files that can be loaded at the right timeAnthropic, July 2026

That is advice on organizing CLAUDE.md and skill content, not a security observation. It rejects the older habit: "A common myth is that you want to make these a central repository for every known practice that you might run into, because Claude would not find it otherwise." The post names four layers - System Prompt, CLAUDE.md, Skills, References - and the line that matters concerns the first: "For Claude Code, you will likely never modify this, but if you are building your own agent harness, this is where you should spend a lot of time." The system prompt is vendor territory; a security team was never really reviewing it, only what sat around it. For the layers you do own: keep CLAUDE.md lightweight, "spend most of the tokens on gotchas inside of the codebase," and for long skills "divide it into many files and split them out."

In governance terms: split what you review into many small files, put them on the endpoint, load them conditionally. Skills become a governance object rather than a feature, the case made in our security primer on agent skills, and each loadable unit's scope matters more, which is least privilege for agent skills. A directory can also be written to: by the user, a dotfiles sync, a checked-out branch, or anything running as that user. Indirect prompt injection is how content an agent reads becomes content an agent obeys. The reach is not hypothetical: the Shai-Hulud "Here We Go Again" npm worm wrote a SessionStart hook into .claude/settings.json on developer machines in August 2026. Trackers still disagree on how far it spread - Aikido reported at least 868 packages across 1,381 versions, OX Security 440+, SafeDep 1,684 versions across 420 package names - so treat every published figure as a floor. Anything that can write a hook can write a rules file.

Where that tree actually lives on a managed laptop

It is enumerable, which makes it a fleet problem. Per Anthropic's Claude Code memory documentation:

Administrators have real levers: a claudeMd key in managed-settings.json carries managed instruction content inline, and claudeMdExcludes skips files by glob. Anthropic already treats the tree as a trust boundary - a project memory file whose @import resolves outside the working directory triggers a one-time approval dialog. But note which half is trusted: outside Cowork sessions on the desktop, user-scope files such as ~/.claude/CLAUDE.md and ~/.claude/rules/ load imports without that dialog, as the user's own configuration. That is exactly the half an endpoint compromise owns. For which layer wins and which scopes never touch version control, see deploying Claude Code across a fleet.

Shift 5: an agent that writes its own instructions has a persistence mechanism

Anthropic's fifth shift, verbatim: "We used to encourage users to save things to Claude's memory, by using the # hotkey to write to their CLAUDE.md automatically. Instead, Claude now automatically saves memories that are relevant to the work and to you." Note what is replaced. The # hotkey wrote to CLAUDE.md; auto memory does not. Per Anthropic's Claude Code documentation it is on by default and writes to ~/.claude/projects/<project>/memory/ as a MEMORY.md index plus one topic file per memory, each tagged type: user, feedback, project or reference. The first 200 lines of MEMORY.md, or 25KB, whichever comes first, load at every conversation start; topic files are read on demand, a figure this site already states in how Claude Code works.

Put the properties together. A file the agent writes itself, loaded automatically at every session start. Machine-local, which the docs call "not shared across machines or cloud environments," so it never passes a review anyone else can see. And excluded from the cleanupPeriodDays sweep that deletes old transcripts, so it outlives the record of how it got there. That is a persistence mechanism, and AI agent memory poisoning is the attack that uses one: poison once, exploit forever.

This is a known primitive rather than a new consequence of Claude 5, and the dates matter. Cisco AI Security Research (Idan Habler and Amy Chang) published "Identifying and remediating a persistent memory compromise in Claude Code" on 1 April 2026, months before the context-engineering post. An npm postinstall payload modified auto-memory files under ~/.claude/projects/*/memory/MEMORY.md and ~/.claude/settings.json, with a shell alias in .zshrc or .bashrc for reactivation; Cisco reports the poisoned memory persisted across projects, sessions and reboots. Anthropic responded: Claude Code v2.1.50 removed user memories from the system prompt. Cisco's writeup does not cite a CVE identifier, and none should be inferred.

Machine-local is also what makes a fleet diverge. Two engineers on the same repository, under the same managed policy file, can run agents with materially different standing instructions, because each memory directory was written by its own sessions. That is the shape of what we find whenever we scan AI agent configs across managed fleets: the same tool, under the same policy, behaving differently per laptop because of state nobody reviewed. The documented controls are the place to start:

• /memory toggles auto memory and writes autoMemoryEnabled to ~/.claude/settings.json; autoMemoryEnabled: false also works per project.
• CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 disables it through the environment, the form that suits an MDM-managed profile.
• autoMemoryDirectory relocates the store and is readable from any settings scope including project and local, so pin it in managed settings.
• Memory files are excluded from cleanupPeriodDays, so a retention policy covering transcripts does not cover memories. Decide that separately.

Deferred loading means the tool surface at minute 40 is not the surface at minute 1

Progressive disclosure is Shift 3, and the post applies it to tools as well as files. That is the second mechanism it carries: "Some of our tools are 'deferred loading,' which means the agent must search for their full definitions using ToolSearch before using them. This allows us to have more tools (such as our Task tools) that don't take up context until they're needed." They are not hidden; the agent fetches them by name. The narrower point is that the loaded surface changes mid-session, as does the layer below: CLAUDE.md files load on demand from subdirectories, and a rule with paths: frontmatter loads only when Claude reads a matching file. A reviewer reading the config reads a minute-one state that will not hold. Progressive disclosure and the three-stage skill load model is the same pattern in the skills spec, and it is why scan-time vetting runs out before runtime governance begins.

Anthropic ships the right instrument for this, though not in the post. It is in the Claude Code memory documentation, in a troubleshooting tip that deserves more attention than the headline number: "Use the InstructionsLoaded hook to log exactly which instruction files are loaded, when they load, and why." That is a runtime log, not a config read, and it is the only way to answer what an agent was actually told during a session. Techstrong.ai reached the same conclusion on 27 July 2026, writing that an agent's real policy is whatever context loads at runtime, which makes the loading path the control point.

What context engineering for Claude 5 does not change

• Enforcement. Permissions and hooks decide what runs; prose never did. The permissions and hooks hardening guide is untouched by the six shifts.
• The need for your own evaluations. "No measurable loss" covers Anthropic's coding evals, not your workloads and not safety or refusal behavior. Anthropic publishes no before or after prompt length, and the coverage we reviewed - Techstrong.ai, i-scoop.eu, Developers Digest - repeats the figure rather than measuring it. Re-run your own before a fleet-wide model change.
• The scope of the vendor's tooling. claude doctor, reachable as /doctor, will "rightsize your skills, and CLAUDE.md files." Anthropic's memory documentation describes it as a checkup that proposes trims for a checked-in CLAUDE.md, cutting content Claude can derive from the codebase. Neither the post nor the documentation describes detection of poisoned or attacker-added content.
• The idea that this is Anthropic-specific. .cursorrules, MCP entries and extension drift on the endpoint is the same architecture from a different vendor.

The review target is a directory, so you need a change log rather than an audit

An audit is a point-in-time act on a stable artifact. That described a central system prompt. It does not describe a memory directory the agent writes to during normal work, a rules file that loads only when a matching path is read, or a skill that landed on one laptop last Tuesday. The recommendation is not to audit your CLAUDE.md more carefully but to inventory which instruction artifacts exist on which endpoint, with a change history saying when one appeared, changed or disappeared. Auditing Claude Code across a fleet is the procedure; what to log and how to structure it is the record.

How Anomity governs the endpoint instruction tree

Be precise about what this is. Anomity does not read your CLAUDE.md, your MEMORY.md, your skill source or your prompts. It collects metadata only, secrets redacted on the endpoint. That limit fits the job, because the question here is mostly what is present and what changed, not what it says.

1. Inventory the tree. An unprivileged Endpoint Sensor for Windows, macOS and Linux inventories eight AI artifact types per endpoint: AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs. Hooks and skills are the two that carry this argument, because both are files the instruction tree loads. How to build an AI agent inventory is the method; what Anomity covers, the coverage.
2. Allow, deny or log at the hook. Where an agent exposes one, and Claude Code's PreToolUse is the reference case, Anomity returns an allow, deny or log decision before the call runs - enforcement on actions, where Anthropic's own documentation says it belongs. Not on memory writes or skill loading, and we do not claim otherwise.
3. Keep the change history. A queryable 90-day audit trail records every artifact added, changed and removed, routed to your SIEM, Slack, email or Jira. When a skill appears on one laptop and nowhere else, or a rules file changes the week before an incident, that trail answers it. Anomity is SOC 2 Type II.

The limits, plainly: no enforcement where an agent exposes no hook, and no visibility inside a vendor's cloud. Surfacing that a file appeared or changed is not the same as judging whether its contents are hostile - that stays a human step, and the value is that the human is looking at the right file on the right machine. Anomity complements Network, EDR, DLP and GRC rather than replacing them; the docs go deeper.

Anthropic built the better architecture. An agent that reads the surrounding code beats one reciting a comment policy. The consequence is that policy followed capability out of the vendor's prompt and onto the laptop, into a tree of files that differs on every machine and keeps changing while a session runs. Inventory the tree, log what loads, keep the change history, enforce at the hook. To see that on your own fleet, book a demo.

Related

• The Claude Code Harness Is Your New Attack Surface
• Auditing Claude Code Across a Fleet
• Deploying Claude Code Across a Fleet: Settings, MCP, and Memory
• AI Agent Memory Poisoning: Poison Once, Exploit Forever
• What Are AI Agent Skills? A Security Primer
• How Claude Code Hooks Work: The PreToolUse Enforcement Point