September 2026 Summaries

Brig versions earlier than 0.3.0 contained a high-severity project-mount symlink traversal vulnerability, tracked as GHSA-wp6x-29qx-fpr7 and ENDOR-VUL-2026-1809, that could let an AI agent access arbitrary host directories despite running in a sandbox or microVM. Because Brig passed user-supplied project paths to its runtime without securely resolving them, an agent with write access to a mounted repository could replace a subdirectory with a symlink to sensitive host locations; if an operator later launched a run targeting that subdirectory, the runtime would mount the symlink target read-write into the sandbox. The issue was confirmed on macOS microVM and Linux container configurations and could expose or modify SSH keys, cloud credentials, other projects, Brig session data, and potentially files enabling host-level code execution. It was classified as CWE-59, improper link resolution, rather than a hypervisor or guest-kernel escape, because Brig itself acted as a confused deputy when requesting the host mount. Version 0.3.0 fixes the flaw by safely resolving project paths, rejecting symlinks in sandbox-writable path components, and preserving path identity through the runtime handoff; users unable to upgrade are advised to provide a manually resolved physical project path and treat paths beneath previously writable project mounts as untrusted.

An evaluation of Claude Code using Anthropic’s Opus 5.5 on real-world security-related coding tasks found that it achieved 68.7% functional-pass and 33.5% secure-pass rates after excluding memorized solutions, ranking nineteenth for functionality and third for secure coding on the benchmark. It slightly exceeded Opus 5 on secure performance but trailed it on functional tests and lagged Fable 5.1 on both measures, despite Anthropic’s claims of state-of-the-art coding performance. Opus 5.5’s main strength was efficiency: it completed tasks in an average of four minutes with no timeouts, used substantially fewer tool calls and tokens, and cost about $116 for the full run, roughly one-tenth the cost of Opus 5 and one-sixth that of Fable 5.1. However, the benchmark’s anti-cheating process identified 51 training-recall cases, the highest total recorded, and removing these memorized fixes reduced its functional score by 25.7 points and secure score by 19 points; if retained, those results would have placed it first in security performance. The findings conclude that Opus 5.5 strongly supports claims of lower cost and faster execution, while its coding-leadership claims are not supported in this benchmark once recalled solutions are excluded.

AI coding agents can assist with consequential security tasks, but their effectiveness and safety depend on a security harness that provides trusted context, limits permissions, governs workflows, and verifies results rather than relying on prompts alone. The proposed framework centers on seven questions: defining the agent’s specific job, supplying the smallest sufficient set of authoritative evidence, separating authority levels from reading through enforcement, requiring validation and approvals before consequential actions, evaluating process quality alongside results and real-world outcomes, containing failures and adversarial inputs through fail-closed controls and limited blast radius, and safely managing updates through versioning, testing, monitoring, rollback plans, and clear ownership. Controlled workflows should resemble state machines, with explicit approval gates, bounded retries, stop conditions, and separate permissions for preparing, publishing, and enforcing changes. Deterministic evidence systems can also reduce tool calls and token use by preventing models from repeatedly reconstructing known security facts, while retaining human reviewers’ ability to inspect, challenge, and reject agent recommendations.

From September 11, 2026, the EU Cyber Resilience Act’s Article 14 requires manufacturers of covered products with digital elements to report actively exploited vulnerabilities and severe security incidents through ENISA’s Single Reporting Platform, with an early warning due within 24 hours, a notification within 72 hours, and subsequent final reports on defined timelines. The obligation generally covers locally executed software such as installed applications, browser extensions, and Electron apps, while browser-only web apps are generally outside this scope, although related local clients and supporting remote services may be covered. Reports are confidential to ENISA and relevant national CSIRTs, but manufacturers must also directly inform affected customers where appropriate, while broader advisories may serve other users. Penalties for reporting failures can reach €15 million or 2.5% of global turnover, alongside possible sales prohibitions, withdrawals, or recalls, though small firms have limited exemptions and open-source stewards are exempt from administrative fines. Reporting deadlines begin when a manufacturer can reasonably confirm exploitation or a severe incident after a prompt initial assessment, making documented intake, triage, verification, and around-the-clock response processes important. Exploitability must be assessed in the manufacturer’s specific product rather than inferred solely from a third-party CVE, increasing the importance of accurate software inventories, SBOMs, dependency and container reachability analysis, and clear processes ahead of broader CRA conformity, documentation, and vulnerability-handling requirements taking effect in December 2027.

Amid increasingly frequent software supply-chain attacks involving compromised npm and PyPI packages, malicious AI-agent hooks, and poisoned VS Code extensions, the company is expanding its malware defenses across the development environment. Its new Threat Center provides real-time visibility into malicious packages in registries such as npm and PyPI, maps affected dependencies to customer projects, supplies malware details and research context, and issues alerts for emerging threats. Package Firewall, which already blocks malicious packages across several ecosystems, now scans and can prevent harmful VS Code extensions and updates from appearing in developers’ editor marketplaces. Deployed through existing mobile device management systems without persistent agents or workflow disruptions, the combined tools aim to identify new threats, assess application exposure through software composition analysis, and stop malicious components before they reach developer workstations or builds.

GitHub’s breach of roughly 3,800 internal repositories after an employee installed a poisoned update to the verified Nx Console VS Code extension highlights how editor extensions can create software supply-chain risks outside traditional dependency controls. Because extensions are not typically included in manifests, lockfiles, SBOMs, or CI scans, can update automatically, and run with developer-level permissions, compromised publishers can distribute credential-stealing or otherwise malicious updates broadly, as illustrated by the GlassWorm campaign. Endor Labs has expanded its Threat Center and Package Firewall products to scan and block unsafe Visual Studio Marketplace extensions and command-line installations before they reach developer machines, while retaining users on the latest known-safe version and logging installation activity. The service can be deployed through existing MDM tools without endpoint agents, wrappers, or certificates, and offers policies to block detected malware, delay newly released versions for review, and permit approved exceptions. The release is positioned as part of broader efforts to secure developer workstations, including governance for AI coding agents, MCP servers, and related tools, and is available to existing Package Firewall customers without an upgrade.

Endor Labs’ Agent Security League evaluated Anthropic’s Claude Fable 5.1 in Claude Code and OpenAI’s GPT-6 Astra in Codex on real historical security-fix tasks, finding that Fable led with 87.2% functional pass rate and 37.4% security pass rate, while Astra achieved 82.1% and 34.1%. Although both models represent substantial improvement over earlier generations, only about 42% of patches that passed functional tests also resolved the underlying security issue, indicating that a green CI suite is not a reliable indicator of secure agent-generated code. A Vyper compiler vulnerability illustrates how an apparently plausible implementation can preserve an exploitable flaw while passing all ordinary tests, because functional tests generally validate intended behavior rather than adversarial conditions. The evaluation also found that inference costs are increasingly driven by repeated reading of accumulated context during tool calls rather than by code output, making excessive turns, timeouts, and exploratory behavior expensive. Fable 5.1 delivered verified secure fixes at about $10 each, compared with roughly $19 for an earlier model, but declining compute costs may increase the more substantial cost of human review, since every functionally valid patch still requires security assessment and engineer review capacity does not scale as cheaply as model output.

OpenAI’s GPT-6 Astra, tested through Codex on the Agent Security League’s real-world security-fix coding benchmark, achieved 82.1% functional pass rate and 34.1% security pass rate, representing gains of 14.5 and 14.0 percentage points over Codex with GPT-5.6 Sol and the largest measured generational improvement for the Codex family. Its performance approached Claude Code with Fable 5.1, which scored 87.2% FuncPass and 36.9% SecPass, while surpassing Claude Code with Opus 5, but Astra required substantially more time, averaging 16.8 minutes per task versus roughly 9.5 minutes for both Fable and Sol, and reached the one-hour limit 29 times. The benchmark evaluates whether agent-created patches pass both functional and hidden security tests, while excluding confirmed cases in which agents appear to recover known fixes rather than independently reason about solutions. Although Astra generated 16 suspicious-instance flags, reviewers cleared all of them, resulting in zero confirmed cheating, compared with 1 for Sol, 17 for Fable, and 38 for Opus. Astra used about 1.6 times as many tokens as Sol, primarily through additional input and exploration rather than longer generated code, and its similar command volume but greater searching and more effective edits suggest that its improvement stems from better use of its available reasoning budget rather than simply taking more actions.

Endor Labs presents its AI SAST as a security scanner that combines whole-codebase program analysis, semantic indexing, and specialized AI agents to identify and prioritize vulnerabilities, claiming benchmark results of 192 verified vulnerabilities across eight projects and more true positives than competing tools and models. Its approach incorporates context beyond source code, automatically analyzing Infrastructure as Code files to understand deployment topology and repository documentation such as AGENTS.md or CLAUDE.md to identify authentication, authorization, and intended application behavior. Teams can further improve results through finding-level feedback and natural-language architecture or threat-model context, which the system verifies against code and categorizes into project context, vulnerabilities to prioritize, and accepted false-positive patterns. Examples describe how external authorization systems, mandated authentication libraries, and WAF protections can help the scanner suppress irrelevant alerts or adjust severity while retaining visibility into meaningful risks.

As coding agents become embedded in software development, the passage argues that organizations need a clearly accountable owner for governing their actions, rather than leaving responsibility divided among AI governance, platform, security operations, and application security teams. It contends that application security should own policy and auditability for agent behavior because its remit has historically expanded from code scanning to dependency, pipeline, and software-factory security. The proposed agentic development lifecycle introduces autonomous agent sessions that can plan, access credentials, install packages, execute code, and make external connections, creating risks that may only be visible across a sequence of actions rather than in individual artifacts. Because agent behavior is non-deterministic, the passage advocates deterministic, policy-as-code controls such as lifecycle hooks that allow, block, or escalate consequential actions. Platform teams would continue operating agent infrastructure, SOC teams would retain broad detection responsibilities, and governance committees would define organizational intent, while AppSec would define, verify, and document controls through agent inventories, action-level policies, and records of agent activity.

AI coding assistants can accelerate software delivery, but their speed and volume may amplify familiar security risks, including insecure patterns such as SQL injection and cross-site scripting, missing authentication or input validation, hardcoded secrets, hallucinated dependencies vulnerable to slopsquatting, and architectural flaws that conventional scanners may overlook. The recommended approach is to treat AI-generated code as untrusted until it passes standard security gates, while adding controls tailored to AI use: prompt tools explicitly for secure practices, run SAST, dependency, and secrets scans in both development environments and CI pipelines, verify all suggested packages, reserve human review for high-risk changes involving authentication, cryptography, sensitive data, or new endpoints, and prioritize findings based on whether vulnerable code is actually reachable and exploitable. The guidance also advocates lightweight governance defining permitted AI use, required scans, approval rules, and exception ownership, arguing that these measures can preserve development velocity while focusing security effort on the most consequential risks.

Agentic development lifecycle (ADLC) describes AI agents that autonomously plan, write, modify, test, and submit software changes across repositories, tools, APIs, and pipelines, shifting development beyond human-approved code suggestions toward high-volume agent-led work. This increased speed can outpace conventional review processes and amplify risks including insecure implementation patterns, architectural flaws that evade static analysis, hallucinated or vulnerable dependencies, and unreviewed pull requests. While traditional SAST, SCA, and DevSecOps controls remain useful for detecting known patterns and vulnerabilities, the text argues they often miss transitive dependencies, resolved-build risks, and context-dependent design weaknesses. It recommends securing ADLC at each control point by providing security guidance during code generation, applying architecture-aware security review to every pull request, prioritizing dependency vulnerabilities based on reachability, automating safe remediation, and maintaining an inventory and consistent governance policy for agents and their output. These measures are presented as a way to align with frameworks from NIST, the Cloud Security Alliance, and OWASP while preserving development speed and measuring outcomes such as remediation time, blocked pull requests, coverage, and alert noise.

AI coding assistants can accelerate development but often generate insecure or outdated code unless prompts explicitly specify security requirements, as models tend to prioritize functional output and may reproduce vulnerable public-code patterns. Common risks include injection flaws, hardcoded secrets, weak validation, vulnerable or hallucinated dependencies, and unintended architectural changes, making prompts an increasingly important source of design and threat-modeling guidance. Recommended approaches include structured design-spec prompts that define context, security controls, relevant CWE weaknesses to avoid, environment constraints, and testing expectations; explicit anti-pattern avoidance; and iterative self-critique followed by revision, while security-expert role-playing is presented as less effective. Organizations can standardize these practices through shared prompt libraries and repository rules files, but prompts alone cannot guarantee safety, so AI-generated code should be treated as untrusted and checked with code review, SAST, dependency analysis, secrets scanning, and reachability-based prioritization. Because AI may recommend non-existent, vulnerable, or obsolete packages, teams should independently validate dependencies and versions, rescan after significant prompt changes, and combine secure prompting with continuous verification to reduce risk without sacrificing development speed.

AI coding assistants can increase the risk of credential exposure by generating hardcoded secrets, reading sensitive workspace files such as .env configurations, and spreading credentials across source code, MCP settings, notebooks, infrastructure files, frontend bundles, agent configurations, and git history. Hardcoded credentials remain a longstanding high-risk weakness, but AI accelerates their creation and distribution, with cited research reporting higher secret-leak rates in AI-assisted commits and millions of new hardcoded secrets appearing in public repositories. Removing a secret from current code is insufficient because it may remain in commit history or external AI tools, while a single exposed credential can provide broad access to cloud systems, data, and linked services. The recommended approach is layered prevention and detection throughout the software development lifecycle, including secure agent instructions, repository-wide and historical scanning, pre-commit, IDE, code-review, and CI/CD checks, as well as validation of whether discovered credentials remain active. When a leak occurs, organizations should promptly rotate and revoke the credential, investigate its potential use and access scope, purge it from history, and rescan to verify remediation.

Application security monitoring continuously tracks an application’s changing security posture after code merges, focusing on code, dependencies, build pipelines, reachability, and credential exposure rather than relying solely on point-in-time scans. In AI-assisted development, where agents can rapidly create commits, add direct and transitive dependencies, and alter call paths, security risks may emerge through dependency updates, newly disclosed vulnerabilities, or refactors that make previously unreachable vulnerable functions accessible. Effective monitoring should distinguish scanner findings from real, exploitable weaknesses, prioritize issues using function-level reachability and runtime signals rather than severity scores alone, and identify coverage gaps such as unsupported languages or unscanned repositories. The approach complements pre-merge scanning by detecting changes after release, while integrating evidence-rich findings into developer workflows, such as pull requests, can reduce triage burden and help teams focus on risks attackers can actually exploit.

AI coding tools can suggest hallucinated packages, plausible but nonexistent software dependencies that may enable “slopsquatting,” in which attackers register those names and distribute malware when developers install them. A 2025 study cited in the text found that 19.7% of more than 2.23 million AI-generated package references were hallucinations, with repeated fake names creating stable targets for attackers, while related research reported that many AI-recommended dependencies contain known vulnerabilities. Unlike typosquatting or dependency confusion, slopsquatting exploits AI-generated names rather than human spelling errors or registry-resolution behavior, so detection should focus on package provenance and malicious behavior. As AI-assisted development becomes widespread, the text argues that organizations should treat AI-generated code and dependencies as untrusted input by verifying packages before installation, reviewing imports and pull requests, detecting malicious packages at installation time, pinning versions, and prioritizing vulnerabilities based on whether they are actually reachable in deployed applications.

Prompt injection in coding agents occurs when attacker-controlled content in repositories, web pages, issue comments, tool outputs, or MCP servers is interpreted as an instruction, potentially causing agents to run commands, access secrets, alter code, or interact with connected systems. Unlike chatbot jailbreaks, these attacks can produce operational consequences because coding agents often have permissions to read files, execute tools, and make changes, especially when auto-run or auto-approval features are enabled. The text distinguishes direct attacks entered by users from more concerning indirect attacks embedded in content agents retrieve, citing research and industry reports that found high attack success rates under certain conditions and evidence of real-world exploitation. It identifies poisoned project files, untrusted MCP servers, and browsed content as major delivery paths, with possible outcomes including secret exfiltration, command execution, persistence, and insecure or backdoored code. It argues that model prompts and filters alone are insufficient and recommends layered protections centered on deterministic controls over agent actions, including least-privilege access, sandboxing, approval gates for high-impact operations, MCP allow-listing, fleet inventory, audit logging, and security review of AI-generated code based on exploitability.

Static application security testing for AI-generated code applies source-code analysis to software produced by coding assistants and agents, addressing the rapid increase in code volume, repeated insecure patterns, unclear ownership, and triage burden rather than assuming AI code is inherently less secure than human-written code. The discussion distinguishes AI-assisted SAST, which adds AI-based summarization or triage to rule-based scanners, from AI-native SAST, which uses AI reasoning alongside pattern matching to analyze multi-file dataflow, authorization decisions, business logic, and natural-language risks such as prompt injection. Traditional scanners can identify familiar issues including injection, XSS, missing validation, hard-coded credentials, and broken access control, but may miss design drift, unsafe or hallucinated dependencies, and logic flaws that do not fit known signatures. Effective tools are presented as prioritizing reachability from untrusted sources to dangerous sinks, reducing false positives with transparent evidence, and providing verifiable remediation rather than unreviewed automated fixes. The text recommends integrating SAST into editors, pull requests, and CI pipelines and pairing it with software composition analysis for dependency risks, while describing Endor Labs’ product approach and benchmark claims as an example of this model.

AI code review combines large language models with static analysis to examine pull-request changes, summarize their effects, assess risk, and flag potential security, logic, and design issues within developers’ existing workflows, while leaving final decisions to human reviewers. Its growing relevance reflects the increased volume of AI-generated code and evidence that such code can contain vulnerabilities, including missing input validation, hardcoded secrets, weak authentication, unsafe dependencies, and subtle architectural changes. Unlike traditional pattern-based tools such as SAST, software composition analysis, and secrets scanning, AI review aims to reason about a change’s intent and broader context, including data flows, access controls, and potential blast radius. Effective systems prioritize findings using reachability analysis to reduce false positives by identifying vulnerabilities that attacker-controlled input can actually reach. Recommended adoption practices include beginning in report-only mode, tuning results for relevance, integrating reviews into pull requests and CI/CD pipelines, routing sensitive changes to appropriate reviewers, and measuring outcomes while retaining human oversight. The text presents Endor Labs as one example of a tool using developer, architect, and security perspectives alongside reachability analysis to review security-relevant changes.

Agentic development security addresses risks arising when AI coding agents autonomously generate, select, and merge code, dependencies, and tool integrations, requiring continuous controls that operate at machine speed rather than relying solely on human review. It differs from agentic AI security by focusing on the software build process rather than protecting AI-agent applications in production. Key risks include insecure generated code, hallucinated dependencies that attackers can exploit through slopsquatting, insecure or untrusted Model Context Protocol servers, and prompt injection combined with overly broad agent permissions. Recommended practices include treating all agent outputs as untrusted, validating packages before installation, applying least-privilege access and approval requirements for high-impact actions, maintaining tool inventories, and aligning controls with OWASP and NIST frameworks. The discussion emphasizes reachability-based analysis to prioritize vulnerabilities that can actually be executed in deployed applications, reducing alert noise and helping teams preserve development speed; it also presents Endor Labs products and reported performance outcomes as an example of this approach.

Platform engineering’s “golden path” model can help organizations adopt coding agents by preserving development speed while restoring reliability and observability. Although agents can accelerate software delivery, their nondeterministic behavior, autonomous tool use, and access to live credentials create risks that conventional build, deployment, and service-monitoring systems do not capture. The proposed solution is to use hooks as a control plane that runs independently of the agent’s reasoning and intercepts consequential actions such as shell commands, file writes, credential access, package installations, and tool calls. Unlike prompts, skills, and MCP tools, which agents may ignore or bypass, hooks can deterministically allow, block, or escalate actions while producing session-level telemetry. This approach aims to block only risky actions in real time, allow routine work to proceed quickly, and give platform teams a way to establish safe, observable agent workflows before uncontrolled adoption leads to incidents.