모델의 호출을 장치에 바로 보내지 않습니다
Dongxu Yang의 DCP 제안은 호스트 Bridge가 manifest와 capability를 확인하고, 작은 장치 프레임으로 바꾸는 구조입니다. v0.x의 장치는 Bridge를 신뢰하며 capability 검증을 직접 수행할 의무가 없습니다. 선택적인 프레임 HMAC를 쓴다고 해서 올바른 권한 설정이나 물리적 안전장치가 필요 없어지는 것도 아닙니다.
모델이 요청한 intent·매개변수
Bridge: 허용 범위 확인 후 프레임 구성
장치: 실행·응답 및 별도의 안전장치
제약을 선언했다고 코드가 실제로 그렇게 검사하는 것은 아닙니다
확인한 eca2649f 판본의 safety.py는 capability·알 수 없는 매개변수·범위·문자열 길이·패턴을 검사합니다. 다만 값의 형식을 엄격하게 거부하기만 하는 것이 아니라 float()·int()·bool()·str() 변환을 사용합니다. unit 표기만으로 잘못 해석한 단위나 안전하지 않은 물리 명령을 모두 탐지할 수는 없습니다.
범위 비교 전에 유한수를 명시적으로 확인하는 코드가 없다는 점도 읽을 수 있습니다. 따라서 이 구현을 모든 비정상 수치와 모든 프롬프트 주입을 막는 증명으로 소개하지 않습니다. 이 관찰은 소스 검토이며 장치 공격이나 재현 시험 결과가 아닙니다.
644바이트는 전체 RAM 사용량이 아닙니다
공개 측정 JSON은 빈 Arduino 스케치 대비 flash 28,267바이트와 정적 전역 영역 644바이트 증가를 기록합니다. 전체 lamp 스케치는 flash 295,007바이트와 전역 영역 22,712바이트입니다. 스택·힙·호스트 Python Bridge까지 포함한 전체 실행 메모리라고 쓰면 안 됩니다.
논문의 IoT-MCP 74KB는 보고된 최대 메모리이고 DCP 0.6KB는 정적 증가분입니다. 측정 범위가 달라 이 두 숫자만으로 전체 시스템이 100배 작다고 계산할 수 없습니다. 15.60ms와 15.59ms의 비교도 같은 ESP32-S3에서 호스트·장치 왕복을 잰 것이며 LLM 응답 시간 비교가 아닙니다.
675개 호출에서의 거부율입니다
고정 판본의 집계는 5개 모델이 낸 파싱 가능한 호출 675개를 대상으로 합니다. DCP의 capability-escalation 항목은 142/142, prompt-injection 항목은 125/160이 거부됐습니다. 호출을 내지 않은 응답은 분모에서 빠집니다. 이는 보편적인 공격 차단율이나 모든 요청의 안전성 보장이 아닙니다.
v1 PDF는 본문 138건, 그림 설명 50%와 295건 등 서로 맞지 않는 이전 수치를 남깁니다. 여기서는 집계 JSON의 분자·분모를 명시하며 불일치를 숨기지 않습니다. 또한 비교 코드의 MCP 쪽은 주로 형식만 제한한 스키마이고, DCP·OpenAPI 쪽에는 추가 범위·패턴·권한 제약이 있습니다. MCP 자체가 입력 검증을 지원하지 않는다는 결론은 나오지 않습니다.
논문 소개와 실기 검증을 구분합니다
이 글은 보존된 v1 PDF 15쪽의 텍스트와 그림 3·4·5, 고정 소스의 관련 부분을 대조한 기술 노트입니다. 실기 펌웨어, LLM API, 공격 표본을 실행하지 않았습니다. 예시의 작은 프레임은 모든 payload·전송 계층의 크기 상한이 아니며, 논문과 draft 규격을 표준 인증으로 취급하지 않습니다.