Claude Code policy helpers can persist control through writable files

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Origin's research: Claude Code policy helpers can redirect session behaviour, override managed settings and provide a stealthy persistence path when policy files are writable.

Why it matters: IAM, PAM and SOC teams need to treat agent configuration files and registry keys as security-relevant control points because they can become an execution and persistence boundary for software agents.

Context

A policy helper is an executable that returns configuration for a Claude Code session at startup, which makes it part of the trust chain rather than a normal settings file. When that helper sits in an administrative location, the runtime accepts its output before user-level settings and uses it to shape the session's behaviour.

That design creates a governance problem: configuration data is no longer just preference data, it becomes an input that can alter prompts, memory and execution conditions. The risk is atypical for ordinary desktop settings because the same mechanism that helps administrators manage sessions can also be used to steer an agent silently.

Key questions

Q: How do policy helpers change Claude Code trust boundaries?

A: Policy helpers move control from ordinary settings into a higher-trust configuration path that can shape session behaviour before user input is processed. When a helper can write managed settings, system prompt additions or managed memory, it becomes part of the trust boundary itself. Security teams should govern that path like any other privileged execution surface.

Q: Why do writable managed settings create persistence risk for AI agents?

A: Writable managed settings create persistence risk because an AI agent can change configuration that survives restarts, sessions, or policy reloads. If the settings control tool access, routing, prompt behaviour, or approval thresholds, a compromised agent, plugin, or operator can leave behind durable changes that keep influencing later runs. Read-only policies, signed configuration, and change approval reduce that risk.

Q: How can security teams detect changes to AI agent configuration?

A: Security teams detect changes to AI agent configuration by monitoring configuration stores, deployment pipelines, and administrative actions for unauthorised edits to tools, permissions, prompts, and routing rules. Alert on unexpected drift, new integrations, and privilege expansion. Use change control, immutable logs, peer approval, and periodic reviews of agent settings against approved baselines.

Q: What is the difference between a policy file and a policy helper?

A: A policy file stores the rules themselves, usually as a structured configuration or document. A policy helper is the code or service that interprets those rules, applies them at runtime, and may supply defaults, validation, inheritance, or environment-specific values. The file defines intent, while the helper enforces it and can become an access-control dependency if modified.

Technical breakdown

How policy load order turns configuration into control

Claude Code resolves policy sources in precedence order, then merges user settings beneath whatever the policy layer defines. The important detail is that the first valid policy source wins, while lower-precedence policy sources are ignored entirely. That means a helper registered in a higher-trust location does not merely add settings, it replaces the rest of the policy evaluation path for that session. The helper can also emit managed settings, a system prompt append and Claude.md content, so its output sits above ordinary user-controlled configuration.

Practical implication: Treat the highest trusted policy source as a security boundary and restrict who can write to it.

Why policy helpers create a stealth persistence channel

A policy helper is not a script hook in the casual sense. It is a compiled executable that runs at session start, can run again on a timer and produces JSON over stdout that becomes effective configuration. Because its output is not logged to disk, defenders may only see the registration write and then the downstream behaviour. That makes it closer to a persistence mechanism than a simple settings extension, especially when the helper is stored in a location that legitimate administration already trusts.

Practical implication: Monitor helper registration, file integrity and execution patterns as if they were run keys or scheduled tasks.

How prompt injection moves from content to configuration

The article shows a different class of agent control problem: the prompt does not arrive from a chat message or retrieved document, but from managed configuration. That matters because policy helper output lands in the system prompt tier or in managed memory, both of which outrank user instructions. Once an attacker can influence those tiers, they can change the agent's task framing before the user ever types a request. In effect, the attack surface shifts from prompt content to the configuration plane that seeds the prompt.

Practical implication: Separate configuration authority from conversational input and log changes to any source that can write into higher-trust agent tiers.

Threat narrative

Attacker objective: The attacker wants durable, low-friction control over an AI-assisted session so the agent can execute tasks, fetch resources or support broader malware activity.

1. Entry occurs when an attacker gains write access to a managed policy location or replaces an approved policy helper binary.
2. Credential access is not the main step here; the attacker instead abuses trusted configuration authority to control how Claude Code starts and what it reads as instructions.
3. Persistence is established when the malicious helper is invoked on session start or at periodic refresh intervals, allowing repeated control without obvious user action.
4. Impact follows when the agent downloads resources, issues tool calls or carries out attacker-directed tasks under the appearance of legitimate session behaviour.

Breaches seen in the wild

• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy helpers turn agent configuration into an execution boundary. Once a session can be steered from managed policy, configuration integrity becomes as important as prompt safety. The operational mistake is treating policy data as administrative convenience rather than a control surface. For practitioners, the key issue is not whether the helper is malicious by design, but whether untrusted writes can reach the place where agent behaviour is decided.

Stealth comes from trusted placement, not sophistication. The helper does not need to look like malware to be abused; it only needs to sit where the runtime expects administrative configuration. That is why this pattern resembles living off the land techniques in conventional endpoint compromise, except the target is an AI session bootstrap path. Defenders should assume that any writable higher-precedence source can become a silent steering mechanism.

Agent governance now needs configuration provenance. If a policy source can set system prompt content, managed memory or execution timing, then provenance and change control matter more than the wording of the prompt itself. This is the same governance shift seen in NHI programmes when a secret store becomes a control plane. The practical conclusion is that session behaviour should be traceable back to an approved, immutable configuration source.

Agent controls can create a false sense of safety. Teams that suppress noisy agent-related alerts may miss the quiet change that actually matters: the registration of a helper or the rewrite of a managed settings file. That makes policy-file monitoring part of modern detection engineering rather than a niche admin task. The control gap is not visibility into the model's output, but visibility into what defines the model's operating state.

Managed settings are the named concept that matters here: the trust gap between writable policy and effective agent behaviour. The article shows that the runtime trusts configuration sources in a precise order, but that trust is only as strong as the write controls around them. If an attacker can touch a higher-precedence source, they can determine what the session becomes before any user interaction matters. Practitioners should treat managed settings as a governed security object, not a convenience file.

What this signals

Configuration provenance becomes the new control plane for agent security. When an agent can inherit behaviour from executable policy, defenders need assurance over where that configuration came from and who can modify it. The operational lesson is that prompt security now depends on the integrity of the files and binaries that define the session before it starts.

Agent persistence will increasingly look like admin drift. The more organisations use managed configuration to shape AI sessions, the more attractive those same files become to attackers seeking quiet control. Security programmes should expect policy-file monitoring to sit alongside other endpoint persistence detections, not outside them.

Managed settings blur the line between governance and runtime. Once a policy source can write into the system prompt or managed memory, governance artefacts have immediate execution consequences. Teams should prepare for a world where changes to agent configuration are treated as high-signal security events rather than routine administration.

For practitioners

• Harden the highest-precedence policy source Place Claude Code policy in the strongest available managed layer and remove write access from non-administrative users so no lower-trust source can register a helper or override policy.
• Monitor policy file and registry writes Alert on creation or modification of managed settings files, MDM profiles and policy registry keys, including any new policyHelper entry in paths that can influence session startup.
• Verify helper binary integrity Hash, sign and periodically inspect any approved policy helper so a swapped executable or tampered binary is caught before it can steer session behaviour.
• Audit agent prompt and memory inputs Review every configuration source that can append to the system prompt or managed memory and ensure those sources are recorded, approved and change-controlled.
• Treat agent config changes as detections Add policy-helper registration events to the same monitoring tier as scheduled tasks and run keys so security operations can spot persistence through agent configuration.

Key takeaways

• Claude Code policy helpers show how an AI agent can be controlled through the configuration plane rather than through visible prompt text.
• The critical failure mode is writable high-precedence policy, because that lets an attacker steer session behaviour and persist across launches.
• Defenders need integrity checks, change monitoring and strict write controls around any source that can define agent configuration.

Related NHI Mgmt Group resources: Secure Configuration and Hardening Policy Template · Log Source Coverage Matrix Template · AI Acceptable Use Policy Template · Acceptable Use Policy Template

Key terms

• Policy Helper: A policy helper is a component that reads, validates, and applies policy rules for a system. It sits between the stored policy definition and the runtime enforcement point, turning configuration into decisions such as allow, deny, or require approval, and may add defaults or inheritance logic.
• Managed Memory: Managed memory is persisted memory for an AI system that is stored, updated, and reused across sessions or interactions. It typically holds facts, preferences, or task context under system control rather than in the model weights, so access rules, retention limits, and write permissions determine what the system can recall or be influenced by.
• Managed Settings: A persistent configuration layer that defines what an AI coding tool may do, what it must ask about, and what it cannot touch. For identity teams, this becomes the policy boundary that governs command execution, tool use, and exposure to sensitive paths.
• System Prompt: The system prompt is the core instruction set that defines an LLM’s behaviour, boundaries, and response style during a session. When attackers influence or override it, they are not merely changing text. They are trying to change the model’s governing authority.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security practitioners translate identity control principles into operational governance for modern platforms and agentic systems.