Ratify Edge Physical AI

Robots, farm equipment, instruments, and edge devices need to decide whether an action is authorized at the point where it has consequences. Network identity and agent-framework permissions are useful controls, but they do not by themselves express which principal approved this exact action, resource, duration, and time window.

This matters when an agent can call a tool but must not have unlimited authority: agricultural equipment, warehouse robots, drones, laboratory instruments, charging systems, and other edge-controlled devices. Ratify complements IAM, OAuth, MCP, A2A, and local policy; it does not replace them.

The example delegation authorizes a bounded farm action:

scope       physical:actuate
zone        greenhouse-b
resource    irrigation-valve-3
duration    20 seconds maximum
expiry      signed delegation expiry

The current hardware maps that valve action to a short LED command over USB serial. No hazardous device is connected.

The Linux receiver is the enforcement boundary. The agent, model, transport, and Arduino cannot turn a denied receiver decision into an authorized decision inside this reference.

The Arduino is an actuator, not the authorization boundary. It does not verify proofs, hold keys, enforce local policy, or provide trusted time. Direct access to the Arduino is outside this reference's security boundary.

The deterministic gate runs the 16-row protocol matrix and observes the protected effect:

The local gate result is 25 passed, 0 failed, 0 skipped. The final Pi 2 ARMv7 serial integration run for this five-input context implementation also passed: two authorized invocations, monitor authorization without actuation, and replay denial. This is evidence of the receiver-to-actuator path, not a claim that the Arduino verifies authorization.

The deterministic controller above is the default because a gate should not depend on a model behaving. The Google ADK path exists to show the same boundary holding when a real agent framework drives it, and the adapter in ../../adk/edge_agent.py is a real ADK FunctionTool rather than a stand-in.

Four layers, and it is worth being precise about which one decides:

The model is not a security boundary here, and nothing depends on it choosing well. A model that asks for the wrong zone, too long a duration, or an action outside the delegation gets the same denial as an attacker would: the receiver never reaches the actuator. That is the point of running the framework path at all.

Setup is in ../../adk/README.md: the pinned environment, the receiver address, and how the authority fixture is issued. The adapter needs the receiver running first, because it asks it for a challenge before it can sign anything.

Use this open reference when you need inspectable source, a deterministic local gate, and a safe demonstration of the verification boundary. Use Ratify Verify when you need managed trust configuration, revocation operations, audit retention, observability, availability, and supported deployment adapters.