Intramedial est en bêta restreinte. À l’inscription ou à la connexion, vous devez fournir le mot de passe de bêta-testeur que vous avez reçu ou en demander un à preview@intramedial.com. Merci.
Chargement…
github.enforceModule 29
Module du plan
GitHub write gate
Faites passer au rouge le contrôle d'un commit sauf si l'agent derrière détient l'habilitation et, pour une écriture, si un humain a confirmé.
github.enforce admet une action sur un dépôt via Intralock et renvoie le verdict à GitHub sous forme de check run ou de statut de commit. Il admet repo:<repo>, utilise write par défaut, et épingle un commit autorisé à l'agent pour que les événements webhook ultérieurs pour ce sha suivent la même décision.
Intralock · Baux · Parley · Fleet Map
A Trustvice Product
Les agents agissent quand le plan dit oui, et le registre dit pourquoi.
Faites passer actions d’agents, hash de contenu, contrôles d’API, requêtes DNS, webhooks, appels LLM et commits git par Intramedial. Obtenez un reçu signé vérifiable par tous – sans nous croire.
ÉtatLes signaux GitHub exigent une App ou un jeton
Sans GITHUB_PAT ni GitHub App liée, le verdict est quand même renvoyé et inscrit au registre, mais commitStatus et checkRun valent null : rien n'apparaît sur le commit. Liez-en un, puis vérifiez avec github/app.
Registre
Le registre
Ce qui est enregistré
repo
Le dépôt, par exemple acme/payments. La ressource admise est repo: suivi de cette valeur.
actorDid
L'agent dont c'est l'écriture. Pour un webhook, l'acteur est le login GitHub qui l'a envoyé.
read, write ou delete. Toute autre valeur, ou rien, est admise comme write.
sha
Le commit sur lequel rendre compte. Facultatif ; le dernier head ingéré est utilisé en son absence.
confirmationToken
Un jeton émis quand un approbateur a confirmé cette écriture.
allow
Dans la réponse : si Intralock a admis l'action.
reason
Dans la réponse : pourquoi, par exemple confirmation_required ou no_grant.
commitStatus
Dans la réponse : le statut de commit publié sur GitHub, ou null.
checkRun
Dans la réponse : le check run publié sur GitHub, ou null.
Mécanisme
Pas à pas
Comment ça marche
Envoyer le commit
enforce prend repo, actorDid, sha et une action parmi read, write ou delete. Sans sha, il utilise le dernier head ingéré par la passerelle pour ce dépôt.
Intralock décide
La passerelle admet repo:<repo> pour cet acteur et cette action. Une écriture sans confirmation revient avec confirmation_required.
GitHub est informé
Le verdict est publié comme check run intramedial/acp quand une App est liée, ou comme statut de commit. Autorisé donne success ; refusé donne failure.
Un humain confirme
Une revue ou un commentaire signé /acp allow émet un jeton pour l'acteur épinglé et réapplique la décision. /acp deny retire l'épingle si cet acteur la détient.
Essayer
Démo en direct
Exécutez-le depuis cette page
GET/api/v1/acp/github/status
// Pas de corps : c’est un GET. Appuyez sur Exécuter.
S’exécute dans un workspace de démonstration partagé avec une clé de démonstration : tout le monde peut voir ce qu’il contient, n’envoyez donc rien de privé. Docs github.enforce
Réponses
Appuyez sur Exécuter pour envoyer la requête de gauche au workspace de démonstration partagé.
S’exécute dans un workspace de démonstration partagé avec une clé de démonstration : tout le monde peut voir ce qu’il contient, n’envoyez donc rien de privé.
Code
Exemple en direct
Une vraie requête
Une requête dans la forme acceptée par l’API, et un exemple de réponse dans la forme renvoyée par le module.
Exigez le contrôle intramedial/acp sur la branche. Un contrôle en attente ou échoué empêche la fusion du commit de l'agent tant que personne ne l'a confirmé.
Confirmer depuis la pull request
Un relecteur commente /acp allow. Le webhook signé émet le jeton, admet à nouveau et passe le statut du même commit à success.
Retirer une approbation
revoke retire l'épingle qu'un agent détient pour un sha et publie un échec, de sorte qu'un commit déjà approuvé peut être à nouveau refusé.
Tenir les agents à l'écart des branches partagées
namespace réécrit la branche d'un agent sous agent/<slug>/ et refuse les noms protégés comme main, release* et hotfix/*.
Quand utiliser autre chose
Admettre des appels à un serveur MCP. Utilisez mcp.enforce ; ce module travaille sur les dépôts et les commits.
Recueillir la décision humaine. L'approbation relève de coordination.approve ; ce module publie le résultat.
Contrôler une branche ou une ref précise par son nom. L'admission est ici par dépôt ; seul namespace connaît les noms de branches protégées.
Preuves
Garanties
Ce qu’il fait, et ce qu’il ne fait pas
Un module est une affirmation forte sur un sujet étroit. Fiez-vous-y exactement pour ce qu’il est.
Il le fait
Le verdict est celui d'Intralock, avec llm: false ; le même acteur, dépôt et action donnent la même réponse que coordination.admit.
Chaque enforce ajoute au registre un événement github.enforce avec le dépôt, le sha, le résultat et le motif.
Un refus pour un acteur ne retire jamais l'épingle de sha détenue par un autre acteur : un tiers ne peut donc pas annuler une approbation.
Une écriture nécessitant confirmation reste en attente quand elle arrive d'un webhook ; seul un enforce explicite publie l'échec.
Il ne le fait pas
Qu'une fusion est bloquée. Le contrôle ne bloque que si la protection de branche exige intramedial/acp ; la passerelle ne peut pas le configurer pour vous.
Que le code du commit est sûr. La décision porte sur qui peut écrire, pas sur ce qui a été écrit.
Qu'un jugement révoque une approbation. revoke est un appel explicite protégé par un warrant ; aucun jugement ne le déclenche.
Qu'un push est contrôlé. L'ingestion de push ne fait qu'enregistrer ; ce sont les événements de pull request, de check, de workflow et de merge queue qui appliquent.
Détails
Notes de conception
Avant de construire
Ce qui est publié
Avec une GitHub App liée, le verdict est un check run nommé intramedial/acp, avec le statut de commit en repli. Un GITHUB_PAT ne publie que le statut de commit.
L'épingle de sha
Une écriture autorisée enregistre l'acteur pour le dépôt, l'action et le sha. Un événement ultérieur pour ce sha peut alors émettre un jeton pour le même acteur sans second humain.
Événements webhook
Les événements pull request, check suite, check run, workflow run et merge group admettent le head comme write et publient un statut en attente jusqu'à l'arrivée d'un jeton.
Autorisations
revoke exige policies.approve et un warrant de double contrôle ou jugé. enforce, ingest et status n'ont pas de rôle propre.
Limites et mesure
Le check run et le statut ne sont publiés que si un identifiant PAT ou App est lié ; sinon les deux champs valent null.
status renvoie les 50 derniers éléments ingérés, filtrés par repo ou sha si fourni.
revoke sans warrant renvoie 403, car les routes protégées par warrant sont fermées par défaut.
namespace prend actorDid et branch ; sans acteur il renvoie 400.
Accès
API et MCP
REST et MCP
Authentifiez-vous avec une clé d’API d’espace de travail comme jeton Bearer. L’URL de base est https://api.intramedial.com.
Points d’accès REST
POST/api/v1/acp/github/enforceAdmettre une action sur un dépôt et publier le verdict sur GitHub.
POST/api/v1/acp/github/ingestEnregistrer un webhook GitHub et appliquer les événements qui l'exigent.
GET/api/v1/acp/github/statusLire les éléments d'audit récents, le dernier head et le détenteur de l'épingle.
POST/api/v1/acp/github/revokeRetirer l'épingle de sha détenue par l'acteur et publier un échec.
Actions MCP
MCPcoordination.github.enforceAdmettre une action sur un dépôt depuis un agent.
MCPcoordination.github.ingestEnregistrer un corps de webhook depuis un agent.
MCPcoordination.github.statusLire les éléments d'audit GitHub récents depuis un agent.
Module du plan
