The Physics Sandbox:
Grounding Agentic AI in Executable Reality

Why agents need a physics oracle

Large language models reason by predicting plausible text. Engineering decisions, however, are judged by physics — and plausibility is not correctness. A torque ripple estimate, a thermal derating threshold, or a fault signature can sound right while being quantitatively wrong.

The physics sandbox closes this gap by giving the agent a verification oracle: a simulation backend it can call as a tool. Instead of asserting "reducing the cooling flow 20% keeps winding temperature within limits," the agent proposes the hypothesis, runs the experiment, reads a structured verdict, and only then commits to a decision. The pattern echoes what made search-plus-evaluation systems like AlphaGo effective: cheap, trustworthy rollouts of candidate ideas [10], and what NVIDIA's Eureka demonstrated for LLMs specifically — language-model proposals scored inside a physics simulator outperformed human-engineered designs [9].

The loop is deliberately simple:

For Vehicle Health Management this is unusually well-matched: diagnosis is hypothesis testing. "Is this current signature consistent with bearing wear or with a winding short?" is a question a plant model with fault injection can answer in seconds — long before a test cell is booked.

Three layers, one protocol

The Model Context Protocol (MCP) [1] is the natural seam: the agent (VS Code Copilot, Claude Code, or any MCP client) sees a small vocabulary of experiment-level tools; the MCP server translates them into solver-level operations; the backends do physics. The agent never touches a solver API directly.

Copilot ↔ MCP server ↔ MATLAB/Simscape

Figure 2 makes the abstraction concrete: one complete experiment, message by message, between the agentic framework inside VS Code Copilot, the sandbox MCP server (a Python process speaking JSON-RPC over stdio), and a persistent MATLAB Engine session running a Simscape harness model. Step through it — each hop shows the actual payload that crosses that boundary, which is exactly what you would show an audience to make the idea tangible.

// payloads appear here, hop by hop

Tiered fidelity: explore cheap, verify expensive

Agents iterate fast; high-fidelity solvers do not. A single CFD or stiff electro-thermal run can cost minutes to hours, while an agent's inner loop wants hundreds of evaluations. The resolution is a fidelity ladder: reduced-order and FMU surrogates for exploration, full-fidelity runs reserved for the shortlisted candidates — the same pattern as a neural-network flux-map surrogate standing in for FEA during calibration.

A minimal server you could run on Monday

Everything in Figures 1–2 reduces to surprisingly little code. Listing 1 is a working skeleton of the sandbox MCP server — FastMCP for the protocol, the MATLAB Engine API for the physics seam, a budget governor, and provenance hashing. Listing 2 is the one file that makes it appear inside VS Code Copilot as native tooling.

# sandbox_server.py — reference skeleton (FastMCP + MATLAB Engine API)
import json, time, hashlib
import matlab.engine
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("physics-sandbox")

# --- persistent session: pay MATLAB startup once, at server boot ---
eng = matlab.engine.start_matlab()
eng.load_system("pmsm_thermal_hrn", nargout=0)
eng.set_param("pmsm_thermal_hrn", "FastRestart", "on", nargout=0)

# --- curated model registry: agents configure, never construct ---
REGISTRY = {
    "pmsm_thermal": {
        "harness": "pmsm_thermal_hrn",
        "rev": "a41f9c",
        "constraints": {"T_ss_C": 140.0},
    }
}
BUDGET = {"tier1": 2000, "tier2": 50, "tier3": 4}   # the governor

def _provenance(spec, args):
    blob = json.dumps({"rev": spec["rev"], "args": args}, sort_keys=True)
    return hashlib.sha256(blob.encode()).hexdigest()[:12]

@mcp.tool()
def run_experiment(model: str, I_amps: float, cooling_health: float,
                   fidelity: str = "tier2", max_runtime_s: float = 60.0) -> str:
    """Run one thermal experiment. Returns steady-state temperature,
    constraint margin, PASS/FAIL verdict, runtime, and provenance hash."""
    spec = REGISTRY[model]
    if BUDGET[fidelity] <= 0:
        return json.dumps({"error": "budget_exhausted", "tier": fidelity})
    BUDGET[fidelity] -= 1

    t0 = time.time()
    eng.workspace["I_phase"] = float(I_amps)         # typed inputs only —
    eng.workspace["h_cool"]  = float(cooling_health) # never model-written code
    eng.eval("out = sim('pmsm_thermal_hrn');", nargout=0)
    T_ss = eng.eval("out.logsout.get('T_wind').Values.Data(end);")

    limit  = spec["constraints"]["T_ss_C"]
    margin = limit - T_ss
    return json.dumps({                              # verdicts, not waveforms
        "T_ss_C": round(T_ss, 1), "limit_C": limit,
        "margin_C": round(margin, 1),
        "verdict": "PASS" if margin >= 0 else "FAIL",
        "runtime_s": round(time.time() - t0, 1),
        "provenance": _provenance(spec, [I_amps, cooling_health]),
    })

@mcp.tool()
def inject_fault(model: str, fault: str, severity: float, t_onset_s: float) -> str:
    """Arm a fault (winding_resistance | cooling_blockage | sensor_bias)
    for the next run; returns the armed configuration."""
    ...  # maps to a fault subsystem + variant control in the harness

if __name__ == "__main__":
    mcp.run()   # stdio transport — VS Code launches and owns this process

{
  "servers": {
    "physics-sandbox": {
      "type": "stdio",
      "command": "python",
      "args": ["sandbox_server.py"]
    }
  }
}

A working sandbox, in your browser

Below is a miniature but honest version of the whole idea. The plant is a single-node motor thermal model with temperature-dependent winding resistance — solved by RK4, right here in the page:

C·dT/dt = I²·R₀·(1+α(T−20)) − (T−T_amb)/R_th(h)

The health parameter h degrades the cooling path (clogged channel, failing pump). The engineering question — a real VHM-flavored one — is: given this cooling health, what is the maximum continuous current that keeps the winding below 140 °C? You can experiment manually, or hand the controls to a toy agent that runs a bisection search using only the sandbox's verdicts.

The single-run loop above generalizes to the sandbox’s most valuable verb: run_doe. Figure 5 maps the entire derating envelope over the (current × cooling-health) plane — and contrasts two strategies an agent could choose: brute-force the grid on Tier-1 surrogates, or hunt the pass/fail boundary directly and spend an order of magnitude fewer runs.

Diagnosis as physics-refereed hypothesis testing

Everything so far ran the model forward: parameters in, behavior out. Diagnosis is the inverse problem — behavior observed, cause unknown — and it is where the sandbox earns its keep for VHM. The agent’s move is abduction: enumerate candidate faults, simulate each, and rank them by how well they reproduce the field signature.

Figure 6 stages the full exercise. Generate a field signature secretly draws one of four ground truths — healthy, cooling degradation, winding resistance growth, or temperature-sensor bias — with random severity and measurement noise. Run agent diagnosis then sweeps each fault family through the sandbox, fits severity by residual, and commits to a diagnosis. Only then is the truth revealed.

Patterns and anti-patterns

Three decisions dominate whether the sandbox produces insight or noise.

1 · Curated model library, not freeform model building

Programmatic diagram construction (add_block/add_line) is brittle, and an agent will burn its budget on connection errors. Instead, engineers curate parameterized template models — PMSM drive, battery pack, gear train, thermal network — and the agent configures, swaps components, and injects faults. The search space stays physically meaningful by construction.

2 · Verdicts, not waveforms

LLMs are good at proposing experiments and unreliable at honestly reading raw traces — they will confabulate trends in noisy data. Post-process inside the server: return steady-state values, constraint margins, rise times, FFT peak tables, and an explicit pass/fail per requirement. Raw signals stay available behind a separate tool for when the agent genuinely needs them.

3 · Fault injection as a first-class tool

For diagnostics work, the killer primitive is inject_fault(model, fault_type, severity, t_onset) — winding resistance step, bearing friction ramp, sensor bias, coolant blockage. It turns the sandbox into a hypothesis tester for diagnosis ("which fault best explains this signature?") and a data factory for training and validating detection algorithms before any test-cell time.

Choosing the physics engines

No single tool spans the ladder. The practical strategy is one authoring environment you trust, with FMU export as the universal currency — models authored anywhere, executed license-free in the agent's inner loop, escalated to the source tool only for verification.

Practical notes before you build

Licensing under concurrency

A single MATLAB Engine session serializes runs; Parallel Computing Toolbox workers each draw licenses from the corporate server. Before designing for agent fan-out, measure what the license pool tolerates — or route the inner loop through exported FMUs and keep MATLAB for authoring and verification only.

Latency budgets are part of the prompt

Expose max_runtime on every tool and return partial results with a budget_exceeded flag rather than hanging the agent. Stiff electro-thermal models benefit from local solvers and fixed-step configurations in the exploratory loop; reserve variable-step accuracy for verification.

Determinism and provenance

Hash the model version, parameter set, and solver settings into every result. Agent-driven experimentation produces hundreds of runs per session; without provenance you cannot reproduce the one that mattered. Treat the experiment log like a lab notebook, because legally and organizationally, it is one.

Guard the interpretation boundary

The most common failure is not a wrong simulation — it's a right simulation read wrongly. Keep numeric judgment (margins, statistics, trend tests) inside the server, and have the agent justify decisions by citing returned verdicts. If a conclusion in the agent's prose has no corresponding verdict in the log, that's a red flag the review process should catch automatically.

Security posture: the server is an execution surface

An MCP server that executes solver commands is an arbitrary-execution surface — the engineering-simulation cousin of handing an agent a shell. Whitelist tool actions, run backends in containers or on dedicated machines, and never let a model-generated string reach a shell or a MATLAB eval. Standard agentic-AI security guidance applies with extra force when the backend can drive licensed engineering infrastructure [11], [13].

Keep the warden outside the cell. The budget governor, model registry, and provenance log are the harness — and the harness must not share an execution context with the code that runs model-influenced experiments. If the process that enforces the Tier-3 gate and writes the audit trail is the same process a compromised run can reach, that run can quietly rewrite its own evidence. The governor passes typed inputs in and reads verdicts and exit codes back out; it never executes inside the sandbox it polices.

Match isolation to what actually runs. The physics complicates the generic sandboxing story, so split the backend in two. Tier-1 surrogates are ordinary code and belong in strong, cheap isolation: a parse-time-restricted interpreter, a Rust micro-interpreter such as Monty that denies filesystem, environment, and network access by default, a Wasm runtime, or a per-call microVM — Firecracker boots in roughly 150 ms and is the production standard for hosted coding agents [14]. Heavyweight licensed solvers cannot spin up per call, so they are isolated at the host or VM boundary and protected by the discipline this monograph already insists on: configure, never construct, and no model-generated string ever reaches eval or a shell.

Network egress is the overlooked surface. Allowlist, do not blocklist. The solver loop rarely needs the open internet, so pin outbound traffic to the package indices, your model registry, and the license server, and deny everything else by default — far more defensible than chasing malicious domains. In a cloud deployment, block the instance-metadata endpoint at 169.254.169.254 and require token-authenticated IMDSv2, or a prompt-injected agent can mint cloud IAM credentials through an SSRF and walk straight out of the sandbox [13].

Bound the blast radius. The budget governor already counts runs for cost; extend it to cap resources for safety. Set conservative memory and CPU ceilings, a process limit to stop fork bombs, and a disk quota on the mounted workspace, and wrap every backend call in a hard timeout that returns a budget_exceeded flag rather than hanging the agent. The same governor that makes the economics visible can make the blast radius finite.

Gate the irreversible by hand. Some actions should never proceed on sandbox isolation alone — writing to the shared model registry, pushing results into a PLM system or database, installing a new solver toolbox, or any run that consumes scarce Tier-3 licenses. Intercept them at the server with the same human-approval hook the Tier-3 sign-off already uses, so a person confirms before the backend ever sees the command; the agent simply receives a result or a timeout, and never learns the gate exists.

Where this bites in VHM

Diagnostic hypothesis testing. Given a field signature, the agent enumerates candidate faults, injects each into the plant model, and ranks them by residual fit — abductive reasoning with a physics referee.

Prognostic feature vetting. Before a feature ships in a health indicator, the agent sweeps degradation severities in simulation and reports whether the feature actually separates failure modes across the operating envelope — the demo in Fig. 4 is the embryo of exactly this study.

Recall scope and what-if analysis. "If this supplier lot has +8% winding resistance, which drive cycles violate thermal limits?" is a DOE the sandbox answers in hours, shrinking scope decisions that otherwise lean on conservatism.

Synthetic fault data. Labeled fault trajectories on demand, for training detectors where field failures are rare — with the fidelity ladder controlling the sim-to-real gap.

A roadmap that fits in three quarters

Risks, named early

Limitations and failure modes

The verdict inherits the model’s trust, never exceeds it. A sandbox cannot validate physics it doesn’t contain: unmodeled aging mechanisms, manufacturing spread, or coupling left out of the harness will be invisible to every experiment. Each registry entry should carry an explicit validity envelope and validation provenance, and the server should refuse — or loudly flag — experiments outside it.

Surrogates drift from their parents. Tier-1 FMUs and reduced-order models disagree with Tier-2/3 somewhere; the question is where. Cross-check a sampled fraction of Tier-1 verdicts at higher fidelity automatically, and treat growing disagreement as a maintenance signal for the surrogate, not noise [12].

Agents will overfit the sandbox if allowed. Given an open parameter space, an optimizing agent finds solver tolerances, unphysical corners, and constraint loopholes — the simulation cousin of reward hacking. Bound every input schema to physical envelopes, randomize nuisance parameters across verification runs, and make “exploits a modeling artifact” an explicit failure category in review.

Automation bias is the human-side failure. A fluent agent quoting numeric verdicts is persuasive even when the underlying model is stale. The audit log helps only if someone reads it; build the review habit in Phase 0, while the stakes are still low.

References & further reading

1. Model Context Protocol — specification and SDKs. modelcontextprotocol.io
2. FMI Standard 3.0 — Functional Mock-up Interface for model exchange and co-simulation. fmi-standard.org
3. FMPy — Python library for simulating FMUs. github.com/CATIA-Systems/FMPy
4. MathWorks — MATLAB Engine API for Python; Simscape documentation and FMU export. mathworks.com/help
5. OpenModelica & OMPython — open-source Modelica environment and Python interface. openmodelica.org
6. PyAnsys — open-source Python ecosystem for Ansys products. docs.pyansys.com
7. Gamma Technologies — GT-SUITE system simulation and automation interfaces. gtisoft.com
8. MuJoCo (Google DeepMind) and Drake (TRI) — fast physics and optimization-centric multibody dynamics. mujoco.org · drake.mit.edu
9. Ma, Y. et al., "Eureka: Human-Level Reward Design via Coding Large Language Models," 2023. LLM proposals evaluated inside a GPU physics simulator. arXiv:2310.12931
10. Silver, D. et al., "Mastering the game of Go with deep neural networks and tree search," Nature, 2016 — the search-plus-evaluation precedent. doi:10.1038/nature16961
11. Yao, S. et al., "ReAct: Synergizing Reasoning and Acting in Language Models," 2022; and OWASP guidance on LLM application security. arXiv:2210.03629 · owasp.org
12. Wang, G. et al., "Voyager: An Open-Ended Embodied Agent with Large Language Models," 2023 — agent skill acquisition inside a simulated world. arXiv:2305.16291
13. Allahyari, M., "Secure Playgrounds: Sandboxing & Execution Security in Harness Engineering," The MLnotes Newsletter, 2026 — the warden/cell principle, egress allowlisting, and metadata-endpoint hardening adapted here to a solver backend. mlnotes.substack.com
14. Sandboxing runtimes for agent-generated code: E2B / Firecracker microVMs, gVisor (user-space syscall interception), Pyodide (Python-to-Wasm), Monty (Pydantic's Rust interpreter), and RestrictedPython. e2b.dev · gvisor.dev · pyodide.org · github.com/pydantic/monty
15. Rehberger, J., "ZombAIs" — prompt injection through browsed content compromising an AI computer-use agent into running a C2 framework, 2024. embracethered.com