devopsy.kinsta.cloud

Author: Jaime Hampton

Docker Introduces Open Sandbox Kit Spec for AI Agent Permissions

AI agents are getting good at probing the boundaries developers put around them. Their ability to improvise makes them hard to contain.

“You ask for something in a very high-level, vague-at-best way. You walk away, and you come back to a remarkable pile of mostly working software. But you then realize that you gave a probabilistic machine access to your life and your systems,” said Docker President and COO Mark Cavage, speaking to the crowd at the opening session of the WeAreDevelopers North America conference in San Jose Thursday.

During his keynote, Cavage unveiled a new specification for packaging an AI agent and its tools together with a declaration of the access it requests from a sandbox. He also announced that Docker plans to contribute the new specification to the Cloud Native Computing Foundation.

A Common Format for Agent Sandboxes

Published under the Apache 2.0 license, the specification is meant to give developers and sandbox providers a common format they can use across different sandbox runtimes. The goal is to let developers define an agent environment once rather than recreate its configuration and access requirements for each sandbox platform.

In Docker’s model, a Sandbox Kit packages either an agent workload or supporting components for use inside a sandbox. Under the new format, those Kits are packaged as OCI images, with descriptors listing the network hosts, credentials, volumes and other capabilities they request. Docker says using existing OCI mechanisms lets teams build, store, sign and scan Kits with the same tools they already use for containers.

Docker already offered Sandbox Kits through Docker Sandboxes, but the new open specification is for implementation by runtimes outside Docker’s own. Cavage said the planned CNCF contribution will be formally submitted later this fall, with the goal of putting the specification’s development under neutral governance with contributions from agent developers, model companies, sandbox vendors and others.

Containers vs Containment

Cavage framed the need for stronger controls around the way coding agents work, since they do not simply execute a predefined workload. To complete a task, they may install dependencies, run code, call external services and probe the environment for capabilities they can use.

On stage, he demoed the problem by running Claude inside a Docker container with a secret file stored on the host. The agent discovered that the host Docker socket had been mounted into the container and used it to reach the file. Cavage stressed that Claude had not found a zero-day. Instead, it had used a configuration he described as one of the longest-running critiques of Docker: mounting the host Docker socket into a container, giving workloads inside the container access to the host Docker daemon.

Cavage used the demo to distinguish between containers and containment. The agent had not defeated Docker’s isolation. It had found access that the container configuration already exposed. Containers were designed to isolate application workloads, he argued, while agents make decisions about how to use the capabilities available to them. “We have to separate containers from containment,” he said.

Reviewing Access Before Agents Run

Because those access declarations live inside the OCI image, changes in an agent’s authority can also be reviewed. Pinning a Kit to a specific image digest pins its contents and access declarations together. If an update asks to reach another host or use another credential, that expansion can show up for review, while runtimes that gate updates can stop it for approval.

Docker Sandboxes is currently the first conforming runtime to implement the specification. If other sandbox runtimes implement it and agent and tool vendors adopt it, DevOps teams could gain a common way to review both what an agent runs and what authority it requests before it runs.

September 28, 2026
Leaked GitLab Email Tokens Can Reach Code, Secrets and CI/CD Pipelines

Security researchers have uncovered a GitLab behavior that could let attackers use a leaked project email address to push code, trigger CI/CD jobs and reach other repositories accessible to the address owner.

Aikido Security researcher Joe Leon detailed the attack path this week in a blog post after reporting it to GitLab earlier this year. The issue involves GitLab’s incoming email token, a credential embedded in private email addresses that GitLab provides for creating issues and merge requests by email.

“The token inside this email address is essentially a fine-grained personal access token with significant access to your GitLab projects,” the report said.

GitLab’s documentation says the token never expires and warns that anyone who obtains it can create issues and merge requests as the user. GitLab also allows users to attach .patch files when creating merge requests by email. GitLab applies the patches to the named source branch or creates the branch if it does not already exist.

Aikido found that the same incoming email token appeared in addresses generated for different projects belonging to one user. The researchers said an attacker who obtained one of those addresses could change its suffix from -issue to -merge-request, attach a patch and submit code using the victim’s existing GitLab permissions.

The same mechanism can also turn a leaked email token into a path for CI/CD execution. Aikido demonstrated adding a job to .gitlab-ci.yml via an emailed patch, causing GitLab to run a pipeline as the victim. Aikido also showed how to use the same access to exfiltrate private source code, read CI/CD variables and secrets, and use a job’s CI_JOB_TOKEN to access additional GitLab resources permitted to that job token.

The attack is constrained by the victim’s existing GitLab permissions and by the attacker’s knowledge of the target project. The incoming email token does not elevate privileges. Aikido said an address tied to a Guest account would have little value for these attack paths, while one tied to a Maintainer could potentially expose protected branches and CI/CD variables, depending on the project’s configuration. Reaching another project also requires its project path and ID. GitLab exposes both for public projects, but going after a private project would require the attacker to obtain identifying information about it through another leak.

Aikido reported the behavior through HackerOne in May and said the report was initially closed as intended behavior. Aikido said it filed a confidential GitLab issue in June, after which GitLab updated its interface and documentation. A GitLab merge request opened July 28 said previous descriptions of the token were inconsistent and updated them to more accurately explain its capabilities and emphasize that the token should remain private.

So far, GitLab has responded by making the token’s capabilities and risks clearer but has not disabled the underlying email functionality. Users who believe one of these addresses has been exposed can reset the token from GitLab’s personal access token settings, which invalidates addresses containing the previous token. For organizations that rely on email-created issues or merge requests, the disclosure is a reminder that exposing those addresses can allow actions under the account owner’s existing GitLab privileges.

September 25, 2026
Factory Raises $200M as It Builds Agents Across the Software Lifecycle

Enterprise coding agent startup Factory announced it has raised $200 million at a $5 billion valuation, more than tripling its valuation from its last funding round five months ago.

Founded in 2023, Factory develops AI agents for software engineering teams. Its platform is designed for work across the full software development lifecycle, including building, testing and maintaining applications. The company says its customers include Nvidia, Adobe, Palo Alto Networks, T-Mobile, and Blackstone.

As AI coding startups proliferate, Factory is trying to differentiate itself by taking agents beyond discrete coding tasks and into coordinated software development workflows. In June, the company introduced Factory 2.0, which it describes as a “software factory” that brings tasks such as code review, security analysis, documentation, quality assurance and incident response onto a common agent platform. The platform also supports cloud, self-hosted and fully air-gapped deployments, which could provide flexibility for organizations with strict security or data residency requirements. Factory is also pursuing FedRAMP authorization for a GovCloud deployment aimed at public-sector customers.

Factory envisions its software factory as a continuous loop beginning with inputs like bug reports, customer feedback and business requirements. Those inputs are triaged into changes that can be built, tested, reviewed, secured, deployed and monitored. The company says this setup allows different stages of development to share organizational context and information. For example, a security finding could inform code review, or an incident could be tied back to the change that caused it. Factory also emphasizes model independence, allowing enterprises to select different AI models for different tasks or route work automatically based on factors like cost, speed and performance.

The new round drew backing from a roster of major investment firms, including Blackstone, Khosla Ventures, Sequoia Capital, Insight Partners, Evantic Capital, Sound Ventures, NEA, Mantis VC and Clearlake. Factory said the financing brings its total funding to more than $400 million. Factory’s announcement did not identify the round as a Series D or specify whether the $5 billion valuation is pre-money or post-money. In April, the company raised a $150 million Series C at a $1.5 billion valuation.

Factory was founded by Princeton alumni Matan Grinberg and Eno Reyes, who did not formally meet until after graduating. Grinberg was pursuing a physics Ph.D. at UC Berkeley and Reyes was working as a machine learning engineer when the two connected at a San Francisco hackathon. They decided to start a company soon afterward and built the first Factory demo in 72 hours, which helped secure an early investment from Sequoia Capital.

Factory closed its funding announcement with a recruiting pitch for what it called “unreasonably ambitious polymaths” who want to help build the future of software. The unusual wording offers a glimpse of the multidisciplinary talent sought by a company that has grown from a 72-hour prototype to a $5 billion valuation in roughly three years.

September 15, 2026
EU-Funded CodeSupply Offers Grants for Open Source Software Supply Chain R&D

Software supply chain, security and compliance tools all depend on accurate information about the packages they analyze, but that data is often fragmented across multiple sources and can be difficult to access or use consistently. A new European Union-funded initiative called CodeSupply, coordinated by the NLnet Foundation, is making €400,000 in grants available for open source R&D projects aimed at improving the availability, quality and interoperability of software package data.

For the current call, projects can request between €5,000 and €50,000, with proposals due Nov. 3. The funding is available for small to medium-sized research and development projects that contribute to CodeSupply’s goals around software supply chain security, software metadata, cybersecurity, open source license compliance and the reliability of the open internet.

Which Projects Are Eligible?

The call covers new and existing technologies with demonstrated real-world impact. Eligible activities range from scientific research and software engineering to security audits, formal security proofs, technical validation, documentation and standardization. The program can also support open source hardware development, usability improvements, participation in technical events, project management and essential infrastructure costs. Projects focused on open source license compliance may also qualify, including tools that help identify, document or manage licensing requirements.

CodeSupply lists publishing current, correct and comprehensive software metadata as one of its three main objectives. The initiative says more complete metadata can help with understanding and managing software components, dependencies, licensing information and security-related information. The call does not describe a specific type of metadata project, but says relevant work could include research, software development and other technical solutions, as well as mechanisms for making essential datasets more widely accessible across the open source and internet ecosystem.

Applicants are expected to show how their proposed work contributes to open source development and connects directly to CodeSupply’s objectives. Proposals should define the problem being addressed, describe the proposed technical work and explain its expected impact. To qualify, proposals must be written in English, align with CodeSupply’s goals, make research and development their primary objective and have a clear European dimension. Projects that pass that initial screening are evaluated on technical feasibility, relevance and potential impact, and value for money.

What is CodeSupply?

CodeSupply is part of the European Commission’s Open Internet Stack initiative, which aims to develop open, secure and reusable technologies that can serve as building blocks for digital infrastructure. The initiative builds on the EU’s earlier Next Generation Internet programs and is intended to give public agencies, businesses and individual users more control over essential technologies.

CodeSupply is a collaboration among four organizations. NLnet Foundation, a Dutch public benefit organization that leads the NGI Zero initiative, is coordinating the project. Other participants include AboutCode, a Belgian nonprofit focused on software package origin, licensing, provenance and software supply chain security; the Edsger Institute, a Dutch nonprofit specializing in reproducible hosting stacks and software composition analysis; and Universidad Rey Juan Carlos, a public research university in Spain. Funding for CodeSupply comes from the European Commission’s Directorate-General for Communications Networks, Content and Technology through Horizon Europe. Read more about CodeSupply here.

September 8, 2026
Dash0 Acquires Polar Signals for Continuous Profiling and GPU Visibility

Observability startup Dash0 announced this week that it acquired Berlin-based continuous profiling specialist Polar Signals. The deal adds continuous profiling to SignalStore, Dash0’s OpenTelemetry-native data platform.

Continuous profiling has been part of the developer toolbox for years and provides teams with an ongoing view of where running applications spend CPU time, allocate memory and consume other resources. Many observability platforms now include some form of it. Polar Signals offers a less common capability: continuous profiling of Nvidia CUDA workloads in production. Dash0 said the technology can profile both AI training and inference workloads, with visibility down to individual GPU kernels, to help monitor resource consumption and pinpoint where performance problems are occurring.

Dash0 will integrate Polar Signals’ profiling data into SignalStore and feed it into Agent0, its AI agent for production operations. Agent0 can already correlate telemetry with source code and prepare pull requests for fixes. Profiling adds another source of runtime evidence to those investigations, which Agent0 can use when deciding what changes to propose. Dash0 will also let external coding agents access that profiling data through its MCP server, giving them runtime context for suggesting changes.

The company is also developing AutoTune, an Agent0 capability that will analyze profiling data on a schedule and look for opportunities to improve CPU and memory use. When it identifies an optimization, AutoTune is designed to open a pull request with the proposed change and the profiling evidence behind it. Dash0 said the system will not merge those changes on its own. Developers will still need to review the changes and decide whether to accept them.

The acquisition grew out of a conversation between Dash0 CEO Mirko Novakovic and Polar Signals founder Frederic Branczyk at a dinner in Berlin. Branczyk wrote that Novakovic described the cost, performance and operational challenges Dash0 was encountering with ClickHouse, while Polar Signals had already built several iterations of a database for similar workloads. As they talked, Branczyk said, it became clear the companies had been “working toward the same thing from opposite ends.”

That overlap suggests why the deal extends beyond continuous profiling. Dash0 is also acquiring Polar Signals’ Great Lakes storage engine and engineering team. Polar Signals built Great Lakes to handle the high-cardinality data generated by profiling, and Branczyk said Dash0 eventually plans to replace ClickHouse beneath SignalStore with Great Lakes. The goal is to store metrics, logs, traces and profiles in the same engine, he said. The deal also includes Parca, Polar Signals’ open source continuous profiling project, which the company said will remain open source and continue to be maintained.

Financial terms of the deal were not disclosed. Dash0, founded in 2023, raised $110 million in March at a $1 billion valuation and said it would use some of the funding to pursue strategic acquisitions. The company now has more than 750 customers.

The acquisition also complements Dash0’s OpenTelemetry-based architecture. OpenTelemetry Profiles, the project’s profiling specification, entered public alpha in March, extending the OpenTelemetry data model to include profiles alongside traces, metrics and logs. Polar Signals has contributed to that work, bringing Dash0 a team already involved in shaping OpenTelemetry’s emerging profiling standard.

August 21, 2026
Dynatrace Acquires Arize as AI Agents Deepen the Observability Challenge

Dynatrace announced Thursday it has agreed to acquire AI observability company Arize in a $915 million cash and stock transaction.

Rick McConnell, CEO of Dynatrace, said the company expects demand for AI observability will keep growing as more AI systems move into production. He said acquiring Arize would speed up Dynatrace’s roadmap, expand its developer reach and bring Arize’s AI team into the company.

Dynatrace said the deal would combine Arize’s AI evaluation and observability software with its own platform for correlating telemetry and tracing dependencies across applications, services and infrastructure. The transaction includes about $815 million in cash and replacement equity awards for Arize employees and is expected to close later this quarter or early in Dynatrace’s fiscal third quarter.

DevOps teams are already used to piecing together telemetry across distributed systems when something breaks. AI adds another source of context to correlate when information about model and agent behavior and output quality lives in separate systems from the application and infrastructure data used to investigate failures. That can leave AI engineering, SRE and platform teams trying to reconstruct the full story across the production environment.

That is where Arize fits. Its tools track what happens during an AI or agent run, including model calls, retrieval and tool use, and use those traces to evaluate both the final output and the path the agent took to reach it. Arize co-founder Jason Lopatecki said the company collects billions of agent trajectory events, while Dynatrace tracks what the surrounding software does. Combining those views could give teams an easier trail between an agent’s actions and the transaction, service or infrastructure involved when something goes wrong.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, sees that connection as the deal’s key value.

“Dynatrace is paying $915 million for the observability-native link between AI observation and agent behavior,” Ashley told devopsy.kinsta.cloud. “An AI engineer measures output quality in one tool. Without it, the current state-of-the-art is that the on-call SRE sees a failed transaction and has no path back to the prompt.”

The issue becomes more than a debugging problem once agents start taking actions in production. Teams also need a record of what the agent did, what systems it touched and what happened afterward. When that trail is incomplete, verifying agent behavior becomes another manual task for platform and operations teams.

“Enterprises ship agents only as fast as they can prove that those agents’ behavior is accountable,” Ashley said. “Verification debt lands on platform teams as a review backlog.” Because agents often run across more than one vendor’s stack, Ashley said enterprises should make that accountability trail a contract requirement that carries across those different systems. That trail has to remain intact as agents cross vendor boundaries.

That need for continuity helps explain the fit between Arize and Dynatrace. Lopatecki said Arize contributes a deep record of agent trajectories, while Dynatrace provides the traces and logs needed to connect those actions with the environment. He sees the acquisition as a way to join those two views as agents become more embedded in production software.

“These two areas just belong together if we are going to build the future systems that continuously improve,” he said.

August 17, 2026
OpenAI Open Sources Codex Security CLI for the Merge Path

OpenAI has released its Codex Security command-line interface and software development kit as open source software under the Apache 2.0 license, providing a new way to bring its AI security scanner into development workflows.

The CLI can scan repositories, review staged and unstaged changes before a commit, compare findings across scans and export results for use in other code-scanning tools. Teams can also run it in CI and set a severity threshold that returns a failing status when a completed scan identifies a finding at or above that level. OpenAI recommends starting with advisory results before allowing findings to affect the CI check.

Because the client code is public, teams can inspect and adapt the CLI or SDK to fit their own tooling. But that openness stops at the integration layer, as the service that performs the underlying analysis remains under OpenAI’s control.

“OpenAI open-sourced the client and kept the scanner. That is distribution, not openness,” said Mitch Ashley, VP and practice lead for DevOps and application development with the Futurum Group. “The Apache-2.0 CLI lands in CI configs and pre-commit hooks while the beta-gated backend holds the model, triage logic, and the billing relationship.”

In practice, teams cannot use the published client code alone to operate a standalone scanner. The CLI and SDK remain in limited beta and are available only to approved customers and partners, according to OpenAI. Local users sign in with a ChatGPT account, while CI and other automated workflows use an OpenAI API key. Full repository scans may also require Trusted Access for Cyber. Developers can therefore inspect and modify the integration software, but the system that generates and evaluates findings still depends on OpenAI’s hosted service.

Security scanning in CI is already common, and established application security platforms are increasingly adding AI features to help assess findings, generate fixes and check whether those fixes work. Codex Security combines those activities in a more integrated agent workflow. According to OpenAI, the agent creates a threat model for the repository, examines possible attack paths, attempts to reproduce suspected vulnerabilities in an isolated environment and proposes patches for human review. It can then check whether a vulnerability remains after a fix is merged.

“Every team already runs a scanner in CI,” Ashley said. “The advance is an agent that confirms the finding, writes the patch, and verifies it across runs.”

Giving the agent responsibility for validating potential vulnerabilities and proposed fixes raises the standard it must meet before teams allow its output to block code changes. OpenAI says AI scans can produce different results even when the configuration remains unchanged, and that a previously reported issue disappearing from a later scan does not prove the vulnerability was fixed.

Ashley said Codex Security should earn a role as a merge gate only after OpenAI demonstrates that repeated scans of the same code produce sufficiently consistent findings. For DevOps teams, the unresolved question is whether those results can become dependable enough to decide whether a code change should be allowed to merge.

July 29, 2026
Pentagon Campaign Seeks Engineers for Defense AI and Software Modernization

The Pentagon has announced the launch of War Force, a recruiting campaign for software engineers whose work would support multiple defense AI and modernization projects. The campaign is being run in partnership with the U.S. Office of Personnel Management as part of the federal government’s U.S. Tech Force program. OPM said the program is intended to recruit hundreds of qualified applicants for technical roles supporting national security missions.

OPM Director Scott Kupor said the campaign is designed to give engineers a path into complex government technology work tied to defense priorities. War Force engineers will work across technical and mission teams to deploy and integrate technologies such as frontier AI, machine learning, automation and data systems. The agency said the engineers will also design, build and maintain software that supports the military’s operational needs.

The public description of the Forward Deployed Engineer role, found on the USAJOBS posting, shows the kind of software delivery work the Pentagon is looking to staff through the campaign. The role includes secure software integration, CI/CD pipeline modernization, automated testing frameworks and infrastructure as code.

Much of the work in defense AI depends on the delivery systems around it, including deployment pipelines, repeatable testing, integration practices, security controls and ongoing maintenance. OPM said War Force engineers will embed at the “unit level” across the Pentagon, an approach that could bring software teams closer to the people using those tools in the field. That proximity could matter in military software projects, where engineers may otherwise be several steps removed from the users and conditions their work is meant to support.

Placing engineers closer to operations could help agencies move faster, but the program’s temporary structure raises questions about handoff and maintenance. The USAJOBS listing describes the Forward Deployed Engineer role as a term appointment that cannot exceed two years, though it may be extended to a maximum of four years. That could help agencies bring in engineering talent quickly, but the long-term value of the work will depend on whether teams can maintain the software and delivery practices after those engineers depart.

The sustainment question seems especially relevant because the War Force campaign is arriving at a time of reduced federal staffing. A recent Government Accountability Office report found that 22 major federal agencies lost nearly 256,000 employees from December 2024 to January 2026, an 11% decline. The report said the Defense Department’s civilian workforce dropped by 10.7% in the same timeframe.

Against that smaller workforce backdrop, the USAJOBS posting lists the practical details of the Forward Deployed Engineer role. The position is listed as GS-14, a senior-level federal pay grade, with salary ranging from $125,776 to $197,200 depending on duty location and hiring agency. Recruitment and/or relocation incentives may be available, depending on the hiring agency’s policies. The posting says many vacancies are in the Washington, D.C., metropolitan area, with location also negotiable after selection. Applicants can indicate geographic preferences, but the posting says those preferences do not guarantee consideration, selection or assignment to a specific location. The role is not remote or telework eligible.

Applicants must also complete USA Hire and industry coding assessments. The required technical competencies include general programming and algorithms, requirements understanding and implementation, and debugging and troubleshooting.

July 8, 2026
Tenet’s ‘Agentjacking’ Attack Turns Sentry Errors Into Code Execution

AI coding agents can create a new code execution risk when they treat externally influenced error data as trusted guidance and have access to command line tools, according to new research from Tenet Security.

The security company demonstrated an indirect prompt injection technique it calls “Agentjacking” in a recent report. In its proof of concept, an attacker planted malicious instructions inside a fake Sentry error report, causing an AI coding agent to execute an attacker-supplied command during a routine debugging task.

The attack began with a Sentry Data Source Name (DSN), a credential commonly embedded in a website’s frontend JavaScript. Sentry treats DSNs as public and write-only because they allow applications to submit events without granting access to the project or its existing data. But an attacker who obtains the DSN can use it to send a false error event to the project’s ingest endpoint and control fields, including the error message, stack trace, tags, context and breadcrumbs.

Tenet formatted the event so that, when retrieved through Sentry’s MCP server, it seemed like legitimate diagnostic guidance. It included headings, code blocks and a fake resolution section containing an npm command. When a developer asked the coding agent to investigate unresolved Sentry issues, the agent accepted the injected instructions as part of the debugging workflow and ran the command.

That command used npx to download and execute a Tenet-controlled package from the public npm registry with the developer’s local permissions. According to the researchers, the package checked what resources were accessible in the development environment, including environment variables, cloud configuration files, Git credentials and information about private repositories.

“What makes this attack unique is that it doesn’t target the developer directly – it targets the AI agent that the developer trusts,” the company wrote. The attacker does not need to compromise Sentry, contact the developer or access the developer’s machine directly because the malicious instructions enter through a public DSN and move through a normal debugging workflow. Because the injected content is formatted to resemble legitimate Sentry guidance, the agent cannot distinguish it from trusted diagnostic output.

Although indirect prompt injection is already a known risk for LLM applications, Tenet’s “Agentjacking” technique is notable because it shows how risk can emerge from the combination of tools available to an agent. Sentry’s MCP server retrieves error data but does not itself execute user-provided commands. In Tenet’s test, the coding agent used separate command-line access to run the instruction embedded in the event. Security teams may therefore need to assess an agent’s combined permissions and tool access rather than evaluating each integration alone.

Tenet said it identified 2,388 organizations whose Sentry DSNs accepted injected events, recorded an 85% success rate in its testing and observed more than 100 agent executions. Those figures do not represent 2,388 confirmed compromises, since exploitation still depends on an organization using an agent connected to Sentry and granting that agent command execution privileges. Also, Tenet’s claim that existing security tools cannot detect the technique is difficult to substantiate. Endpoint monitoring or controls like command approval, sandboxing, restricted network access and limited credentials could interrupt the attack or reduce its impact.

For DevOps teams, the case shows how externally influenced telemetry can become an attack channel when coding agents are connected to observability platforms, source code and command line tools. “The era of indirect prompt injection via developer tools has arrived,” the Tenet team said.

June 15, 2026