Dana Brings Agentic AI to Vehicles, Robots and Industry

Applied Intuition introduced Dana on July 22, 2026, describing an agentic platform for building, testing, deploying and operating physical AI in vehicles, robots and industrial machinery. It is intended to combine data, visualisation, developer tooling, evaluation, traceability and governance in one environment. The important shift is not the addition of chat to engineering: an agent may execute multi-step workflows across code, simulation and data, so it must be treated as a privileged infrastructure operator.

Product details in this article come from Applied Intuition’s Dana announcement. The phrase “first agentic platform for physical AI” is vendor positioning, not an independent comparison of the entire market. Likewise, claims that some phases fell from months to days reflect the company’s and selected deployments’ experience rather than a public benchmark of identical projects.

What is Applied Intuition Dana?

Dana is presented as a common layer for the physical-AI lifecycle: data preparation, software development, simulation testing, result analysis, deployment and operations. Users can issue requests through natural language or a command-line interface. The platform is also intended to integrate with work systems such as Slack and Jira so that agents can participate in existing issue and decision flows.

The vendor lists autonomous and software-defined vehicles, ADAS, fleet management, robotics, construction, mining and in-vehicle systems as application areas. This is broad, but the shared pattern is clear: software interprets physical-world data, builds or evaluates behaviour and may ultimately influence machine motion.

Applied Intuition says it has used Dana internally since last year. Komatsu and Isuzu are named as limited early-access customers, with Isuzu applying it to Level 4 autonomy work. Those statements confirm participation and intended use, not completed homologation, commercial availability of an autonomous vehicle or a published improvement in safety performance.

Why agentic workflows can change engineering speed

In a conventional process, an engineer selects logs, builds a scenario, starts a simulation, waits for results, compares metrics, opens an issue and prepares a change. An agent can connect those steps: find a regression, generate edge cases, launch a test series, classify failures and prepare a report linked to artefacts. The benefit comes from reducing delay between stages, not from replacing physics with generated text.

Compare this with an on-device world model such as NVIDIA Cosmos 3 Edge. A model may interpret vision and propose an action; an agentic platform organises data, tools and evaluation around multiple models. Dana is therefore not simply another vision-language-action model. It is an orchestration layer where security depends not only on prediction quality but on which tools an agent can invoke and which evidence it accepts as sufficient.

From natural language to physical consequences

A request such as “find cases where the vehicle brakes too late and prepare a fix” is convenient but leaves many implicit decisions. The agent must choose data, define “too late”, select scenarios and software versions, set a success metric and accept a trade-off. If it can change those values itself, an apparently strong result may not reduce real risk.

Every workflow therefore needs a machine-verifiable contract:

• an approved objective and named owner;
• identifiers for data, models, code and configuration;
• immutable entry and exit criteria;
• time and compute budgets;
• an allowlist of tools;
• mandatory human approval points;
• abort and rollback rules;
• a signed report with complete provenance.

An agent may prepare a change, but it should not redefine the safety criterion, approve its own test and release the result to a vehicle. Separation of duties becomes more important when one platform spans the whole lifecycle.

Three layers that must remain separate

A secure physical-AI architecture separates an experimentation layer, a release layer and an execution layer. Experimentation lets the agent generate code, modify scenarios and run simulation against synthetic data. Release verifies signatures, tests, compliance and approvals. The runtime on a vehicle or robot executes only an artefact promoted through that controlled process.

A Slack or Jira integration must not become a back door into deployment. A channel message is untrusted input: it can contain prompt injection, a malicious file link or instructions from a compromised account. A broker should verify sender and classify data before the agent reads it. Actions with durable consequences need strong approval outside the conversation itself.

Prompt injection in CI/CD agents demonstrates the same issue in software. The potential impact is broader in physical AI because a harmful change may travel from a repository to an executing device. Signed artefacts, pinned dependencies, two independent approvals and immediate rollback are essential.

Simulation is evidence, but not all evidence

An agentic platform can generate thousands of scenarios and discover conditions no engineer specified manually. That is useful, but the result depends on the simulator’s fidelity. Sensor faults, friction, lighting, bus latency, human behaviour and mechanical failures may be represented inaccurately. An agent optimising one benchmark may learn its simplifications rather than improve safety.

Validation should progress from software-in-the-loop to hardware-in-the-loop and controlled physical testing. Each phase has distinct criteria and an independent data set. A closed safety set used for final acceptance must not also become optimisation material. The OpenAI benchmark incident shows why test solutions must remain outside an agent’s reach.

Deterministic safeguards remain mandatory

A generative model should not be the only component deciding whether motion is safe. An independent safety controller must enforce limits for speed, workspace, force, temperature, distance and device state. Its code should be smaller, deterministic, amenable to formal or exhaustive testing and unaffected by agent instructions.

When Dana proposes an action or publishes an artefact, the runtime should check its signature, version, compatibility, policy and machine state. A breached envelope leads to a safe state: stop, degraded mode or operator takeover, depending on the system. “Human in the loop” is not sufficient if a person receives hundreds of decisions per second or lacks time to intervene.

Identity and permissions for a Dana agent

Every session should receive its own AI agent identity. Permissions to read data, start simulation, create an issue, modify code and prepare deployment must remain separate. A token must not inherit every right held by the user who posted a Slack message.

For example, policy may allow an agent to read de-identified logs from a selected fleet, create scenarios in a test project and open a pull request. It should not delete data, alter a closed evaluation set, approve the pull request or contact a vehicle directly. Production authority is issued only to the deployment controller after release gates pass.

Tokens need short lifetimes and audience binding. All activity should share a workflow identifier so AI agent observability can join the request to the dataset, model version, executed code and final artefact. The audit trail belongs in a system the agent cannot modify.

Physical-AI data governance

Vehicle and robot data may contain faces, number plates, speech, location, factory secrets, process parameters and employee information. A central platform simplifies analysis while increasing the target’s value. Classification, minimisation, processing-region controls, retention and project or tenant separation are required.

An agent should receive the result of an authorised query, not unrestricted access to a raw data lake. Views can remove identifiers, reduce resolution and restrict time windows. Exports need DLP. If an external model participates, the organisation must understand processing location, retention, training use and deletion mechanisms.

An AI model registry should connect each version to its model card, licence, training data, known limitations, tests, owner and approval status. For physical AI, that registry should also record compatible hardware, firmware and operational envelopes.

Threat modelling integrations and supply chain

Dana connects many systems, so both its value and risk emerge at integration points. Start an AI security architecture review with the data flow: vehicle, gateway, cloud, storage, agent, repository, CI, simulator, issue tracker and deployment. For every edge, record identity, encryption, replay potential, data schema and ownership.

Pay particular attention to plugins, packages, container images and models retrieved by agents. A software supply-chain attack can replace a tool the platform trusts. Require SBOMs, signatures, pinned digests, scanning and isolated builds. Models and datasets are supply-chain artefacts too, even when they do not look like traditional packages.

How to evaluate Dana before buying

A demo that turns one request into a fast report is not enough. Ask for deployment architecture, tenant boundaries, the responsibility model, subprocessors, data regions, RTO/RPO and incident procedures. Technical reviewers should get clear answers to these questions:

1. Can customers enforce zero public egress?
2. How does an agent acquire and lose permissions?
3. Is the audit log immutable and exportable?
4. How are prompts, models, data and tools versioned?
5. Which actions always require human approval?
6. Can a workflow be reproduced deterministically?
7. How are untrusted data and code isolated?
8. How are artefacts signed and promoted?
9. How do emergency stop and rollback work?
10. Which penetration tests and assurance reports are available?

A proof of concept should use your own negative scenarios. Introduce prompt injection through an issue, a malformed dataset, an unavailable simulator, a misleading metric and an attempted privilege escalation. Verify not just that the model says no, but that technical policy blocks the operation and produces useful evidence.

What Dana signals for the market

Agentic platforms move generative AI from advice into the execution of engineering work. Dana shows that this direction now encompasses vehicles, robots and heavy machinery. If the claimed cycle-time reductions hold across broader deployments, the advantage will come from a shorter path between data and a verified artefact. Independent safety gates are the condition for making that speed sustainable.

Organisations do not need to choose between speed and control. They need a process where an agent automates repeatable work but cannot increase its own privileges, redefine a safety threshold or release its own result. Considering physical AI or an AI security audit? Contact BreachRoad before an agent is connected to a system capable of affecting the physical world.

Sources

• Applied Intuition: Dana, the agentic platform for physical AI