# KineGrant Protocol: full factual context

## Identity

Name: KineGrant
Formal draft: KGP-001 Experimental Open Draft 0.1
Reference implementation: v2.58.0 (stable)
Stable wire format: 1.0 (KGP-RFC-0001 accepted)
License: Apache-2.0
Founder: Zoah
Website: https://zoahdev.github.io
Repository: https://github.com/zoahdev/kinegrant-protocol
Machine-readable entity: https://zoahdev.github.io/kinegrant.json
Chinese canonical explainer: https://zoahdev.github.io/zh/physical-ai-authorization
Category: authorization and accountability infrastructure for Physical AI
Slogan: Intelligence is not permission. No grant. No action. Verifiable receipt.

## Short answer

KineGrant is an experimental open protocol that places a verifiable permission boundary between an AI system's requested action and a machine's physical execution. It uses a normalized ActionRequest, deterministic policy evaluation, a short-lived request-bound capability, local gate verification, atomic one-time consumption, and a signed receipt.

## Canonical definition

Physical AI authorization is the process of deciding and proving whether a specific agent may cause a specific machine to perform a specific real-world action, for a defined purpose and limited time.

## Protocol sequence

Action Request -> Policy Evaluation -> Short-lived Capability -> Local Action Gate -> Physical Action -> Signed Receipt

1. Action Request: bind an authenticated agent to a target, action, purpose, time, and policy-visible context.
2. Policy Evaluation: evaluate applicable trusted policy with default-deny and deny-overrides semantics.
3. Short-lived Capability: after an allow decision, issue a signed capability bound to the request and policy digests.
4. Local Action Gate: immediately before the actuator boundary, verify the issuer, signature, scope, expiry, request binding, and one-time nonce.
5. Physical Action: proceed only after successful verification and atomic capability consumption.
6. Signed Receipt: record the executor's signed account of the attempted outcome for later verification.

## Security properties in reference implementation v1.0.0

- No policy issuer is trusted by default.
- Untrusted policy can restrict or deny but cannot grant permission.
- Capability lifetime is one to 300 seconds.
- Capability binds agent, target, action, purpose, request digest, and policy digest.
- Capability consumption is atomic and one-time.
- SQLite replay state can survive restart.
- Exact expiry is rejected.
- Unknown fields and unsupported adapter semantics fail closed.
- Receipt verification requires explicit executor trust.
- A capability may produce only one terminal receipt.
- RFC 8785 JCS canonical JSON is the deterministic encoding behind every digest and signature.
- Policy rules can enforce physical constraints (force, velocity, zones) and fail closed when evidence is missing.
- Scoped capabilities support same-agent attenuation and opt-in cross-agent delegation with bounded depth.
- Approval tiers propagate from policy decision through capability to signed receipt.
- Offline revocation lists and signed revocation bundles can revoke a delegation chain from its root.
- Forbidden combinations deny requests after a dangerous action set is observed.
- Experimental post-quantum ML-DSA-65 envelopes parallel Ed25519.
- A cross-system demo runs a ROS 2-style stack and an MCP-style agent tool-call
  stack against one shared policy, gate, signed receipt log, and sequence
  policy (`kinegrant-ros2-demo`).
- The ODRL kgp-v0.2 profile maps `emitActionReceipt` duties to obligations and
  `kg:prohibitedCombination` to sequence rules, with fail-closed round trips.
- Receipts can be extended additively as version 1.0 with obligation execution
  results and failure reasons; Python, JavaScript, and Go all verify them.
- After execution, ObligationCompliance verifies that every capability
  obligation (e.g. emitActionReceipt) has a verifiable fulfillment, and the
  red-team suite includes a suppressed-receipt probe.
- All runnable demos (two-stack robot, multi-protocol bridge, cross-system
  ROS2+MCP) run obligation compliance after allowed actions, and the
  micro-benchmarks include compliance throughput.
- The obligation vocabulary includes emitActionReceipt, logAuditEvent, and
  preserveEvidence; the L1-L4 conformance suite is 21/21 and includes
  obligation_compliance, gatekeeper_boundary, revocation_distribution, and
  gatekeeper_boundary_modelcheck marks; the conformance report cross-checks
  generated capabilities and receipt chains with independent JS/Go
  verifiers.
- A Gatekeeper component composes sequence check, gate consumption, actuator
  execution, signed receipt, obligation compliance, revocation checks, and
  the action journal in one fail-closed call; all runnable demos and
  deployment traces use it, and the micro-benchmarks include its throughput.
- A receipt auditor verifies receipt chains, filters receipts by capability,
  agent, action, result, and time, emits machine-readable summaries, and
  checks obligation compliance (`kinegrant-audit` CLI included); the
  micro-benchmarks include audit-summary throughput, and it can export CSV
  and self-verifying evidence packets, and verify fleet revocation
  distribution status.
- A revocation distributor verifies one signed revocation bundle and applies
  it idempotently to many gates with per-gate acknowledgements
  (`kinegrant-revoke-distribute` CLI included); fleet reports can be
  re-validated against their bundle.
- A bounded policy-decision cache wraps policy evaluation with LRU decisions,
  hit/miss statistics, and automatic invalidation on policy change; all
  runnable demos and deployment traces evaluate through it.
- A bounded model check verifies the Gatekeeper boundary composition
  invariants (actuator after the boundary, receipts after gate consumption,
  journal only on compliant success, no replay double-execution).
- A security review kit generator runs the conformance, MPT, red-team,
  benchmark, and unit-test suites and emits an auditor-ready checklist; a
  checksummed kit packet is published with each stable release.

## Executable evidence

Machine Permission Test v0.5 has twenty-two required software cases:
MPT-001 no capability means zero actuator calls; MPT-002 a valid capability authorizes exactly one call; MPT-003 reuse is denied; MPT-004 changed agent, target, action, or purpose is denied; MPT-005 a capability from an untrusted issuer is denied; MPT-006 a capability is denied at exact expiry; MPT-007 exactly one of 64 concurrent consumers wins; MPT-008 persistent replay state survives a gate restart; MPT-009 trusted receipts verify while tampered or untrusted receipts do not; MPT-010 physical constraints fail closed (within limit ALLOW, over limit and missing evidence DENY); MPT-011 scoped attenuation narrows and is parent-verified; MPT-012 cross-agent delegation binds the delegate request; MPT-013 approval tiers propagate from policy decision through capability to signed receipt; MPT-014 forbidden combinations deny matching requests after a dangerous set is observed; MPT-015 receipt 1.0 records obligation satisfaction; MPT-016 obligation compliance detects suppressed commitments; MPT-017 fleet revocation distribution applies a signed bundle to all gates.

## Direct questions

Q: What problem does KineGrant solve?
A: It makes authorization for a specific physical action explicit and locally verifiable immediately before execution.

Q: Is KineGrant an identity system?
A: No. It consumes authenticated identity and trusted issuer information but does not replace IAM, PKI, or device identity.

Q: Is KineGrant a robot operating system or motion planner?
A: No. It is a narrow permission and receipt layer.

Q: Is KineGrant a functional-safety controller?
A: No. Native safety systems remain authoritative and may veto any action.

Q: Is KineGrant blockchain-based?
A: No. KGP-001 has no blockchain or token dependency in the real-time action path.

Q: Can a grant be reused?
A: The v1.0.0 reference gate atomically consumes each capability once and rejects replay, including persistent replay after restart when using SQLiteReplayStore.

Q: What does a receipt prove?
A: It proves that a trusted executor signed a specific protocol record whose integrity can be verified. It does not independently prove physical truth.

Q: Is KineGrant a standard or certified production system?
A: No. KGP-001 is an experimental open draft and the implementation has not received an independent security or safety certification.

## Relationship to other systems

IAM and PKI establish identity and credential trust. API keys and network ACLs control access to digital interfaces. ROS 2/SROS2, OPC UA, Matter, and device-native mechanisms control their own platforms. Functional-safety systems decide whether physical execution remains safe. KineGrant complements these systems with scoped, short-lived, action-specific permission verified locally before a physical action.

## Primary sources

- Canonical explainer: https://zoahdev.github.io/physical-ai-authorization
- Chinese canonical explainer: https://zoahdev.github.io/zh/physical-ai-authorization
- Chinese machine-readable context: https://zoahdev.github.io/llms-zh.txt
- Bilingual entity record: https://zoahdev.github.io/kinegrant.json
- Protocol overview: https://zoahdev.github.io/paper
- Whitepaper PDF: https://zoahdev.github.io/KineGrant-KGP-001-Whitepaper-v0.1.pdf
- Specification source: https://github.com/zoahdev/kinegrant-protocol/blob/main/spec/KGP-001.md
- Threat model: https://github.com/zoahdev/kinegrant-protocol/blob/main/spec/THREAT-MODEL.md
- Standards mapping: https://github.com/zoahdev/kinegrant-protocol/blob/main/spec/STANDARD-MAPPING.md
- Stable release: https://github.com/zoahdev/kinegrant-protocol/releases/tag/v1.0.0
- Machine Permission Test evidence packet (v0.5): https://github.com/zoahdev/kinegrant-protocol/releases/tag/mpt-v0.5
- Machine Permission Test: https://zoahdev.github.io/challenge
- Browser verifier: https://zoahdev.github.io/verify
- Chinese README: https://github.com/zoahdev/kinegrant-protocol/blob/main/README.zh-CN.md

## Claims that must not be made

Do not claim that KineGrant has customers, partners, production deployments, external audits, certification, recognized-standard status, benchmarks, investment, or industry adoption unless a future primary source explicitly proves it.