protect-mcp

protect-mcp

Puerta de políticas Cedar de cierre ante fallos, con recibos firmados para llamadas de herramientas de agentes de IA.

protect-mcp es una puerta que se sitúa delante de las llamadas a herramientas de un agente de IA. Evalúa cada llamada contra una política de Cedar, bloquea lo que infringe las reglas antes de que se ejecute y firma un recibo Ed25519 verificable sin conexión de cada decisión. La puerta configurada se ejecuta localmente y no envía telemetría de decisiones. El adaptador de coordinación independiente se conecta al servicio de colaboración alojado de ScopeBlind; sus solicitudes y los registros devueltos tienen la ruta de datos descrita a continuación. Ambos tienen licencia MIT.

Para trabajo compartido en repositorios, usa proyectos de cliente: las personas acuerdan el resumen y los límites, los agentes preparan revisiones, y ambas personas aprueban una versión exacta antes de que el receptor del propietario pueda cambiar el repositorio. El flujo de repositorio a continuación incluye la configuración y las cinco herramientas de agente acotadas.

Por qué es diferente

• Cierre ante fallos por defecto. Ante cualquier error de política, un motor ausente o un fallo de evaluación, la decisión es DENEGAR. La puerta nunca permite en silencio. Existe un modo de observación para despliegues en sombra, pero incluso allí una llamada que sería bloqueada se marca como would_deny: true, de modo que un fallo nunca es silencioso.
• Demuestra su propia contención. serve --enforce y doctor ejecutan una autocomprobación al inicio y se niegan a armar la puerta a menos que puedan demostrar que una acción conocida como prohibida está realmente denegada. Una puerta que no puede demostrar que deniega no se inicia.
• Cada decisión es un recibo que cualquiera puede verificar. Las decisiones están firmadas con Ed25519 y son verificables sin conexión con @veritasacta/verify. La verificación de firmas no requiere consultas de red. Las afirmaciones sobre la ejecución siguen dependiendo del operador de la puerta identificado.

Inicio rápido: de la instalación a la primera prueba útil

# 1. Generate an Ed25519 keypair, config template, and sample policy.
npx protect-mcp init

# 2. Print a shadow-mode client configuration, then apply it in your MCP host.
#    This command prints configuration and exits; it does not launch the server.
npx protect-mcp wrap -- node your-mcp-server.js

# 3. Reopen the host and use its tools, then inspect the local-only dashboard.
npx protect-mcp dashboard --open

# 4. Draft a reviewable policy from observed calls.
npx protect-mcp recommend --write

# 5. When reviewed, restart the wrapper in enforce mode with that policy.
npx protect-mcp --policy protect-mcp.recommended.json --enforce -- node your-mcp-server.js

Para Claude Desktop, ejecuta primero un parche de configuración en seco y luego aplícalo:

npx protect-mcp wrap --claude-desktop
npx protect-mcp wrap --claude-desktop --write
npx protect-mcp dashboard --open

El panel se vincula a 127.0.0.1, lee solo archivos locales de registro/recibos y no sube nada. Usa npx protect-mcp connect solo si deseas explícitamente un panel alojado de ScopeBlind.

La puerta como servidor MCP

Si prefieres llamar a la puerta como herramientas en lugar de cablear los hooks de Claude Code, ejecútala como servidor MCP:

npx protect-mcp mcp

Habla MCP sobre stdio y expone cuatro herramientas de solo lectura, el bucle completo:

• evaluate_action: decide una llamada de herramienta propuesta contra una política Cedar en línea, con cierre ante fallos (cualquier error de política es DENEGAR). Devuelve { allowed, decision, reason, policy_digest }.
• sign_decision: convierte una decisión en un recibo firmado con Ed25519 (una denegación firma un gateway_restraint, una autorización un decision_receipt). Devuelve el recibo y su clave pública; genera una clave efímera si no proporcionas una.
• verify_receipt: verifica un recibo firmado sin conexión contra una clave pública. Devuelve { valid, error, type, kid, issuer }.
• self_test: demuéstralo, sin entradas. Una acción conocida como prohibida se deniega, luego un recibo firmado hace el recorrido completo y una copia manipulada falla.

Apunta cualquier host MCP hacia él, por ejemplo Claude Desktop:

{
  "mcpServers": {
    "protect-mcp": { "command": "npx", "args": ["-y", "protect-mcp", "mcp"] }
  }
}

Los recibos son compatibles a nivel de bytes con los que la puerta firma en tiempo de ejecución, de modo que un recibo acuñado aquí usa el mismo sobre Acta. Las capacidades de verificación y la compatibilidad de canonicalización dependen de la versión del verificador; usa la API verifyReceipt de la puerta para el comportamiento de conformidad descrito a continuación.

Compatibilidad de canonicalización de recibos

Este árbol de fuentes corrige el defecto de ordenamiento de claves enteras presente hasta 0.14.0: las firmas y los hashes de cadena ahora usan emisión directa de miembros JCS, conservando el perfil de claves de objeto ASCII de la puerta. Las claves de apariencia numérica como "10" preceden a "2", incluso dentro de objetos anidados. Los valores no JSON y el Unicode inválido se rechazan.

Los recibos JSON ordinarios cuyas codificaciones no han cambiado continúan verificándose. Los recibos históricos firmados con el antiguo orden de claves numéricas se reportan como legacy_non_jcs_signature; la verificación estricta no los considera JCS válidos. Para una verificación explícita de compatibilidad histórica, usa verifyReceipt(receipt, publicKey, { allowLegacyNumericKeys: true }) e inspecciona los campos canonicalization y warning. Su hash es entonces el hash histórico original. Conserva los recibos originales y los enlaces de cadena: recalcular un recibo antiguo de claves numéricas con receiptHash ahora produce su hash JCS y puede romper la cadena histórica. Estos cambios están incluidos en 0.15.0.

Comienza con tu agente y luego autoriza cada tarea

La versión 0.25.0 incluye un perfil de agente reutilizable. Abre Comienza a través de tu agente para el comando de configuración con la clave de autoridad mostrada del servicio. Verifica esa clave contra una fuente confiable antes de conectarte. Por ejemplo:

npx --yes protect-mcp@0.25.0 coordination agent setup \
  --client claude-code \
  --profile ~/.scopeblind/agent.json \
  --endpoint https://scopeblind.com/api/coordination \
  --authority-key PINNED_64_HEX_AUTHORITY_KEY

Usa --client codex o --client json para esas instrucciones de registro. La configuración imprime la configuración; aplícala en tu cliente y luego vuelve a abrir ese cliente. El perfil privado contiene una clave de agente y conexiones con alcance separado, con permisos de archivo 600. La configuración no otorga permisos de tarea y no copia ninguna clave de navegador humana. El servidor registrado ejecuta coordination agent --profile FILE.

Pide a tu agente que prepare una tarea de factura compartida para tu revisión. El flujo de herramientas es:

1. coordination.prepare_task({request_id, draft}) guarda un borrador sin firmar y devuelve un enlace de revisión privado para ti. Mantén el mismo request_id al reintentar. El borrador contiene un título, un objetivo y límites propuestos opcionales, suposiciones y preferencias privadas. No crea sala ni autoridad humana.
2. Revisa el borrador en el navegador, edítalo y firma tus propios límites. Invita a la otra persona, que firma sus propios límites de forma independiente. Por separado, autoriza la conexión de negociación de tu agente. Los enlaces de revisión expiran después de 30 minutos; la posesión no otorga al agente poderes de pago o aprobación.
3. coordination.inspect_task_request({request_id}) verifica esa revisión. coordination.claim_task_connection({request_id}) reclama la concesión exactamente autorizada y devuelve un connection_id. Luego llama a coordination.inspect_negotiation({connection_id}) antes de proponer o probar.
4. Ambas personas aprueban un plan probado exacto. El organizador original crea la tarea separada y puede autorizar explícitamente al mismo agente para ejecutarla. coordination.check_handoffs({connection_id}) descubre esa autorización; coordination.claim_execution_connection({connection_id, handoff_id}) guarda una nueva conexión de ejecución. Inspecciona su connection_id devuelto antes de enviar pagos. El token de negociación nunca se convierte en token de pago.

Cada herramienta con alcance en el perfil requiere un connection_id explícito; usa coordination.connections para listar conexiones guardadas sin credenciales. El perfil conserva los tokens antes de reclamar, de modo que una respuesta incierta se puede recuperar con los mismos IDs. Las ventanas iniciales de emparejamiento duran como máximo diez minutos. Si esa ventana o una concesión expira, la persona original debe reconectar explícitamente el mismo perfil bajo los límites actuales. Los perfiles faltantes requieren autorización nueva. Un perfil contiene como máximo 50 solicitudes y 50 conexiones; mantenlo privado.

Las conexiones existentes de una sola sala a continuación siguen funcionando. Importa una con coordination agent import --profile FILE --config OLD_PRIVATE_CONFIG después de configurar el perfil. La importación conserva su alcance y no puede reconstruir una clave de agente privada descartada por emparejamientos antiguos; esa conexión no puede reclamar una transferencia de ejecución con la misma clave.

El texto del borrador y las instrucciones privadas se envían a ScopeBlind. El proveedor de modelos de tu agente puede recibir resultados de herramientas, incluido tu propio resumen privado autorizado. Un asistente alojado recibe el resumen de su propio principal más los registros compartidos. Ni la configuración del perfil ni un cliente detenido ejecutan un agente o modelo en segundo plano.

Toma decisiones exactas en otro dispositivo

Desde una tarea en el navegador autorizado original, elige Continuar en otro dispositivo. Abre o escanea su enlace en tu teléfono, solicita acceso y compara el código mostrado en ambos dispositivos. El navegador original firma la clave exacta del teléfono, la sala, los permisos y la expiración. Un enlace o código QR por sí solo no otorga autoridad; cada dispositivo conserva su propia clave de firma privada.

El acceso dura como máximo siete días o la expiración de la tarea. Según el alcance elegido y el rol existente de la persona, el teléfono puede inspeccionar la tarea, aprobar o denegar un pago exacto, aceptar o solicitar cambios en su resultado exacto, y firmar su propio mandato de negociación o decisión de plan probado exacto. No puede crear tareas, invitar personas o agentes, iniciar un modelo alojado, adoptar reglas, ejecutar pagos ni delegar a otro dispositivo. Las firmas futuras de acuerdo y rol de revisor se permiten solo dentro de esa propuesta exacta revisada conjuntamente. No transfieren el acceso del teléfono a la nueva tarea.

El navegador original o el dispositivo vinculado pueden revocar el acceso de ese dispositivo. La revocación bloquea nuevas acciones; no borra decisiones anteriores válidas. La evidencia conserva el firmante real del dispositivo, la autorización firmada del principal original y el recibo de uso de autorización firmado del servicio. La verificación portátil de negociación, resultado y ensayo comprueba el linaje requerido. Estas firmas identifican claves, no identidades reales verificadas.

Tus decisiones lee el trabajo actual autenticado por este dispositivo. Abrir un elemento verifica la solicitud actual nuevamente; las decisiones expiradas o superadas no pueden autorizar un pago o resultado modificado. Los recordatorios opcionales del navegador no contienen detalles de tarea ni credenciales, abren esta bandeja de entrada y nunca aprueban trabajo ni despiertan un agente externo. La entrega depende del navegador, el sistema operativo y la configuración del host. En iPhone o iPad, agrega ScopeBlind a la pantalla de inicio, vincula la clave de dispositivo de esa aplicación y habilita los recordatorios allí. Los recordatorios se pueden desactivar sin cambiar los permisos de la tarea.

Conecta tu agente a una sala de factura compartida

protect-mcp versión 0.25.0 conecta tu agente instalado al mismo servicio de admisión y libro mayor de muestra que la sala compartida. Inicia una sala en ScopeBlind y luego elige Usa tu propio agente → Crear código de emparejamiento. Es un entorno de prueba de facturas ficticio; no se mueve dinero real.

La versión se distribuye como un paquete versionado desde scopeblind.com. Su checksum SHA-256 se publica junto a él. Ejecuta el comando de la sala en tu terminal. Para una sola conexión:

npx --yes protect-mcp@0.25.0 coordination pair

Pega el código privado cuando se te solicite. Nunca es un argumento de línea de comandos ni un parámetro de URL. El comando genera una clave y credencial de agente independientes, guarda el estado pendiente antes de reclamar, verifica la autorización del propietario y el reconocimiento fijado del servicio, y luego almacena la conexión completada en ~/.scopeblind/coordination.json con permisos 600. El código de emparejamiento dura como máximo diez minutos; la conexión resultante dura como máximo 24 horas. El propietario puede revocarla en la sala. Si se pierde una respuesta, vuelve a ejecutar el mismo comando con el mismo archivo de configuración para recuperar la misma inscripción.

Para varias salas, usa la ruta --config específica de la sala que se muestra en el navegador. Una configuración existente nunca se reemplaza con la credencial de una sala diferente.

El emparejamiento exitoso imprime directamente el comando de registro de Claude Code. Para imprimirlo nuevamente:

npx --yes protect-mcp@0.25.0 coordination setup --client claude-code

Ejecuta el comando que imprime en el proyecto donde usas Claude Code. Registra un servidor MCP en el ámbito local, con la ruta de la configuración privada y sin credencial en el comando ni en la configuración del cliente. Reinicia Claude Code y verifica /mcp, luego pregunta:

Inspecciona la sala de facturas de ScopeBlind y sus órdenes de compra. Completa el trabajo permitido bajo los límites acordados. Solicita aprobación exacta donde sea necesario; sigue trabajando en otras facturas y luego usa coordination.wait para las decisiones. Entrega el resultado completado para que el destinatario lo revise.

setup --client json imprime la configuración estándar de mcpServers para uso manual con otros clientes. Usa setup --client codex para el registro de Codex CLI. Estos comandos imprimen configuración y no editan la configuración de tu cliente. Para Claude Code, consulta su documentación oficial de MCP.

Las herramientas MCP son:

• coordination.inspect: inspecciona el acuerdo firmado por el propietario, las facturas, las órdenes de compra, el presupuesto, las operaciones actuales e históricas y las instrucciones de revisión.
• ledger.pay: envía el operation_id, invoice_id, amount_minor, currency exactos (USD) y destination. Las salas en vivo también requieren el fixture_revision de inspección. El adaptador verifica la admisión firmada antes de la ejecución y el resultado firmado después.
• coordination.wait: pasa el evento cursor de inspección como after_cursor. La herramienta espera hasta 30 segundos y comprueba los cambios cada dos segundos, sin llamar al modelo entre comprobaciones. Devuelve changed o waiting, la ejecución/posición actual y lo que necesita atención. En caso de tiempo de espera, una sesión activa puede volver a esperar; la reanudación depende del cliente MCP. Esta herramienta no envía notificaciones push; los recordatorios opcionales de la bandeja de entrada del navegador son independientes. La cancelación y la desconexión detienen una espera activa.
• coordination.deliver: proporciona el run_id inspeccionado y congela el resultado una vez que todo el trabajo tiene una disposición registrada. El servicio rechaza el trabajo no resuelto. El destinatario acepta por separado el resultado exacto o solicita una revisión.

Conserva el mismo ID de operación en los reintentos y reinicios. Una carga útil modificada bajo ese ID es rechazada. Después de que un revisor apruebe el trabajo retenido, reintenta la misma operación sin cambios. El agente no puede aprobar su propia solicitud, cambiar reglas, crear una revisión, invitar a personas ni aceptar su propio resultado. Las revisiones autorizadas por el propietario conservan el presupuesto acumulado y la protección contra facturas duplicadas.

Un resultado de ejecución desconocido conserva su reserva. Una operación confirmada repetida devuelve el resultado firmado original; no paga dos veces. Revocar a un agente detiene futuras admisiones y efectos no confirmados, incluida una solicitud que compitió con la revocación. No deshace pagos confirmados.

Para operadores de servicios personalizados, la conexión explícita original permanece:

npx --yes protect-mcp@0.25.0 coordination \
  --endpoint https://YOUR-HOST/api/coordination \
  --room ROOM_ID \
  --authority-key PINNED_64_HEX_AUTHORITY_KEY \
  --token-env PROTECT_MCP_COORDINATION_TOKEN

La variable de entorno nombrada contiene la credencial del ejecutor. HTTPS es obligatorio excepto para pruebas locales de bucle invertido. Las redirecciones son rechazadas. Las credenciales nunca se imprimen. El servicio configurado recibe las solicitudes de muestra; el proveedor de modelos de tu agente puede recibir registros devueltos por las herramientas. El adaptador cubre esta ruta de libro mayor de muestra y no gobierna otras herramientas en tu cliente.

Deja que un agente pruebe las reglas

En Prueba estas reglas, elige Deja que tu agente pruebe las reglas para crear una conexión de prueba separada y explícitamente delimitada. Usa su comando específico de sala y código privado, luego ejecuta el comando de registro de Claude Code impreso. La versión 0.20.0 reconoce estos códigos de emparejamiento versión 2; las concesiones de ejecución antiguas permanecen sin cambios y no obtienen permisos de prueba. Usa archivos de configuración separados para una conexión de ejecución y una conexión de prueba. La configuración registra una conexión de prueba como scopeblind-test, por lo que no sobrescribe la conexión de ejecución scopeblind.

Pregunta a tu agente:

Inspecciona este ensayo. Quiero que una persona revise facturas superiores a $400. Añade esa expectativa para Fieldwork, propón el cambio de umbral y compara la puerta real antes y después. Explica qué trabajo útil aún tiene éxito y si todos los casos de seguridad requeridos pasan. Deja la adopción a mí.

Una conexión de prueba expone solo estas cuatro herramientas:

• coordination.inspect_rehearsal: lee el acuerdo fuente firmado, los registros, casos, propuestas e informes. Proporciona report_digest para recuperar una instantánea histórica de evidencia exacta y verificarla.
• coordination.propose_case: añade un caso con un id, factura, expectativa y requisito estables. Los casos de seguridad fijos no pueden reemplazarse ni marcarse como opcionales.
• coordination.propose_repair: propone un umbral de revisión y una justificación vinculada al acuerdo fuente, la instantánea fija y los casos. Otros términos no pueden cambiar.
• coordination.run_rehearsal: proporciona un id de prueba estable y un proposal_id opcional para ejecutar la puerta real en libros mayores de muestra separados. La herramienta continúa hasta seis fragmentos duraderos dentro de tres minutos; el trabajo incompleto devuelve pending con instrucciones para reanudar el mismo ID. La cancelación detiene más solicitudes del cliente y los fragmentos completados permanecen disponibles. Si la respuesta se pierde o expira, inspecciona los informes y reintenta el mismo ID de prueba para recuperar su resultado.

El agente de prueba no puede pagar en la sala fuente, aprobar excepciones, invitar a otro agente ni activar una reparación. El propietario decide por separado si una comparación exitosa debe convertirse en una nueva tarea de muestra. Esa nueva tarea tiene su propio libro mayor; los acuerdos fuente, presupuestos, pagos y resultados permanecen sin cambios. La revocación bloquea solicitudes futuras y la publicación final de una prueba aún en curso.

Los informes describen el comportamiento observado de la puerta para casos concretos. Una firma válida identifica al operador de puerta nombrado y protege el registro exacto de alteraciones; no prueba todas las entradas posibles ni observa independientemente al operador. El adaptador instalado verifica el informe y los enlaces de instantánea antes de devolver evidencia de comparación. Las aplicaciones fuera de línea pueden verificar un paquete exportado con:

import { verifyRehearsalEvidence } from 'protect-mcp';
const result = await verifyRehearsalEvidence(bundle, expectedAuthorityPublicKey);
if (!result.valid) throw new Error(result.errors.join('; '));
console.log(result.checks, result.limitations);

Fija la clave de autoridad de forma independiente; omitirla comprueba contra la clave nombrada en el acuerdo fuente firmado por el propietario. Un informe verificado es evidencia para una decisión de adopción humana, no permiso para ejecutar un pago.

Panel de acciones local

protect-mcp dashboard es la vista del operador para pasar de la visibilidad a la aplicación de políticas:

• Inventario de herramientas: cada herramienta observada, recuento de llamadas, riesgo alto/medio/bajo y si la política activa tiene una regla exacta, un respaldo comodín o ninguna regla.
• Cobertura de políticas: ediciones de políticas locales con un clic para Require approval, Block o Observe. Reinicia el envoltorio después de revisar los cambios.
• Cola de aprobación de acciones exactas: la herramienta exacta, acción, destino, vista previa de carga útil redactada, hash de carga útil, base de política y captura de razón antes de que un humano apruebe, niegue, edite o tome el control.
• Cadena de recibos: IDs de solicitud correlacionados con hashes de recibos firmados, para que un revisor de auditoría pueda ver qué decisiones tienen prueba criptográfica.
• Exportación de auditoría: descarga el paquete de auditoría verificable fuera de línea cuando existen recibos firmados. Si solo hay registros locales sin firmar, el panel explica que la firma debe habilitarse primero.

Para aprobaciones de respaldo de escritorio en vivo, inicia el panel con el punto final de aprobación de puerta local y el nonce impreso por el envoltorio:

npx protect-mcp dashboard --open \
  --approval-endpoint http://127.0.0.1:9876 \
  --approval-nonce "$PROTECT_MCP_APPROVAL_NONCE"

Approve reenvía a la puerta local en vivo cuando esos indicadores están presentes. Deny, Edit y Take over se registran localmente como registros de resolución de aprobación; úsalos como instrucción del operador y vuelve a ejecutar la herramienta cuando sea necesario.

MVP de límite pagado: anclaje de resumen, no carga de datos

Los recibos autofirmados locales permanecen gratuitos y verificables fuera de línea. El límite pagado es evidencia independiente de que ScopeBlind vio un resumen de recibo en un momento, bajo una identidad de organización, sin recibir el prompt sin procesar, la carga útil de la herramienta, la salida, la clave privada o el recibo sin procesar.

# Create or refresh a local org identity and public-key directory.
npx protect-mcp registry init --org "Meridian Global Macro" --billing-account acct_meridian

# Local preview: writes a digest registry and shareable static verifier page.
npx protect-mcp registry anchor

# Hosted mode: uploads receipt digests only for independent anchoring.
SCOPEBLIND_TOKEN=... npx protect-mcp registry anchor \
  --hosted \
  --endpoint https://api.scopeblind.com \
  --verifier-base https://scopeblind.com

La vista previa local está deliberadamente etiquetada como local-preview-not-independent. El modo alojado ancla solo hashes de recibos, IDs de solicitud, claves públicas de organización y metadatos de facturación. No carga recibos sin procesar ni contexto sensible.

Demo impactante: sombra a política a prueba

protect-mcp killer-demo genera un paquete completo de ventas/demo de tres minutos:

npx protect-mcp killer-demo --dir ./scopeblind-demo

Crea actividad simulada de sistema de archivos, GitHub, correo electrónico y PMS; muestra llamadas riesgosas en modo sombra; aplica un paquete de políticas; requiere aprobación para una reserva sensible de PMS; ejecuta a través de la puerta; escribe un recibo firmado; prueba que el recibo original verifica; prueba que un recibo manipulado falla; y crea un paquete de divulgación selectiva que oculta contexto sensible mientras muestra la prueba mínima.

Abre el DEMO-RUNBOOK.md generado primero. Luego ejecuta el comando de panel impreso para guiar a un cliente a través de la secuencia exacta.

Divulgación selectiva v0

Los recibos en modo compromiso pueden llevar un committed_fields_root en lugar de exponer cada campo en texto claro. Más tarde, el titular puede divulgar solo campos seleccionados:

npx protect-mcp verify-disclosure \
  --receipt ./receipts/selective-disclosure.receipt.json \
  --disclosure ./receipts/selective-disclosure.tool-only.json

El verificador comprueba el hash del recibo padre, la firma Ed25519, la raíz de compromiso y la prueba de Merkle de cada campo divulgado. Luego explica qué campos fueron divulgados y qué campos comprometidos permanecen ocultos. Esto es divulgación de compromiso con sal, no conocimiento cero completo, pero hace concreto el reclamo de privacidad: los auditores pueden verificar hechos seleccionados sin recibir la carga útil completa de la herramienta o el contexto sensible del escritorio.

Prueba una afirmación sobre el registro (atestaciones ciegas a la posición)

Puedes probar una AFIRMACIÓN sobre tu registro sin revelarlo. Acuña una atestación firmada, ciega a la posición, sobre todo el registro que divulga solo categorías por decisión (un resumen de recibo, el veredicto, etiquetas de capacidad), nunca tus entradas, salidas o datos de la herramienta:

# "No action reached the network across the record":
npx protect-mcp claim --no net.egress

# other predicates:
#   --only fs.read,fs.write     all actions were confined to these capabilities
#   --no-verdict blocked        no action was blocked
#   --count blocked             how many were blocked

Cualquiera la verifica fuera de línea, viendo solo las categorías, nunca el contenido:

npx protect-mcp verify-claim claim-<id>.json

El verificador recalcula una raíz de Merkle sobre el conjunto divulgado y recalcula el predicado de forma independiente, por lo que el emisor no puede mentir sobre la afirmación dada la divulgación. Añade --anchor para registrar el resumen de la afirmación en el registro público de transparencia de ScopeBlind de solo añadido, para que una contraparte que no confíe en ti pueda confirmar que el conjunto divulgado está completo y no fue recortado silenciosamente (solo se envía el hash; el registro permanece local):

npx protect-mcp claim --no net.egress --anchor

Esta es una atestación responsable y ciega a la posición, no conocimiento cero completo: revela la forma, no el contenido.

Pruébalo en 60 segundos (sin agente requerido)

Mira la película de dos minutos en scopeblind.com/film, luego reprodúcela contra tu propia copia:

npx protect-mcp sample     # seed a labeled sample record (8 decisions: 1 blocked, 2 payments)
npx protect-mcp record     # open it: signatures verified in your browser

npx protect-mcp claim --payment-under 100 --anchor --output payments-under-100.json
npx protect-mcp verify-claim payments-under-100.json
npx protect-mcp anchor-record

Arrastra el demo-tampered.jsonl generado a la página de registro para ver cómo se detecta una edición posterior a la firma. sample se niega a tocar un registro existente, así que ejecútalo en una carpeta vacía. Cuando estés listo para lo real, conecta la puerta a continuación y los mismos comandos se ejecutan contra el registro de tu propio agente.

Inicio rápido de enganche de Claude Code

# Generate hook config and a sample Cedar policy.
npx protect-mcp init-hooks

# Serve the Claude Code hook gate in enforce mode. It runs a restraint self-test
# first and refuses to start if it cannot prove it denies a forbidden vector.
npx protect-mcp serve --enforce --cedar ./cedar

Evaluación de una sola vez, como la llama un enganche PreToolUse. El código de salida 2 significa denegar (la herramienta está bloqueada); el código de salida 0 significa permitir:

npx protect-mcp evaluate --cedar ./cedar --tool Bash --input '{"command":"rm"}'
echo $?   # 2  -> denied, fail-closed

npx protect-mcp evaluate --cedar ./cedar --tool Read --input '{"path":"README.md"}'
echo $?   # 0  -> allowed

Una política faltante o no cargable deniega (salida 2) a menos que pases explícitamente --fail-on-missing-policy false.

Enganches de Claude Code

protect-mcp init-hooks escribe un .claude/settings.json para ti. Para conectar la puerta manualmente, los dos verbos que necesitas son evaluate (PreToolUse, bloquea en salida 2) y sign (PostToolUse, registra un recibo). Claude Code entrega a un enganche la llamada como JSON en stdin y no establece variables TOOL_NAME o TOOL_INPUT, así que pasa --format claude y nada más sobre la llamada: la puerta lee tool_name y tool_input de la carga útil, y en una denegación devuelve la razón al modelo como hookSpecificOutput.permissionDecisionReason además de la salida 2. Fija la versión para que una sesión de Claude Code siempre ejecute la puerta que probaste:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "npx protect-mcp@0.25.0 evaluate --cedar ./cedar --format claude"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "npx protect-mcp@0.25.0 sign --format claude --receipts ./receipts --key ./keys/gateway.json"
          }
        ]
      }
    ]
  }
}

Pon un estándar firmado en vigor y deja que el registro aterrice en su página

Desde 0.14.0 la puerta puede mantener el estándar firmado en sí (el standard.json escrito y firmado en scopeblind.com/write) junto a la política Cedar compilada a partir de él, e informar a la página del propio estándar:

# Initialize the signing key once, unless this directory already has one.
npx protect-mcp@0.25.0 init
npx protect-mcp@0.25.0 --enforce --cedar ./policy --standard ./standard.json \
  --report 'https://scopeblind.com/api/standard?s=<standard id>' \
  -- <your MCP server command>

Con --standard, tres de los términos del estándar se aplican desde el propio estándar en lugar de inferirse: una llamada a una herramienta que el estándar no nombra es rechazada (standard_tool_not_allowed); una llamada cuyo monto supera el límite por instrucción, o está en otra moneda, es rechazada antes de ejecutarse (standard_amount_over_limit, standard_currency_not_permitted); y una llamada cuyo monto supera el umbral de aprobación queda en espera para la persona designada (standard_requires_person). Los montos se leen del campo amount_minor (unidades menores enteras) o amount (unidades mayores) y del campo currency de la llamada; una llamada que no lleva monto no es un pago y no queda en espera.

Una llamada en espera se responde al modelo como un resultado de herramienta, nunca como un error, de modo que la conversación continúa: REQUIRES_APPROVAL: ... esperando a la persona designada en https://scopeblind.com/standard?s=<id>#held-<hid>. Esa persona abre la página y aprueba o deniega la acción exacta, firmando en el navegador con la clave que el estándar acepta. Cuando el modelo reintenta la misma llamada (el mismo hash de carga útil), la puerta encuentra la decisión: una aprobación deja pasar la llamada con la decisión en el recibo (approval: { hid, approver_key_id, digest, page }); una denegación la rechaza (person_denied). Una llamada modificada es una acción nueva.

Con --report, cada recibo se añade primero a la cadena local y se publica en la página después, en orden, con el mejor esfuerzo: la página nunca bloquea una llamada, y una página inaccesible se registra en el registro, no es fatal. El token proviene de la pestaña Sign de la página Write, mostrado una sola vez; configúralo en el entorno del proceso como PROTECT_MCP_REPORT_TOKEN. --run <id> nombra la ejecución en la página (por defecto: una marca de tiempo). Los recibos llevan standard: { request_id, digest } para que un lector pueda saber qué estándar estaba en vigor.

El servidor de hooks acepta las mismas cuatro banderas, de modo que las llamadas de un agente de codificación a través de los hooks de Claude Code llegan a la página y quedan en espera bajo el estándar de la misma manera:

npx protect-mcp@0.25.0 serve --enforce --cedar ./policy --standard ./standard.json \
  --report 'https://scopeblind.com/api/standard?s=<standard id>'

Una retención en la ruta de hooks se devuelve como una denegación cuya razón nombra la página; el agente reintenta la misma llamada después de que la persona haya decidido allí.

La puerta de enlace ahora también pasa la entrada de la llamada a Cedar como context.input, de modo que una política compilada a partir del límite de monto de un estándar se evalúa en la puerta exactamente como sign --cedar y el servidor de hooks la evalúan.

Firmar la decisión de política en sí misma

Desde 0.13.0, sign puede evaluar la política y registrar la decisión real en el recibo en lugar de una autorización incondicional. Pasa el directorio de políticas y la misma entrada y contexto que el hook pasaría a evaluate:

npx protect-mcp@0.25.0 sign --cedar ./cedar --tool Bash \
  --input '{"command":"rm -rf /"}' --context '{"command_pattern":"rm -rf"}' \
  --receipts ./receipts --key ./keys/gateway.json

Sin --receipts, el recibo se une al registro propio de la puerta de enlace (.protect-mcp-receipts.jsonl en --dir), de modo que un despliegue tiene una sola cadena y record muestra cada decisión; --receipts <dir> mantiene un receipts.jsonl separado.

La carga útil del recibo lleva entonces decision (autorizar o denegar), reason (cedar_allow o cedar_deny) y policy_digest (el resumen acta-policy-digest-v1 del conjunto de políticas), y cita draft-farley-acta-signed-receipts-03. El comando imprime la decisión y el resumen en la salida estándar. Una denegación sigue firmada: el recibo es el registro de la decisión, no el permiso para proceder.

Se admiten dos modelos de acción Cedar. La puerta de enlace en tiempo de ejecución evalúa Action::"MCP::Tool::call" con la herramienta como recurso, que es lo que las políticas en cedar/ esperan y lo que sign --cedar usa por defecto. Las políticas que nombran la herramienta como la acción (action == Action::"Bash"), como la política de conformidad publicada en agent-governance-testvectors, necesitan --action-model tool. evaluate acepta la misma bandera.

evaluate sale con código 2 en caso de denegación para que Claude Code bloquee la llamada a la herramienta, y con 0 en caso de autorización. sign es de mejor esfuerzo: añade un recibo firmado con Ed25519 cuando hay una clave configurada, y si no hay un firmante disponible registra una línea sin firmar honesta ("signed": false) en lugar de hacer fallar la herramienta.

Usarlo en otros agentes (Codex, Cursor, Gemini, Hermes)

La misma puerta de cierre por fallo se ejecuta como un hook de herramienta en cualquier agente que los admita. Añade --format <host> para que el verbo lea la carga útil del hook de ese host desde la entrada estándar y deniegue en su contrato:

# the PreToolUse / before-tool command for each host
npx -y protect-mcp@0.25.0 evaluate --format codex  --cedar ./cedar   # OpenAI Codex
npx -y protect-mcp@0.25.0 evaluate --format gemini --cedar ./cedar   # Gemini CLI BeforeTool
npx -y protect-mcp@0.25.0 evaluate --format cursor --cedar ./cedar   # Cursor beforeShellExecution
npx -y protect-mcp@0.25.0 evaluate --format hermes --cedar ./cedar   # Hermes pre_tool_call

Combina cada uno con sign --format <host> en el evento posterior a la herramienta para los recibos. El caso importante es Hermes, que ignora los códigos de salida de los hooks y lee el veredicto desde la salida estándar, por lo que --format hermes deniega mediante {"decision":"block"} en lugar de salir con código 2 (una salida con código 2 en bruto fallaría en abierto silenciosamente allí). Sin --format, los verbos leen las banderas --tool/--input exactamente como en la sección de Claude Code anterior.

Escribir una política

Las políticas Cedar viven en un directorio al que apuntas con --cedar. Una regla forbid deniega, una regla permit autoriza. Para coincidir con un valor en la entrada de la herramienta, usa el modismo .contains():

// Allow read-only tools.
permit(
  principal,
  action == Action::"MCP::Tool::call",
  resource == Tool::"Read"
);

// Deny dangerous shell commands by matching the command against a list.
forbid(
  principal,
  action == Action::"MCP::Tool::call",
  resource == Tool::"Bash"
) when {
  ["rm", "dd", "mkfs"].contains(context.command)
};

// Block destructive tools outright.
forbid(
  principal,
  action == Action::"MCP::Tool::call",
  resource == Tool::"delete_file"
);

Peligro: NO escribas context.command in ["rm", "dd"] para coincidir una cadena contra una lista. in es para jerarquías de entidades, no para pertenencia a cadenas. Cedar trata la expresión como un error de tipo y descarta silenciosamente toda la regla forbid, lo que (bajo una puerta de apertura por fallo) deja una permit residual en pie. Este es el defecto exacto detrás del aviso a continuación. Usa [...].contains(context.command) en su lugar. Desde 0.7.0 la puerta deniega ante ese error en lugar de permitir, y una prueba de alerta en CI hace fallar la compilación si el patrón se reintroduce en una política publicada. Consulta GHSA-hm46-7j72-rpv9.

Paquetes de políticas iniciales

La mayoría de los equipos no deberían escribir Cedar desde cero el primer día. Instala un paquete inicial, ejecútalo en modo sombra, inspecciona los recibos y luego ajusta o aplica:

npx protect-mcp policy-packs list
npx protect-mcp policy-packs show secrets-safe
npx protect-mcp policy-packs install filesystem-safe --dir ./cedar
npx protect-mcp policy-packs install all --dir ./cedar
npx protect-mcp serve --cedar ./cedar

Paquetes integrados:

• filesystem-safe: acciones destructivas de archivos y lecturas de rutas similares a secretos.
• git-safe: push forzados, reinicios duros, limpieza destructiva, eliminación de repositorios.
• email-safe: permite redactar, bloquea envíos no supervisados.
• database-safe: postura de base de datos orientada a lectura, bloquea SQL de escritura/administración.
• cloud-spend-safe: creación obvia de gastos en la nube y destrucción de infraestructura.
• secrets-safe: exfiltración común de secretos de archivos, entorno, shell y nube.
• finance-mandate-safe: violaciones de listas restringidas y concentración en flujos de reserva.

Credenciales que el agente nunca posee

La puerta de enlace puede guardar un secreto e inyectarlo en el despacho, de modo que el agente trabaja con una etiqueta y nunca ve el valor. Configura la bóveda en protect-mcp.json; el valor se lee de la variable de entorno nombrada del proceso de la puerta de enlace, no del agente:

{
  "credentials": {
    "github_token": { "inject": "header", "name": "Authorization", "value_env": "GITHUB_TOKEN" },
    "warehouse":    { "inject": "env",    "name": "PGPASSWORD",    "value_env": "WAREHOUSE_PASSWORD" }
  }
}

inject: "env" coloca el valor en el entorno del servidor envuelto; inject: "header" y "query" lo adjuntan a la llamada saliente. Una herramienta cuyo nombre coincide con una etiqueta se resuelve en cada llamada; si el secreto falta, la llamada se rechaza con credential_error en lugar de enviarse sin él. Cada recibo de tal llamada lleva credential_ref con la etiqueta, nunca el valor, de modo que un lector puede ver que la credencial que el estándar nombra se usó a través de la puerta de enlace. Lo que los recibos no pueden mostrar es que el agente no tenía otra copia del secreto; eso es una propiedad del despliegue.

Un estándar ScopeBlind establece esto como requirements.credentials_held_by_gate, y el informe de recibos de la puerta de enlace en scopeblind.com/verify verifica la etiqueta en cada recibo de la herramienta.

Verificar un recibo

Los recibos están firmados y son verificables sin conexión por cualquier persona con la clave pública. Sin red, sin proveedor, sin confianza en ScopeBlind:

npx @veritasacta/verify ./receipts/receipts.jsonl --format jsonl
# Exit 0 = valid, non-zero = tampered or malformed

npx protect-mcp bundle --output audit.json exporta un paquete de auditoría autocontenido y verificable sin conexión de tus recibos más la clave pública de firma.

Seguridad

protect-mcp 0.7.0 falla en cerrado por diseño. Ante cualquier error de evaluación de política, un motor faltante o una política que falló en la evaluación, la decisión es DENEGAR, no autorizar. serve --enforce y doctor ejecutan una autoprueba de arranque que demuestra que la puerta deniega un vector conocido como prohibido antes de que se confíe en ella, y se niegan a armarse si no puede.

Versiones afectadas: 0.5.x y 0.6.x. Esas líneas fallan en abierto (devuelven AUTORIZAR ante errores de evaluación) y no evalúan Cedar correctamente contra el motor fijado, por lo que una regla forbid podría no bloquear. Actualiza a >= 0.7.0.

Detalles y remediación: GHSA-hm46-7j72-rpv9. Para reportar una vulnerabilidad, consulta SECURITY.md.

Comandos

Comando	Descripción
serve	Inicia el servidor de enganche HTTP para Claude Code (puerto 9377). --enforce ejecuta primero la autoprueba de restricción; --cedar <dir> y --policy <path> seleccionan la política.
init	Genera un par de claves Ed25519 (keys/gateway.json), una plantilla de configuración y una política de muestra.
sample	Siembra un registro de muestra claramente etiquetado (8 decisiones: una llamada bloqueada, dos pagos; niño sample-demo) más una copia manipulada, para que record, claim, verify-claim y anchor-record sean reproducibles desde cero antes de conectar un agente. Se niega a tocar un registro existente; --force lo anula.
policy	Ver y cambiar la política Cedar desde la terminal: policy list (permitir / prohibir / denegar por defecto por herramienta, con la frecuencia con la que la puerta lo permitió o denegó), policy show, policy allow <tool>, policy deny <tool>, policy path. Un serve en ejecución recarga en caliente el cambio.
wrap	Imprime un comando MCP protegido o parchea los servidores MCP de Claude Desktop. Simulación por defecto; use --write para actualizar la configuración de Claude Desktop.
dashboard	Inicia un panel solo local en 127.0.0.1 que muestra inventario de herramientas, riesgo, cobertura de políticas, aprobaciones de acción exacta, cadenas de recibos y exportación de auditoría.
recommend	Redacta una política JSON revisable a partir de llamadas locales observadas. Simulación por defecto; use --write para crear protect-mcp.recommended.json.
registry	Crea una identidad de organización, ancla resúmenes de recibos y escribe una página de verificador estático. El modo alojado sube solo resúmenes.
record	Abre un visor local y buscable sobre sus recibos (--live transmite mientras el agente se ejecuta): firmas Ed25519 verificadas en su navegador contra su clave de puerta de enlace, etiquetas de capacidad, un árbol de procedencia y exportación firmada con un clic. Todo local, nada subido.
claim	Acuña una atestación firmada y ciega a la posición de un predicado sobre el registro (--no <cap> incl. --no payment, --only <c1,c2>, --no-verdict <verdict>, --count <verdict>, --payment-under <cap>), revelando solo categorías de decisión. Agregue --anchor para registrar el resumen de la reclamación en el registro de transparencia público; las claves inscritas se anclan como una organización nombrada.
anchor-record	Punto de control de la raíz Merkle del registro + recuento + rango de tiempo en el registro público (amigable con latidos: omite cuando no cambia). Una reclamación posterior cuyo compromiso coincida con un punto de control anclado es demostrablemente sobre el registro completo a partir de ese punto de control.
verify-claim	Verifica un paquete de reclamaciones sin conexión: firma, raíz Merkle recalculada, predicado recalculado independientemente y el sidecar de anclaje cuando está presente (vincula el sobre anclado a esta reclamación exacta, luego confirma que el registro público lo contiene). --check-anchor requiere el anclaje; --offline omite el salto de registro.
killer-demo	Genera un paquete de demostración completo de modo sombra a política a aprobación a recibo firmado.
verify-disclosure	Verifica un paquete scopeblind.selective_disclosure.v0 y explica los campos divulgados versus ocultos.
policy-packs	Lista, inspecciona e instala paquetes de política Cedar de inicio.
evaluate	Evalúa una llamada de herramienta contra una política Cedar (puerta PreToolUse). Salida 2 = denegar (cierre por fallo), salida 0 = permitir.
sign	Firma una llamada de herramienta en un recibo (PostToolUse). Mejor esfuerzo: registra una línea sin firmar honesta si no hay clave.
simulate	Simula una política contra un registro de decisiones grabado para ver qué habría bloqueado.
demo	Inicia un servidor de demostración integrado envuelto con la puerta, para ver recibos al instante.
doctor	Verifica su configuración (claves, políticas, motor Cedar, verificador) y ejecuta la autoprueba de restricción.
bundle	Exporta un paquete de auditoría verificable sin conexión de recibos más la clave pública.
report	Genera un informe de cumplimiento (Markdown o JSON) a partir del registro de decisiones y recibos.

Ejecute npx protect-mcp --help para la referencia completa de banderas.

Enlaces

• Protocolo (IETF): draft-farley-acta-signed-receipts
• CHANGELOG
• npm
• scopeblind.com

Licencia MIT. Construido por ScopeBlind.

Deje que su agente negocie por usted

La versión 0.25.0 admite el acuerdo de dos personas en ScopeBlind. Cada persona firma su propio mandato y crea su propio código de emparejamiento versión 3. La configuración privada vincula un principal y una discusión; no hereda poderes de pago o de revisor. Las conexiones existentes versión 1 y versión 2 conservan sus alcances.

Pregunte a su agente:

Inspeccione mi mandato de negociación y mi informe privado. Busque un umbral de revisión que satisfaga ambos mandatos compartidos y sus requisitos de factura. Proponga, compare, y responda usando solo las herramientas de negociación. Deje la aprobación del plan exacto a ambas personas.

Herramientas: coordination.inspect_negotiation, coordination.propose_candidate, coordination.respond_candidate, coordination.compare_candidate y coordination.wait_negotiation. La espera sondea solo la discusión con alcance y es cancelable, limitada a 30 segundos. Cada agente puede leer el informe privado de su propio principal, nunca el informe de la otra persona. ScopeBlind almacena los informes; su proveedor de modelo puede recibir los resultados de herramientas de su propio agente. Las exportaciones compartidas omiten los informes.

La discusión puede cambiar el umbral de revisión de facturas, con como máximo tres candidatos. Ambas personas firman la propuesta exacta, el informe de puerta, el acuerdo futuro y la inscripción de revisores antes de que el organizador cree un ensayo separado. Las recomendaciones del agente no pueden sustituir esas aprobaciones. El verificador del navegador verifica el historial compartido sin conexión, incluida la autorización de emparejamiento firmada independientemente por el principal para contribuciones realizadas por un agente instalado.

Revisar juntos un cambio visible del repositorio

Abra la demostración del botón de contacto para crear una tarea de repositorio aislada propiedad de ScopeBlind e invitar a una segunda persona. La vista previa renderiza datos demo/contact.json verificados con una plantilla fija; no ejecuta código del repositorio ni afirma que se implementó un sitio web público. Ambas personas aprueban los commits exactos revisados antes de que el receptor de confianza los aplique. El destinatario puede aceptar el resultado observado o solicitar una revisión fresca vinculada.

Para su propio repositorio, elija Usar su repositorio y ejecute el comando protect-mcp@0.25.0 repository setup generado localmente. Descubre nombres/proveedores de verificación reales, guarda una clave de receptor con permisos solo de propietario y prepara un flujo de trabajo con hash fijado para su revisión. El connection.json devuelto contiene claves públicas y evidencia de descubrimiento firmada. Mantenga receiver-key.json privado. El descubrimiento, un flujo de trabajo coincidente instalado y una ejecución de preparación de Actions exitosa firmada se muestran por separado. Ninguno otorga aprobación humana de una tarea.

El comando generado por el navegador suministra su clave pública de propietario y el pin de autoridad de servicio. Su forma completa está abajo; reemplace cada marcador de posición en mayúsculas con esos valores revisados y elija un nuevo directorio de salida. Inicie sesión localmente con gh auth login, o suministre GITHUB_TOKEN a través de su administrador de credenciales local. La configuración no guarda ni imprime ese token.

npx --yes protect-mcp@0.25.0 repository setup \
  --repository OWNER/REPOSITORY \
  --owner-key YOUR_PUBLIC_OWNER_KEY \
  --authority-key REVIEWED_SERVICE_AUTHORITY_KEY \
  --endpoint https://scopeblind.com/api/coordination \
  --output ./repository-connection

Para inspeccionar las verificaciones de CI existentes para una solicitud de extracción particular abierta del mismo repositorio, agregue --pull NUMBER. Revise el INSTALL.md generado antes de instalar el flujo de trabajo o configurar Actions. Importe solo el connection.json público. Para actualizar la preparación local de solo lectura para esta misma conexión, use un nuevo archivo de salida:

npx --yes protect-mcp@0.25.0 repository ready \
  --connection ./repository-connection/connection-config.json \
  --key-file ./repository-connection/receiver-key.json \
  --output ./repository-readiness.json

Esta actualización local no establece que el receptor de Actions esté respondiendo. Para esa observación, ejecute la operación ready del flujo de trabajo revisado e importe su evidencia pública como se describe en INSTALL.md.

Su perfil de agente reutilizable expone su clave pública a través de coordination.connections. Autorice esa clave exacta en la tarea del repositorio, luego pida al agente que llame a coordination.inspect_repository con la tarea y los IDs de concesión. La conexión de repositorio devuelta admite coordination.request_repository_revision con un resumen de base actual explícito y un ID de solicitud estable. Puede sugerir datos de página de contacto limitados y una razón; no puede inscribir un revisor, aprobar un cambio o ejecutar el receptor. Reutilizar un ID de solicitud reintenta la sugerencia firmada original exacta.

Revisiones recurrentes de clientes y preparación de agentes

Cree un proyecto de cliente desde la página de revisión del repositorio para reutilizar su repositorio, conexión de receptor y membresía de revisor. Cada revisión contiene su propio informe, criterios de éxito estables y una instantánea exacta de la solicitud de extracción. Ambas personas aprueban esa versión revisada; el destinatario puede aceptar por separado el resultado observado.

Para la preparación recurrente, ambas personas pueden firmar un mandato que nombre una clave de agente público, repositorio, rama, rutas permitidas, proveedores de verificación requeridos, caducidad y límites de solicitudes. Obtenga la clave pública del perfil con coordination.connections, luego autorícela en el panel Permisos de agente del proyecto. Un agente conectado usa estas herramientas:

Herramienta	Propósito
coordination.inspect_workspace	Verificar el proyecto y el mandato conjunto; inspeccionar la asignación restante y los borradores existentes.
coordination.prepare_repository_review	Enviar un borrador de revisión de PR firmado a la bandeja de entrada del proyecto para que una persona lo adopte.
coordination.inspect_repository_review	Leer el informe exacto de la tarea asignada, criterios, paquete de receptor y comentarios atribuidos.
coordination.report_repository_criteria	Informar met, not_met o unknown contra cada criterio, citando evidencia presente en el paquete.
coordination.request_repository_changes	Registrar comentarios de revisión general vinculados a la versión revisada exacta.

Use el workspace_id y mandate_id exactos mostrados en el proyecto. Después de la inspección, el ID del mandato se convierte en el connection_id de este propósito. Reutilice un request_id estable después de un envío interrumpido; el perfil privado conserva la intención firmada original. Nuevos hallazgos contra un paquete cambiado requieren una inspección fresca y un nuevo ID. Para preparar una revisión a partir de comentarios grabados, incluya la referencia draft.source exacta devuelta por la revisión: ID de tarea y resumen, resumen de base, resumen de paquete y resumen de comentarios. El proyecto conserva esa referencia en la evidencia portátil de la nueva revisión. La nueva versión requiere aprobaciones humanas frescas.

Estos permisos preparan y revisan el trabajo. No pueden hacerse pasar por una persona, adoptar el mandato, aprobar un cambio, fusionar un PR o aceptar un resultado. ScopeBlind no inicia un modelo alojado ni mantiene un agente externo en ejecución. El implementador maneja los cambios de código solicitados a través de sus herramientas de desarrollo y permisos existentes.

El registro de vista previa de un receptor describe la implementación de GitHub y los metadatos de verificación para el commit observado. Una URL de vista previa externa sigue siendo mutable; no es un artefacto inmutable ni una prueba de los bytes servidos posteriormente. Los hallazgos de criterios son recomendaciones de agentes atribuidas, incluidos desconocidos explícitos, para la decisión humana.

La recuperación del proyecto usa una credencial de recuperación inscrita por separado. Rota la autoridad futura de ese miembro del proyecto; nunca recrea una clave privada antigua del navegador ni reescribe aprobaciones históricas. Inicie una nueva revisión con la membresía actual antes de tomar más decisiones sobre el trabajo asignado a una clave anterior.

Conexión guiada y trabajo de código limitado

Abra sus proyectos y conecte un repositorio. La ruta guiada identifica el repositorio seleccionado y la solicitud de extracción, luego suministra un comando de instalación con versión fijada. Pegue su enlace de configuración de corta duración en el mensaje en lugar de un argumento de shell:

npx --yes protect-mcp@0.25.0 repository connect --link-stdin --install

Revise el flujo de trabajo exacto, los permisos y la clave de receptor antes de autorizar la instalación. Las claves se generan localmente. Una prueba de identidad de GitHub Actions y una firma de receptor establecen qué flujo de trabajo instalado respondió al desafío de preparación. La configuración manual existente del receptor sigue disponible.

El trabajo de codificación es una instalación y permiso opcionales y separados. Ambos miembros del proyecto firman las rutas permitidas, las pruebas/compilación fijas, la imagen de runtime inmutable, el permiso de vista previa pública, el tiempo, los archivos, los tokens y los límites de llamadas al modelo. El trabajador comienza desde la retroalimentación exacta registrada. Sus programas de repositorio no confiables se ejecutan en un contenedor Docker sin acceso a la red ni credenciales; el controlador confiable verifica los archivos resultantes y publica la nueva rama, PR y vista previa admitidas. El runtime inicial admite pequeños sitios estáticos de Node 22 con activos relativos autocontenidos y scripts fijos de prueba/compilación de Node.

El inicio automático del trabajo requiere la conexión de la GitHub App. Con una conexión local al propietario, el trabajo en cola muestra la página de Actions del repositorio exacto de scopeblind-coding.yml, la rama y el ID del trabajo. Seleccione Run workflow y proporcione ese ID existente como job_id; esto no crea otro trabajo ni omite el permiso de ninguna de las dos personas.

GitHub Actions debe tener permitido crear pull requests en Settings → Actions → General → Workflow permissions. El CI obligatorio existente puede necesitar Approve workflows to run o una ejecución manual configurada para el head exacto del nuevo PR. Los PR creados por GITHUB_TOKEN no garantizan la ejecución automática del CI existente; GitHub documenta las reglas actuales de activación y aprobación. Cada verificación/proveedor acordado sigue siendo obligatorio antes de la aprobación de la revisión o un efecto.

El resultado requiere una revisión nueva. Ninguna concesión de codificación autoriza una fusión. Después de que se admitió una publicación, la cancelación no puede deshacer los efectos ya enviados; un resultado incierto se reconcilia leyendo su rama y PR deterministas. La evidencia firmada distingue estas observaciones de la prueba de que el código cumple con cada criterio.

Los miembros del proyecto también pueden autorizar un segundo navegador para acciones de revisión seleccionadas. Ambos dispositivos confirman el enlace. Esto preserva la clave de membresía original y nunca otorga configuración del proyecto, recuperación, delegación de agentes o permisos de ejecución. La revocación detiene el acceso de nuevos dispositivos y las decisiones mientras preserva las firmas ya registradas.

Prueba de codificación gestionada compartida

La prueba de revisión de IA real alojada utiliza un repositorio desechable propiedad de ScopeBlind. Dos identidades de navegador acuerdan el trabajo, autorizan un trabajo de codificación limitado, inspeccionan la vista previa publicada, aprueban el cambio resultante exacto y aceptan el resultado registrado. No requiere acceso de GitHub del visitante. El iniciador estilizado inicial es determinista; solo la revisión autorizada por separado es producida por el modelo.

El controlador gestionado se envía como dist/repository-trial-cli.js. No es una credencial de repositorio alojado de propósito general ni una forma de omitir el receptor propio de un proyecto. Su flujo de trabajo revisado fija el repositorio, la plantilla, la autoridad de servicio y las identidades del trabajador. Si la publicación tiene éxito pero la confirmación de preparación de GitHub se interrumpe, los usuarios pueden verificar la publicación existente sin cambiarla y luego finalizar explícitamente la preparación de ese mismo PR mientras el permiso de ambas personas siga vigente. Ningún paso vuelve a ejecutar el modelo ni reemplaza el PR. Las observaciones de recuperación describen el estado actual del proveedor; no son aprobaciones, recibos de fusión ni garantías de corrección del código.