Corellium

Corellium is the hardware that agents and pipelines drive, not an agent that acts in other systems. Its integrations point inward: CI services such as GitHub Actions, GitLab, Jenkins, CircleCI and Travis CI create and run virtual devices through the Corellium CLI, and development tools from Vector, Lauterbach, Arm, Visual Studio and IAR connect to the virtual hardware for building and debugging. CoreModel lets outside peripheral models attach to a device's UART, I2C, SPI, CAN, GPIO and USB host buses over the network.

Corellium offers no connectors through which an agent would act in business systems such as a ticketing tool or a code host.

Sourcecellebrite.com/en/products/corellium/atlasread 2026-10-08

Multi step work belongs to whatever calls Corellium. In Cellebrite's own Atlas walkthrough, the Kiro IDE runs the loop of design, code, build, deploy, exercise and observe against a virtual NXP i.MX93, while Corellium supplies the board through two MCP servers and a VS Code extension gives a console into it. Devices in the same project share a virtual network, so a pipeline can stand up several boards that talk to each other.

Corellium itself has no workflow engine, step model or way for agents to hand work to one another.

Sourcecellebrite.com/en/blog/virtual-arm-hardware-firmware-development-corellium-atlasread 2026-10-08

What Corellium stores is virtual devices, firmware images, storage files and snapshots, not a knowledge base. Each supported board has its own reference pages (details, supported hardware components, quickstart and stock firmware), written for the engineers using it.

Corellium keeps no searchable index of a customer's documents and has no assistant that answers questions from one.

Sourcesupport.avh.corellium.com/sdk/apis/restread 2026-10-08

Calls through the API, the CLI and the MCP servers run straight away, whether they create a device, load firmware, restore a snapshot or drive a peripheral signal. There is no point where a person approves, pauses or rejects an agent's action on a virtual device before it happens.

What Corellium does offer is control over who can act at all: project administrators decide which users and teams can create and delete devices in a project, and domain administrators set each project's share of CPU cores. A failed run can be rolled back to a known good snapshot in seconds.

Sourcecellebrite.com/en/blog/virtual-arm-hardware-firmware-development-corellium-atlasread 2026-10-08

Sign in can run through the customer's own identity provider. Corellium supports SAML 2.0 with any compliant provider, naming Azure AD, Okta, ADFS and Ping Identity, and OpenID Connect, with accounts created at first sign in and SAML group mappings assigning each user a role and a team. Domain administrators invite and manage users, create teams and assign them to projects, where a Project Administrator manages membership and a Member creates and deletes devices.

Virtual device data is encrypted at rest with AES-256-CBC, with keys held by the main database and passed only temporarily to the compute node running a device, and remote access uses TLS 1.2 or later. Each virtual device runs on dedicated CPU cores, and on Enterprise each project gets an isolated network with its own VPN key. Any administrator access to a customer account is recorded for audit.

Cellebrite, which owns Corellium, holds ISO 27001:2022 and ISO 27017 certificates and a SOC 2 Type II report, all stated at company level. Its compliance page names no product scope for them and does not mention Corellium.

Sourcesupport.avh.corellium.com/authentication/sso/samlread 2026-10-08

The views Corellium offers show what the firmware did: the serial console, which can capture input, kernel and system logs, a network monitor of the device's traffic, and CoreXight, a code flow trace off the CPU core available to select customers. Those help an engineer see how the device behaved.

The one access record described is internal: administrator access to a customer account is logged for audit, with no customer view of that log. Corellium offers no customer facing record of which user, API key or agent created, changed or deleted a device.

Sourcesupport.avh.corellium.com/security/limited-accessread 2026-10-08

Virtual devices keep their own state between runs. A standard snapshot saves a device's storage and can be taken with the device powered off. A live snapshot also saves its RAM, so the device resumes with apps still running, while a device cloned from a live snapshot gets the filesystem but boots fresh. Each device holds up to five snapshots, including the initial one, and restoring a snapshot removes everything that changed after it.

On Business plans, once a domain administrator turns sharing on, users can share a snapshot by access code, with a password, across their domain or with invited users only, and recipients clone it into a project of their own. All of this is the device's saved state. Corellium keeps no memory of an agent's past work for it to read back.

Sourcesupport.avh.corellium.com/features/snapshotsread 2026-10-08

Customers choose where Corellium runs. Arm Virtual Hardware and the public cloud serve the API at app.avh.corellium.com, Enterprise Cloud gets its own subdomain, and an on premises appliance serves the same API from the customer's own hostname, with documented server roles for a site installation. Atlas is also offered through AWS Marketplace and as a private cloud deployment.

On Enterprise, each project's cores, devices and network are separated from every other project, so teams can share one installation without sharing a network.

Sourcesupport.avh.corellium.com/sdk/apis/restread 2026-10-08

A catalog of virtual boards comes ready to run, including Raspberry Pi 4 and 5, NXP i.MX8M Plus and i.MX93, STM32U5, NXP S32K, TI AM62P and Arm reference platforms, many with stock firmware, quickstart guides and examples such as a TF-M build, an HTTP client and audio detection on the STM32U5 or a safety island demo on an Arm automotive reference design. Microcontroller targets take firmware as a 32 bit ELF, a raw binary or a ZIP with a load map.

Shared snapshots, such as the i.MX93 PLC demo and a generic Linux sensor simulator, hand a working setup to another team, and the CHARM Developer Kit lets teams load device models of their own. These are environments to build in; no prebuilt agents or agent templates come with them.

Sourcesupport.avh.corellium.com/devicesread 2026-10-08

Virtual devices start when a person works in the web interface, or when a script, an agent or a pipeline calls the REST API or the CLI. The published GitHub Actions example runs on each push to the customer's repository: it installs the Corellium CLI, logs in with an API token, creates a device, waits for it to boot, works with it and deletes it. GitLab, Jenkins, CircleCI and Travis CI follow the same pattern.

In every case the event belongs to the customer's own CI service. Corellium has no scheduler, webhook or event listener of its own that starts a device.

Sourcesupport.avh.corellium.com/sdk/ci-cd/github-actionsread 2026-10-08

No model runs inside Corellium for the agent. Whatever drives it, Kiro in Cellebrite's walkthrough or any client calling the REST API or the MCP servers, brings its own model, so model choice happens in that tool rather than in Corellium.

Sourcecellebrite.com/en/blog/virtual-arm-hardware-firmware-development-corellium-atlasread 2026-10-08

Every deployment, cloud or on premises, exposes its own interactive API reference at /api/docs. Devices and projects are controlled through that REST API, authenticated with API keys generated in the administration settings, and Python, JavaScript and TypeScript clients, a C API and a CLI with commands for authentication, instances and projects build on it. Published examples cover bulk device setup and uploading firmware with the Python client, and a VS Code extension opens a console into a running device.

Cellebrite's Atlas walkthrough names two MCP servers: Corellium MCP for device lifecycle (create, start, stop, snapshot, share, inspect) and CoreModel MCP for driving SPI, GPIO, CAN, I2C and UART signals into a running device. The 7.12 release in August 2026 describes MCP integrations as a key investment, though no public endpoint or tool list has been published yet.

Sourcesupport.avh.corellium.com/sdk/apis/restread 2026-10-08

Teams run their own firmware on the virtual board and debug it with GDB, LLDB, kernel debugging and CoreSight trace. CoreModel lets a team write C test benches that drive peripheral signals into a running device, and Cellebrite's walkthrough shows CoreModel MCP injecting SPI, GPIO, CAN, I2C and UART stimulus so tests run as function calls.

The CI examples create, use and delete devices inside a pipeline, but none checks results or reports a pass or fail. Corellium offers no test format, scoring or release gate of its own; the checks a team writes live in its own pipeline.

Sourcesupport.avh.corellium.com/features/connect/coremodelread 2026-10-08

Agents drive Corellium through API and MCP calls that boot, snapshot and signal a virtual board. The device's console and display belong to the virtual hardware under test, which Corellium itself runs, and no browser or desktop is operated by the agent on someone else's software.

Sourcecellebrite.com/en/blog/virtual-arm-hardware-firmware-development-corellium-atlasread 2026-10-08