01 / ABSTRACT
Machines can act. They still need a common way to prove they were allowed.
Physical-AI systems cross boundaries between people, spaces, devices, and organizations. KineGrant connects existing identity, policy, device, and robotics systems at one decisive point: immediately before a physical action.
02 / CORE OBJECTS
Five objects, one enforceable path.
ActionRequest
A normalized request binding an authenticated agent to a target, action, purpose, time, and policy-visible context.
PolicyRule
An allow or deny rule with issuer, scope, constraints, and obligations. Unknown policy never becomes permission.
Decision
The deterministic result of evaluating a request against all applicable policy with deny-overrides semantics.
Capability
A short-lived Ed25519-signed permission bound to the request and policy digests, with a random one-time nonce.
Receipt
A signed, privacy-minimized record of the attempted outcome, optionally chained to the previous receipt.
03 / DECISION SEMANTICS
Safe, deterministic, deliberately conservative.
An implementation rejects a request when no applicable allow exists, when any applicable deny exists, or when a required constraint cannot be interpreted.
- 01
Normalize and validate the action request.
- 02
Resolve authenticated policy sources and trusted issuers.
- 03
Collect every applicable allow and deny rule.
- 04
Apply deny-overrides and default-deny semantics.
- 05
Issue a short-lived capability only after an allowed decision.
- 06
Verify signature, scope, expiry, and nonce locally at the actuator gate.
- 07
Consume the capability once and emit a signed receipt.
04 / SECURITY MODEL
A signature is necessary. It is not physical truth.
Draft 0.1 uses Ed25519 signatures, authenticated policy issuers, trusted-clock request freshness, request binding, one-to-300-second capability lifetimes, and atomic one-time replay protection. Implementation v0.1.1 includes a crash-persistent SQLite replay store; production deployments still require hardware-backed keys, local revocation, and an independent functional-safety controller.
05 / INTEROPERABILITY
Standards remain authoritative at their boundaries.
Native platform authorization AND a valid KineGrant capability AND the local safety controller must all allow. Any layer may veto; no layer may force another to permit.
06 / STATUS AND PARTICIPATION
Review the threat model before the marketing.
KGP-001 is an experimental open draft, not a recognized standard or safety certification. The reference implementation is designed to make the semantics testable and challengeable.
PDF SHA-256802665df4d4221299a53e081f120e402987675a3efc7fb3574d517d8484078f3
ZIP SHA-25663d7bf7d9a101ca018054642f88e639a12ffc0bdd8cf9cdb021278ab3f78f4db