PENTESTY · EDITORIAL ANALYSIS · · 4 min read
AI agents: who receives the data and substantiates the audit?
A provider name in an interface and a security score are insufficient acceptance evidence. Check the data route and how the reported result can be reproduced.
By Pentesty
The documented case and its limits
This analysis was prompted by Cyber Security Brazil’s report. In its October 12 analysis, Elastic linked npm packages @apexacc/cli and @apexacc/audit to a fake Web3 accelerator. It reported Windows and macOS malware, rerouted LLM requests, MCP server registration and fabricated audit results. The team did not observe malicious substitution of LLM responses. These are findings from that investigation, without establishing compromise of every agent or named provider.
Approve a data route that can be checked
Imagine a team accepting AI credits offered by a partner. Before using internal documents, describe the authorized path: application, intermediary service, final provider and connected tools. Identify the owner of each handoff and the information the task actually requires. An approved intermediary can be legitimate when its participation is explicit and its responsibilities are understood.
Compare that declaration with the process’s effective configuration and available communication records. Retain the version, package origin, environment and observation time. The analysis of network boundaries for agents complements this exercise. The specific acceptance question here is whether the observed recipient matches the one the business approved for the task and its information.
Follow context using synthetic markers
Prepare an authorized environment without production credentials, customer documents or real wallets. Use a known test integration, a controlled receiver and fictional content carrying a unique marker. Define which stages may read that content and which destinations may receive it before starting the session. The exercise owner should approve those boundaries in writing.
Follow a simple task and an approved local-tool action. Check whether the marker appears at the expected receiver and what remains in later messages. Retain only the material necessary to demonstrate the path. Absence from a partial capture leaves an observation gap; describe that gap in the test result so that reviewers understand its coverage.
- Input: fictional task, permitted information and test identity.
- Path: process, effective configuration and observed recipient.
- Persistence: configuration changes and behavior after restart.
- Closure: environment cleanup and temporary-access revocation.
Require evidence before accepting an automated audit
Choose a small sample the team understands: a laboratory project with a verifiable condition and another without it. Agree what the tool should examine, which inputs it needs and how unavailable analysis must be communicated. An acceptance criterion can require it to declare insufficient information before issuing a conclusion about the submitted project.
Ask for a connection between each finding, the examined artifact and a reproducible observation. A report can look polished while leaving that connection unanswered. The review of pentest report evidence helps define what the buyer needs to receive before deciding on remediation and assigning work to the application owner.
Verify the return to approved configuration
After the trial, compare previous and current configuration: providers, MCP servers, startup behavior and granted permissions. Check whether ending the supplier relationship or removing a package closes the associated access. Assign each outstanding item to an owner who can confirm closure, keeping secrets out of shared evidence and retaining only the records required for the decision.
Deliver a decision identifying the assessed set, observed paths and remaining questions. Repeat the sample when the package, intermediary or tools change. The trial supports acceptance of that integration under its examined conditions, with coverage stated clearly enough for another team to review the outcome and understand what would require a separate assessment.
Frequently asked questions
Does the provider name displayed by the agent confirm the recipient?
Acceptance should compare the declared destination with effective configuration and observed communication. If an intermediary is involved, record its purpose, approval and access to the submitted information.
Must we execute the malicious packages to perform this test?
The proposed exercise uses a known integration, fictional content and controlled services. Malware analysis requires a separate scope and environment; it is not a prerequisite for this acceptance trial.
How should we evaluate an AI-generated security score?
Define inputs, coverage and verifiable outcomes beforehand. Request the relationship between the score, examined artifacts and evidence, including disclosure of missing information or unavailable analysis.
What evidence should accompany approval?
Record versions, recipients, configurations, sample outcomes and limitations. Include the acceptance owner and confirmation that cleanup and temporary-access closure were completed.
Sources and references
- Elastic Security Labs: October 12, 2026 Apex investigation
- Cyber Security Brazil: editorial news reference
Original Pentesty analysis, published October 20, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.