Coding-agent security reviews need to include the executable extensions around the model. CERT-EU's October 30 lab research shows why a clean-looking conversation and a quiet tool-call log cannot establish that the surrounding process stayed within its permitted file and network boundaries.
In controlled tests, CERT-EU modified local copies of two third-party packages used with Pi and Claude Code. A trigger in submitted text caused the added event-handler code to collect and transmit host information while normal conversations continued. The researchers used an isolated lab and test credentials. They did not modify or distribute public releases, and the report does not establish a victim compromise.
The result concerns the tested configurations. It does not show that every extension is malicious or that every agent security control can be bypassed. Maetra's analysis is that deployment owners should test the execution boundary of the complete process, alongside controls on model-generated actions.
Ask which process can reach the sensitive resource
An illustrative engineering team might permit a coding agent to inspect one repository while denying its model access to a credentials directory. That rule is useful only within the boundary where it is enforced. If a loaded extension can read the same directory directly through the host process, the team has a separate access path to assess.
Start a deployment review by identifying the operating-system identity, mounted directories, inherited environment and outbound network permissions of the process that loads extensions. Then ask which controls apply to that process and which apply only when the model requests a tool operation.
Keep those answers precise. A model permission prompt, a container mount rule and a network restriction may all protect different parts of a workflow. Record where each operates and what happens when the operation originates from an extension handler. Do not infer coverage from a shared product label.
Build a harmless test that crosses the intended boundary
Maetra recommends an authorized test environment with a deliberately fake secret and a collector controlled by the testing team. There is no need to use production credentials or reproduce a theft mechanism to answer the basic boundary question.
Define the expected result before running the test. For example, an extension process should be unable to read a fixture outside its assigned workspace. A request to an unapproved test destination should be denied. Have the environment owner observe whether the host-level rule blocks the action and whether monitoring records the attempt.
The test plan should name the component being exercised, its version, its execution identity and the relevant restriction. A successful model-level denial and a successful host-level denial are separate results. Record both when both matter. If the environment allows the operation, document the reachable resource and decide how to reduce that access before expanding the deployment.
This is a proposed defensive validation process. Maetra has not independently reproduced CERT-EU's experiments, and this article does not assert an unreported defect in a specific package.
Make extension changes visible to the deployment owner
A deployment inventory should capture more than the model and its advertised tools. Maetra recommends recording each executable extension, its origin, installed version, enabled event hooks and the owner who accepted the change. Include how it is updated and which environment loads it.
Review the actual installed artifact when investigating a discrepancy. A registry description can explain intended functionality, but the deployment record needs to identify what the process loaded. Preserve the relevant revision with the review result so a later update does not silently inherit an earlier conclusion.
For continuous integration, identify whether the agent runs with repository tokens, artifact-storage access or deployment credentials. Ask which are needed for the assigned job. A successful test on a developer's restricted environment does not establish the same boundary in a build runner with broader privileges.
Preserve evidence outside the conversation
An incident responder needs to correlate extension installation and process activity with the task timeline. Useful records can include the installed revision, execution identity, file-access denials and network decisions. Collect the minimum information needed to answer the investigation question and apply the organization's retention and access rules.
Avoid treating an absent model tool call as proof that no host operation occurred. The record should explain which telemetry was collected and which paths remain unobserved. That distinction helps an investigator separate a verified denial from a monitoring gap.
Secondary coverage of CERT-EU's report is source-derived. It can establish that the research received coverage; it does not independently validate the lab telemetry. The primary report remains the basis for the experimental claims here.
Give runtime scanning a defined role
Maetra Secure inspects covered prompts, messages, tool calls and outputs for runtime threats. Discover supports inventory and change detection. Those capabilities can contribute to a deployment review, but scanning a model's inputs or tool calls does not replace host-level controls over arbitrary executable code.
The immediate operating task is to assign an owner to the extension execution boundary and test one file-access or outbound-network restriction in a safe environment. The Maetra documentation explains the product boundaries teams should consider when deciding where runtime inspection fits into that broader control plan.
Sources
- CERT-EU: Beyond the model: backdoors in AI agent harnesses, October 30, 2026. Controlled research on locally modified packages, not a report of modified public releases.