NeuraOS: gateway lab evidence and the device gates ahead

The NeuraOS public record describes an R80–R85 agent-gateway reference that accepted signed TLS 1.3 MCP requests as a Linux systemd service and in an ARM64 Docker/Compose path. Two isolated QEMU builders produced a byte-identical ARM64 image. The same image passed Compose restart, non-root isolation and tampered-registry denial checks in an ARM64 QEMU guest. These are repeatable loopback laboratory results, not a physical-device or fleet acceptance.

R87–R88 adds an image-specific software bill of materials and a dated vulnerability scan. A cryptography dependency fix was reproduced in two ARM64 QEMU builders and passed the signed TLS/Compose flow. The record still lists unresolved Python and zlib findings. A smaller scan count is useful evidence of one fix, but it is not security clearance for production.

The gateway work strengthens a software boundary around approved tool requests. In the wider host reference, mission admission checks scope and capability, durable intent prevents changed replayed commands, and signed outcomes attach evidence to the task record. A proposed device action can therefore be reviewed against the approved mission instead of treated as an unqualified instruction.

That software path still stops short of physical control. A real controller must prove its own boot, peripheral ownership, transport behaviour, safe state after interruption and independent observation of completion. Recent device-intake discussions are being turned into a candidate acceptance matrix, but no board, firmware or robot model has been qualified by this lab record.

The public release record marks seven of seventeen production gates satisfied, ten pending and nine field-readiness blockers open. Its production authorization flag is false, and physical operation remains NO-GO. Target qualification, production security disposition, protected keys, independent failure domains and operational approval need their own evidence before a site can accept a release.

The next useful result is a device-specific bench plan and a reviewable outcome on one exact target. The lead image is a conceptual edge-device scene, while the accompanying R75 console capture documents an actual unbound local reference workspace. Neither shows gateway traffic, qualified hardware or a customer deployment.