Intramedial está en beta restringida. Al registrarte o iniciar sesión, debes indicar la contraseña de beta tester que recibiste o solicitar una en preview@intramedial.com. Gracias.
Cargando…
github.enforceMódulo 29
Módulo de la plataforma
GitHub write gate
Haz que el check de un commit se ponga en rojo salvo que el agente que hay detrás tenga el grant y, para una escritura, una persona lo haya confirmado.
github.enforce admite una acción de repositorio a través de Intralock e informa del veredicto a GitHub como check run o estado de commit. Admite repo:<repo>, usa write como acción por defecto, y fija un commit permitido al agente para que los eventos de webhook posteriores de ese sha sigan la misma decisión.
Intralock · Leases · Parley · Fleet Map
Un producto Trustvice
Los agentes actúan cuando el plano dice sí, y el registro dice por qué.
Pasa por Intramedial acciones de agentes, hashes de contenido, pruebas de API, DNS, webhooks, llamadas LLM y commits. Obtén un recibo firmado que cualquiera verifica, sin fiarse de nadie.
EstadoLas señales de GitHub necesitan una App o un token
Sin GITHUB_PAT o una GitHub App vinculada, el veredicto se devuelve y se registra igualmente, pero commitStatus y checkRun son null, así que no se ve nada en el commit. Vincula una y confírmalo con github/app.
Registro
El registro
Qué se registra
repo
El repositorio, como acme/payments. El recurso admitido es repo: seguido de este valor.
actorDid
El agente cuya escritura es esta. Un actor de webhook es el login de GitHub que lo envió.
action
read, o . Cualquier otra cosa, o nada, se admite como .
El commit sobre el que informar. Opcional; se usa el último head ingerido cuando se omite.
confirmationToken
Un token generado cuando un aprobador confirmó esta escritura.
allow
En la respuesta: si Intralock admitió la acción.
reason
En la respuesta: por qué, como confirmation_required o no_grant.
commitStatus
En la respuesta: el estado de commit publicado en GitHub, o null.
checkRun
En la respuesta: el check run publicado en GitHub, o null.
Mecanismo
Paso a paso
Cómo funciona
Enviar el commit
enforce toma repo, actorDid, sha y una action de read, write o delete. Sin sha usa el último head que la pasarela ingirió para ese repo.
Intralock decide
La pasarela admite repo:<repo> para ese actor y acción. Una escritura sin confirmación vuelve como confirmation_required.
Se informa a GitHub
El veredicto se publica como el check run intramedial/acp cuando hay una App vinculada, o como estado de commit. Allow es success; el rechazo es failure.
Una persona confirma
Una revisión firmada o un comentario /acp allow genera un token para el actor fijado y vuelve a aplicar. /acp deny elimina la fijación si ese actor la tiene.
Pruébalo
Demo en vivo
Ejecútalo desde esta página
GET/api/v1/acp/github/status
// Sin cuerpo: esto es un GET. Pulsa Ejecutar.
Se ejecuta en un workspace de demostración compartido con una clave de demostración: cualquiera puede ver lo que contiene, así que no envíes nada privado. Docs de github.enforce
Respuestas
Pulsa Ejecutar para enviar la solicitud de la izquierda al workspace de demostración compartido.
Se ejecuta en un workspace de demostración compartido con una clave de demostración: cualquiera puede ver lo que contiene, así que no envíes nada privado.
Código
Ejemplo en vivo
Una petición real
Una petición con la forma que acepta la API y una respuesta de ejemplo con la forma que devuelve el módulo.
Exige el check intramedial/acp en la rama. Un check pendiente o fallido impide que el commit del agente se fusione hasta que alguien lo confirme.
Confirmar desde la pull request
Quien revisa comenta /acp allow. El webhook firmado genera el token, vuelve a admitir y cambia el estado del mismo commit a success.
Retirar una aprobación
revoke elimina la fijación que tiene un agente para un sha y publica un fallo, así que un commit ya aprobado puede volver a rechazarse.
Mantener a los agentes fuera de ramas compartidas
namespace reescribe la rama de un agente bajo agent/<slug>/ y rechaza nombres protegidos como main, release* y hotfix/*.
Cuándo usar otra cosa
Admitir llamadas a un servidor MCP. Usa mcp.enforce; este módulo trabaja con repositorios y commits.
Recoger la decisión humana. La aprobación en sí pertenece a coordination.approve; este módulo publica el resultado.
Controlar una sola rama o ref por nombre. Aquí la admisión es por repositorio; solo namespace conoce los nombres de rama protegidos.
Evidencia
Garantías
Qué hace y qué no hace
Un módulo es una afirmación fuerte sobre algo acotado. Confía en él exactamente para lo que es.
Hace
El veredicto es de Intralock, con llm: false; el mismo actor, repo y acción dan la misma respuesta que coordination.admit.
Cada enforce añade un evento github.enforce al ledger con el repo, el sha, el resultado y el motivo.
Un rechazo para un actor nunca elimina una fijación de sha que tenga otro actor, así que un extraño no puede cancelar una aprobación.
Una escritura que necesita confirmación queda pendiente cuando llega por webhook; solo un enforce explícito publica el fallo.
No hace
Que un merge esté bloqueado. El check bloquea solo si la protección de rama exige intramedial/acp; la pasarela no puede fijarlo por ti.
Que el código del commit sea seguro. La decisión trata de quién puede escribir, no de lo escrito.
Que un dictamen revoque una aprobación. revoke es una llamada explícita protegida por una autorización; ningún dictamen la activa.
Que un push esté controlado. La ingesta de push solo registra; los eventos de pull request, check, workflow y merge queue son los que aplican.
Detalles
Notas de construcción
Antes de construir
Qué se publica
Con una GitHub App vinculada el veredicto es un check run llamado intramedial/acp, con el estado de commit como alternativa. Un GITHUB_PAT publica solo el estado de commit.
La fijación de sha
Una escritura permitida anota el actor frente a repo, acción y sha. Un evento posterior de ese sha puede entonces generar un token para el mismo actor sin una segunda persona.
Eventos de webhook
Los eventos de pull request, check suite, check run, workflow run y merge group admiten el head como write y publican un estado pendiente hasta que llega un token.
Permisos
revoke necesita policies.approve y una warrant de control dual o adjudicada. enforce, ingest y status no llevan rol propio.
Límites y medición
El check run y el estado se publican solo cuando hay una credencial PAT o App vinculada; si no, ambos campos son null.
status devuelve los últimos 50 elementos ingeridos, filtrados por repo o sha si se dan.
revoke sin warrant devuelve 403 porque las rutas protegidas por autorización están cerradas por defecto.
namespace toma actorDid y branch; sin actor devuelve 400.
Acceso
API y MCP
REST y MCP
Autentícate con una clave de API del workspace como token Bearer. La URL base es https://api.intramedial.com.
Endpoints REST
POST/api/v1/acp/github/enforceAdmite una acción de repositorio y publica el veredicto en GitHub.
POST/api/v1/acp/github/ingestRegistra un webhook de GitHub y aplica los eventos que lo requieren.
GET/api/v1/acp/github/statusLee los elementos de auditoría recientes, el último head y quién tiene la fijación.
POST/api/v1/acp/github/revokeElimina la fijación de sha del actor y publica un fallo.
Acciones MCP
MCPcoordination.github.enforceAdmite una acción de repositorio desde un agente.
MCPcoordination.github.ingestRegistra el cuerpo de un webhook desde un agente.
MCPcoordination.github.statusLee los elementos de auditoría recientes de GitHub desde un agente.
Módulo de la plataforma
