Agenttipinossa on neljä kerrosta. Useimmista käyttöönotosta puuttuu kolme

Identiteetin, maineen, valtuutuksen ja maksun on oltava ketjussa. Monissa tuotantokäyttöönotossa ne eivät vielä ole, ja se on arkkitehtoninen ongelma, ei compliance‑jälkivaikutus.

Käytän paljon aikaa tarkastellessani, miten tuotantoympäristön agenttien käyttöönotot on todellisuudessa kytketty yhteen, ja malli on usein sama: malli on kykenevä, orkestrointikehys on kohtuullinen, mutta autentikointikerros on yhä jaettu API-avain, jota ei ole vaihdettu kuukausiin.

Autonomisen agentin infrastruktuuri ei ole pysynyt mukana sen päällä toimivien mallien kanssa. Agenttipinossa on neljä komponenttia, jotka täytyy olla natiivisti ketjussa: identiteetti, maine, valtuutus ja maksu. Useimmissa näkemissäni tuotantokäyttöönotossa ne on edelleen kiinnitetty jälkikäteen, jos ne ylipäätään ovat olemassa.

Ja tämä on tärkeämpää säännellyssä rahoituksessa kuin missään muualla. Agentin, joka voi tehdä kauppaa tokenisoiduilla arvopapereilla, hyväksyä valtionvarainhoitotoimenpiteitä tai allokoida eri positioiden välillä, täytyy pystyä näyttämään, mitä se on saanut valtuutuksen tehdä, kuka sen valtuutti, millä rajoilla ja missä ketjussa oleva rekisteri siitä valtuutuksesta sijaitsee. Useimmat käyttöönotot eivät pysty vastaamaan tähän selkeästi tänään. Ilman tätä rekisteriä itse agentti on tarkastus- ja compliance‑riski.

Miksi jaetut API-avaimet ovat väärä periaate

Useimpien agenttien käyttöönottojen perimä autentikointimalli SaaS:ista on jaettu salaisuus, joka välitetään otsakkeessa. Se todentaa kutsuvan palvelun, mutta ei kerro mitään siitä, mikä tietty agentti tekee kutsun tai mihin agentti on oikeutettu, eikä se jätä jälkeä, joka selviäisi tarkastuksesta sellaiseen muotoon, jonka sääntelijä voi tarkastaa. Jokainen agentin toiminto voidaan liittää vain siihen, joka avaimen hallussa, mikä käytännössä tarkoittaa, että attribuutio romahtaa, kun on enemmän kuin yksi agentti tai operaattori.

Vaihtoehto on allekirjoituspohjainen pyyntökohtainen selvitys. Jokainen pyyntö allekirjoitetaan agentin omalla lompakolla ja se selvitetään kryptografisesti kutsun yhteydessä. Tämä on juuri se, mitä x402 on rakentanut, yhdistäen autentikoinnin ja maksun. Tämä antaa instituutioille rekisterin siitä, mikä lompakko toimi, milloin se toimi ja mitä se maksoi, kirjanpito, joka kestää tarkastuksen.

Identiteettivaje

ERC-8004 määrittelee ketjussa olevan identiteetin luottamattomille agenteille: rekisteri, jossa agentti on rekisteröity hallitsevan lompakon, palvelupisteen ja malliviitteen kanssa. Tällä hetkellä kyseinen agentti on vain läpinäkymätön prosessi, joka toimii toimittajan infrastruktuurissa. Rekisterimerkintä tekee siitä ensiluokkaisen ketjussa toimivan toimijan, jonka alkuperä on tarkistettavissa — älysopimus tai compliance‑hallintapaneeli voi tarkistaa sen suoraan ilman välikäden luottamista.

Mainekerros rakentuu tämän päälle. ERC-8004‑rekisteriin kirjoitetut palautesignaalit ovat muuttumattomia, aikaleimattuja ja attribuoitavissa. Mikä tahansa järjestelmä, joka haluaa tehdä luottamuspäätöksiä agentista, voi lukea rekisterin suoraan. Toisin kuin toimittajan hallinnoima pisteytys tai Discord‑arviointi, luottamus täällä on verkon ominaisuus eikä sen, joka hallitsee tietokantaa.

Molemmat kerrokset ovat toteutettavissa tänään ilman eksoottista tekniikkaa. Useimmissa käyttöönotossa niitä ei ole, koska vähiten vastustusta aiheuttava toteutustapa on edelleen käsitellä agentteja palvelutilinä eikä ensiluokkaisina toimijoina. Kohtuullinen kiertotie prototyypissä muuttuu arkkitehtoniseksi velaksi, joka kasvaa tuotannossa.

Valtuutusongelma on se kohta, jossa säännelty rahoitus eroaa kaikesta muusta

Identiteetti ja maine kertovat, kuka agentti on ja miten se on käyttäytynyt. Ne eivät määritä, mihin agentti on valtuutettu. Monissa agenttien käyttötapauksissa sovelluskerroksen kontrollit voivat kattaa tämän aukon. Säänneltyjen omaisuuserien kanssa toimiville agenteille valtuutuskysymys muuttuu oikeudelliseksi kysymykseksi. Vastaus täytyy olla muodossa, joka voi täyttää sääntelijän vaatimukset.

ERC-8226, säänneltyjen agenttien valtuutusstandardi (RAMS), on suunniteltu sulkemaan tämä aukko. RAMS määrittelee compliance‑delegointikerroksen, joka sijaitsee agentin identiteetin ja token‑tasojen compliance‑kehyksen välissä. KYC‑vahvistettu pää antaa agentille valtuutuksen, jossa on määritelty laajuus, toimivalta, arvorajat ja voimassaoloaika. Käytännössä se toimii kuin ketjussa oleva valtakirja, joka voidaan tarkistaa ennen selvitystä. Säännelty token‑sopimus tarkistaa sitten valtuutuksen atomisesti ennen siirtoa compliance‑koukussaan ennen kuin mitään selvitystä tapahtuu.

Kaksi rajapintaa toteuttavat suunnitelman. `ComplianceProvider` toteutetaan millä tahansa KYC‑ tai vahvistusoperaattorilla, ja se takaa päähenkilön kelpoisuuden tiettyyn laajuuteen. `IAgentMandate` on rekisteri, joka kirjaa myönnytykset, jatket, peruutukset, toteutukset ja sääntelijätason jäädytykset. Valvonta tapahtuu `recordExecution`‑toiminnon kautta, joka tarkistaa aktiivisen valtuutuksen rajoitukset siirtoajankohtana ja peruuttaa, jos transaktio ylittäisi ne.

Tämä arkkitehtuuri sijoittuu ERC-8004‑identiteetin ja token‑compliance‑kehysten, kuten ERC-7943, väliin korvaamatta kumpaakaan. Identiteetti kertoo, että agentti on olemassa ja tarkistettavissa; token‑compliance, että päähenkilö on oikeutettu omistamaan tämän erityisen omaisuuden. RAMS lisää sen osan, jota kumpikaan ei kata: valtuus tältä päähenkilöltä, tälle laajuudelle, näiden rajojen sisällä, tähän päivään asti. Laillisesti täytäntöönpanokelpoinen delegointikerros, joka tällä hetkellä elää vain PDF‑tiedostoissa ja taustatoimiston taulukkolaskentaohjelmissa, siirtyy ketjuun, jossa se voidaan toteuttaa siirtoajankohtana.

Valmistelu‑ ja toteutus‑erottelu ei ole kitkaa

Yksi suunnittelupäätös ansaitsee suoran puolustuksen: transaktion valmistelun erottaminen allekirjoituksesta ja lähetyksestä. Tämä poistetaan monissa järjestelmissä, jotka pyrkivät tekemään agenteista sujuvampia.

Instinkti on yhdistää nämä yhdeksi vaiheeksi, koska se tuntuu tehokkaammalta. Mutta valmistelun ja lähetyksen välinen aukko on juuri se, mihin institutionaalinen valvonta kuuluu. Siellä compliance‑virkamies tarkastelee, mitä agentti on aikeissa tehdä ennen kuin ketju saa siitä tiedon, jossa RAMS‑valtuutustarkistus vahvistaa valmistellun sisällön aktiivista laajuutta, arvorajoja ja toimivaltaa vastaan ennen kuin allekirjoitus tuotetaan, ja jossa talousjohtaja (CFO) hyväksyy valtionvarainhoitotoimenpiteen, jonka agentti on valmistellut mutta ei ole vielä sitonut.

Monet merkittävällä mittakaavalla autonomisia agenteja käyttävät instituutiot rakentavat lopulta tämän erottelun uudelleen, kun ne huomaavat sen puuttuvan. Rakentamalla sen sisään tarkoituksellisena arkkitehtonisena periaatteena sen sijaan, että se olisi jälkiasennus, joka kuljettaa järjestelmän läpi ensimmäisen compliance‑tarkastuksen.

Miltä pino näyttää, kun se on valmis

Kun kaikki neljä kerrosta ovat paikalla, ne muodostavat puhtaan kokonaisuuden. ERC-8004 ankkuroi agentin identiteetin ja ketjussa olevan maineen, ja ERC-8226 lisää valtuutuskerroksen, joka rajoittaa, mitä kukin agentti voi tehdä kenen puolesta. x402 hoitaa selvityksen, allekirjoittaen jokaisen pyynnön, jotta jokainen toiminto on attribuoitavissa ja tarkastettavissa. Alla säänneltyjen omaisuuserien kehyksissä, kuten ERC-7943, noudatetaan compliance‑sääntöjä siirtoajankohtana sekä päähenkilön kelpoisuuden että agentin aktiivisen valtuutuksen osalta.

Nämä osat ovat eri kypsyysasteilla, mutta mikään niistä ei ole pelkästään teoreettinen. ERC-8004 on Draft Standards Track -ERC, jossa on käyttökelpoiset identiteetti- ja maine‑primitivet. ERC-7943 on lopullinen Ethereum‑standardi. ERC-8226 on standards track -listalla, ja ydinrajapinnat ovat tarpeeksi vakaita varhaiseen toteutustyöhön. x402 on toiminnassa ja on jo suunniteltu ohjelmallisten HTTP‑maksujen ympärille ihmisille ja agenteille.

Tiimit, jotka saavat tämän oikein, voivat rakentaa tätä pinoa nyt tai odottaa, kunnes tarkastus‑ ja compliance‑paine pakottaa jälkiasennuksen. Ne instituutiot, jotka saavat tämän oikein, ovat ne, jotka käsittelevät valtuutus‑ ja identiteettikerroksia infrastruktuurivaatimuksina alusta alkaen, samalla tavalla kuin ne käsittelevät KYC‑ ja säilytyspalveluita. Sääntelijät eivät ehkä ole vielä erikseen vaatineet kaikkia näitä osia. Tällä alalla tuotantojärjestelmiä rakentavat tiimit tietävät jo, kuinka kalliita nämä kontrollit ovat lisätä jälkikäteen.