Intramedial è in beta ristretta. Alla registrazione o all’accesso devi fornire la password da beta tester che hai ricevuto oppure richiederne una a preview@intramedial.com. Grazie.
Caricamento…
coordination.admitModulo 01
Modulo della piattaforma
Intralock admission
Decidi ogni azione prima che avvenga: un agente dichiara il suo intent, e Intralock lo ammette o indica il motivo per cui non può.
coordination.admit è il percorso rapido della piattaforma. Un agente invia il suo DID, la risorsa e il verbo, e Intralock valuta quell’intent rispetto allo snapshot di policy compilato, alle quarantene e agli interruttori di stop. La risposta è un allow o un deny con un motivo, senza chiamate di rete né LLM.
Gli agenti agiscono quando il piano dice sì, e il registro dice perché.
Fai passare da Intramedial azioni di agenti, hash di contenuti, controlli API, lookup DNS, webhook, chiamate LLM e commit git. Ricevi una ricevuta firmata che chiunque verifica, senza fidarsi di noi.
grant su un allow; su un deny il codice che lo spiega, come quarantine o confirmation_required.
enforced
Se la classe di risorsa era in enforce, quindi il verdetto si è davvero applicato alla chiamata.
Meccanismo
Passo dopo passo
Come funziona
L’agente dichiara l’intent
Invia actorDid, resource e action a POST /api/v1/acp/coordination/admit prima di agire. Una scrittura o cancellazione porta anche un confirmationToken monouso.
Prima girano i controlli della piattaforma
Un attore in quarantena è rifiutato con quarantine, e una risorsa fermata con resource_halted. Una scrittura senza token valido è rifiutata con confirmation_required e finisce nella coda di approvazione.
Intralock valuta lo snapshot
L’intent è verificato rispetto ai grant compilati dello snapshot di policy. Il kernel è una funzione pura: stesso intent, stesso snapshot, stesso verdetto.
La fase di adozione modella la risposta
Una classe di risorsa gira in observe, advise, transform o enforce. Solo enforce può negare; le fasi precedenti riportano cosa avrebbe deciso enforce e lasciano passare la chiamata.
La decisione va nel log
La decisione è scritta dopo la risposta, mai prima, quindi il logging non aggiunge nulla al percorso rapido. Anche una decisione che ha superato il budget di tempo è registrata.
Premi Esegui (o ⌘/Ctrl + Invio) per firmare la richiesta a sinistra.
La prima esecuzione crea una chiave di test gratuita nel browser: circa 35 chiamate in 7 giorni, senza account. La ricevuta torna qui ed è verificata con le chiavi pubblicate, senza fidarsi di noi.
Codice
Esempio live
Una richiesta reale
Una richiesta nella forma accettata dall’API e una risposta di esempio nella forma restituita dal modulo.
Un agente di rilascio e un bot delle dipendenze vogliono entrambi repo:payments/main. Entrambi dichiarano prima, così il secondo riceve un motivo e un detentore da attendere, invece di un push fallito.
Una persona sul passo rischioso
Un agente può leggere una tabella liberamente, ma un delete richiede un token. Il rifiuto crea una richiesta di approvazione, e l’agente riprende quando qualcuno firma.
Adottare senza rompere nulla
Metti una classe di risorsa in observe, leggi per una settimana cosa avrebbe deciso enforce, poi alza solo quella classe.
Un rifiuto su cui un agente può agire
Il reason permette a un agente di prendere un’altra strada o fermarsi a chiedere, invece di ripetere in loop la stessa chiamata negata.
Quando usare altro
Pianificare il lavoro dentro il workflow di un team. L’ammissione decide se un’azione può avvenire, non quale task giri dopo.
Tenere una risorsa su più passi. L’ammissione risponde a un intent; usa coordination.lease per tenerla.
Fermare un agente che non dichiara mai. Metti un punto di applicazione come mcp.enforce o github.enforce sul suo percorso.
Prove
Garanzie
Cosa fa e cosa non fa
Un modulo è una promessa forte su una cosa circoscritta. Contaci esattamente per ciò che è.
Fa
Ogni intent che la raggiunge ottiene un verdetto dallo stesso kernel deterministico, senza modelli.
Una scrittura o cancellazione in enforce non passa senza un token di conferma monouso legato a quell’attore, risorsa e verbo.
Un agente in quarantena resta rifiutato sulle classi protette, qualunque cosa dica la fase di adozione.
Ogni decisione registra il verdetto, il motivo e se è stata applicata.
Non fa
Che l’agente abbia fatto ciò che ha dichiarato. Confronta gli intent con gli effetti osservati in detection.run.
Che un agente non possa agire aggirando la piattaforma. L’ammissione vincola solo le azioni che passano da un punto di applicazione.
Che la policy sia giusta. Intralock applica i mandati compilati esattamente come scritti; riproducili in mandates.compile.
Dettagli
Note di sviluppo
Prima di costruire
Budget di tempo
Il budget del kernel è 5 ms p99 per il suo lavoro e 15 ms su una richiesta con chiamate a Durable Object. Entrambi sono impostati nel codice e verificati nei test; i campioni oltre il budget sono registrati.
Comportamento in caso di guasto
Ogni classe di risorsa dichiara fail-open o fail-closed. Se lo store del kill switch non può essere letto, la risposta lo dice in killSwitch.readable invece di nasconderlo.
Classi protette
KMS, identità, ledger e fatturazione restano in enforce. La scala di adozione non può essere usata per aprirle.
Limiti e misurazione
Ogni decisione di ammissione conta come un’azione coordinata, qualunque sia l’esito. Le letture della mappa e della presenza non contano.
Un token di conferma è monouso; riprodurne uno è rifiutato con confirmation_replay.
I campioni oltre il budget sono registrati per l’operatore; un’ammissione lenta non è rifiutata perché lenta.
Accesso
API e MCP
REST e MCP
Autenticati con una chiave API del workspace come token Bearer. L’URL di base è https://api.intramedial.com.
Endpoint REST
POST/api/v1/acp/coordination/admitDecidi un intent dichiarato.
POST/api/v1/acp/coordination/confirmEmetti un token di conferma monouso per una scrittura o cancellazione.
Azioni MCP
MCPcoordination.admitDecidi un intent dichiarato.
MCPcoordination.confirmEmetti un token di conferma per una scrittura o cancellazione.
Modulo della piattaforma
