Röviden: A Microsoft Agent Governance Toolkit (AGT) az ágensszabályzatokat futtatható kontrollokká alakítja. A YAML-szabályzatokat még azelőtt kiértékeli, hogy az eszközhívások, üzenetküldések és delegálások elérnék a hálózatot; azonosítja a kérést indító ágenst; rögzíti az aktív szabályzatot, a kérést és a döntést; és GovernanceDenied kivételt dob, ha egy műveletet letilt. Nem helyettesíti az IAM-et és az OAuth-t, hanem kiegészíti őket.
- Az ágensek irányítását kezelje kikényszerítési határként, ne szabályzati dokumentumként: a kontrollnak még azelőtt kell lefutnia, hogy a művelet elérné a hálózatot.
- Tartsa külön az identitást és az engedélyezést. Az IAM és az OAuth a szolgáltatásokhoz való hozzáférést biztosítja, míg az AGT az ágens által kért műveletet értékeli ki.
- YAML-szabályzatokkal fejezze ki a különböző kockázatkezelési módokat, beleértve az alapértelmezett engedélyezést, a drop, delete és truncate műveletek tiltását, valamint az e-mail-küldés jóváhagyáshoz kötését.
- Az auditálhatóság a kikényszerítés része: az aktív szabályzatot, az ágens kérését és az engedélyező vagy tiltó döntést együtt őrizze meg.
- Ne tekintse a toolkit bevezetését az irányítás bizonyítékának, ha csapata nem tudja éles környezetben működtetni az identitás-, naplózási és szabályzati kontrollokat.
Egy autonóm ágensnek, amely eszközöket hívhat, üzeneteket küldhet vagy munkát delegálhat, többre van szüksége egy szabályzati dokumentumnál. Olyan kontrollokra van szüksége, amelyek még azelőtt lefutnak, hogy egy művelet elérné a hálózatot. A Microsoft Agent Governance Toolkit: az AI-szabályzatokból kikényszerített kontrollok című anyag az AGT-t az autonóm AI-ágensek szabályzat-kikényszerítésének, zero-trust identitásának, futtatási sandboxingjának és megbízhatósági mérnökségének infrastruktúrájaként írja le.
A Microsoft Agent Governance Toolkit (AGT) az ágensszabályzatokat futtatható kontrollokká alakítja. A YAML-szabályzatokat még azelőtt kiértékeli, hogy az eszközhívások, üzenetküldések és delegálások elérnék a hálózatot; azonosítja a kérést indító ágenst; rögzíti az aktív szabályzatot, a kérést és a döntést; és GovernanceDenied kivételt dob, ha egy műveletet letilt. Nem helyettesíti az IAM-et és az OAuth-t, hanem kiegészíti őket.
A Microsoft AI Agent Governance Toolkit repository az irányítást control plane problémaként kezeli. A hasznos teszt nem az, hogy egy szabályzat leírja-e az elfogadható viselkedést, hanem az, hogy a rendszer képes-e kikényszeríteni ezt a szabályzatot, azonosítani a kérést indító ágenst, és bizonyítékot előállítani arról, hogy a döntés megtörtént.
Mit kell a Microsoft Agent Governance Toolkitnek bizonyítania egy ágensről?
A Microsoft Agent Governance Toolkit három kérdés köré épül: engedélyezett-e egy ágens művelete, melyik ágens hajtotta végre, és igazolható-e az esemény manipulációbiztos nyilvántartással. Ezek különálló szempontok: engedélyezés, identitás és auditálhatóság.
Az OAuth-scope-ok és IAM-szerepkörök a szolgáltatásokhoz való hozzáférést szabályozzák, de nem határozzák meg, mit tesz az ágens a csatlakozás után. A megosztott API-kulcsok többágenses rendszerekben további problémát okoznak, mert megnehezítik az incidensek hozzárendelését, ha több ágens ugyanazt a hitelesítő adatot használja.
Az AGT az aktív szabályzatot, az ágens kérését és az engedélyező vagy tiltó döntést auditnaplóban rögzíti. A nyilvántartás így magának a kontrollnak a része, nem csupán utólag generált jelentés.
A forrás szerint a toolkit az OWASP Agentic Top 10 mind a 10 területét lefedi, és megfeleltetéseket ad a NIST AI RMF 1.0, az EU AI Act és a SOC 2 követelményeihez. Ezek a forrás által közölt megfeleltetések auditbizonyítékkal vagy auditnapló-exporttal. Nem bizonyítják, hogy egy szervezet megfelel az előírásoknak, vagy hogy minden ágenskockázatot kezeltek.
Miért nem elegendő önmagában az IAM, az OAuth és a prompt szintű biztonság?
Az IAM és az OAuth a szolgáltatás-hozzáférés kérdésére ad választ. Arra nem, hogy egy adott ágensnek végre kell-e hajtania egy adott műveletet a hozzáférés megadása után. Az AGT ezen a műveleti szinten működik; nem helyettesíti a hitelesítő adatokat és hozzáférési kontrollokat, hanem kiegészíti őket.
A prompt szintű biztonságnak más a korlátja. A prompt injection elleni és a modellrétegbeli védelmek valószínűségi alapúak. Befolyásolhatják a viselkedést, de nem adnak determinisztikus határt azokhoz a műveletekhez, amelyeket következetesen tiltani kell.
Az AGT a kikényszerítést az alkalmazáskódba helyezi át. Ez működtetési kötelezettséggel jár: a csapatnak kezelnie kell az ágensidentitásokat, karban kell tartania a szabályzatokat, működtetnie kell a naplózást, és kezelnie kell a jóváhagyási vagy tiltási folyamatokat. Egy irányítási csomag nem pótolhatja azokat a kontrollokat, amelyeket éles környezetben senki sem tud működtetni vagy megfigyelni.
Mikor ne tekintse egy csapat ezt a toolkitet az irányítás megoldásának? Ha nem tudja éles környezetben működtetni az identitást, a naplózást és a szabályzat-kikényszerítést, akkor az AGT-t nem szabad az irányítás bizonyítékának tekintenie. Ha egy nem megfigyelhető ágensrendszerhez szabályzatfájlt ad, az hamis biztonságérzetet kelt.
Hogyan tiltja le az AGT az engedély nélküli ágensműveleteket?
Az AGT minden eszközhívást, üzenetküldést és delegálást determinisztikus alkalmazáskódban fog el, még mielőtt a modell szándéka elérné a hálózatot. Ha az AGT kernel megtagad egy műveletet, az strukturálisan le van tiltva, nem egy későbbi ellenőrzési lépésre marad.
Ez a különbség egy utasítás és egy kikényszerítési pont között. Egy prompt megmondhatja az ágensnek, hogy jóváhagyás nélkül ne küldjön e-mailt. Egy alkalmazásszintű szabályzat viszont leállíthatja az üzenetküldési műveletet, és olyan tiltást bocsáthat ki, amelyet a körülötte lévő rendszer megvizsgálhat.
Ez a határ specifikus, nem univerzális. A determinisztikus elfogás nem old meg minden ágenskockázatot, és önmagában nem teszi biztonságossá a mögöttes eszközt. A kontroll érvényesüléséhez a releváns hívásoknak, üzeneteknek és delegálásoknak át kell haladniuk az AGT-n.
Az értékelési kérdés egyszerű: képes-e a csapat minden fontos szabályzatot egy olyan determinisztikus kontrollhoz rendelni, amely még azelőtt lefut, hogy a művelet elhagyná az alkalmazást? Ha nem, akkor dokumentációja van, nem kikényszeríthető irányítása.
Hogyan kezdjen hozzá a Python SDK-val?
A gyors kezdéshez Python 3.11 vagy újabb szükséges. A teljes csomagot így telepítheti:
pip install "agent-governance-toolkit[full]"
Egy eszközfüggvény két sor Pythonnal az irányítás alá vonható:
from agentmesh.governance import govern
safe_tool = govern(my_tool, policy="policy.yaml")
Minden hívás kiértékeli a YAML-szabályzatot, a döntést auditnaplóba írja, és GovernanceDenied kivételt dob, ha a műveletet letiltja.
A toolkit egyetlen pip-telepítéssel bármilyen keretrendszert támogat. Ez akkor hasznos, ha a mérnöki feladat az, hogy a meglévő eszközök és munkafolyamatok köré egységes irányítási határt húzzon, nem pedig egy másik ágenskeretrendszer kiválasztása.
Ne tévessze össze a rövid integrációt egy teljes működési modellel. A használat kiterjesztése előtt jelölje ki a felelősöket az ágensidentitásért, a szabályzatmódosításokért, az auditnyilvántartásokért, a jóváhagyási folyamatokért és a kikényszerítési hibákért.
Mit engedélyezhetnek, tilthatnak vagy követelhetnek meg az AGT-szabályzatok?
Az AGT-szabályzatok alapértelmezetten engedélyezhetik a műveleteket, tilthatják a destruktív műveleteket, vagy jóváhagyáshoz köthetnek kiválasztott műveleteket. A forrás három konkrét viselkedést említ:
- Alapértelmezetten engedélyezi a műveleteket, ahol ez a szabályzat megfelelő.
- Tiltja az olyan destruktív műveleteket, mint a
drop, adeleteés atruncate. - Jóváhagyáshoz köti az olyan műveleteket, mint az e-mail-küldés.
Minden irányított hívás kiértékeli a YAML-szabályzatot, és rögzíti az eredményt. Ha egy hívást megtagad, aGovernanceDeniedegyértelmű hibajelzést ad az alkalmazásnak, ahelyett hogy a művelet csendben folytatódna.
A jóváhagyási szabályok működési költséggel járnak, mert emberi vagy munkafolyamat-függőséget vezetnek be olyan műveleteknél, amelyek egyébként automatikusan lefutnának. E-mail-küldésnél vagy más érzékeny műveletnél ez lehet a helyes kompromisszum, de a jóváhagyási folyamatot működtetni kell, nem elég beállítani.
Ugyanez igaz az auditálhatóságra. Egy letiltott hívás csak akkor hasznos, ha a csapat meg tudja vizsgálni, mit tiltottak le, melyik szabályzat volt aktív, melyik ágens kérte, és milyen döntés született. Az AGT ezeket az elemeket együtt rögzíti, de az auditnapló megőrzése, a hozzáférés és az átvizsgálás továbbra is a csapat felelőssége.
Hogyan bővíti az irányítást az AgentControl API?
Az AgentControl API a Python wrapperen túl programozott szabályzat-kiértékelést biztosít. Tartalmaz egy Agent Control Specification manifestet és egy ágensidentitás-borítékot (identity envelope), így az alkalmazás- és platformfolyamatok explicit artefaktumokat kapnak a kontrollelvárásokhoz és az identitáskontextushoz.
A toolkit SDK- és integrációs példákat is tartalmaz TypeScripthez, .NET-hez, Rusthoz és Góhoz, valamint MCP-szerver-integrációt. A Claude Code a plugin marketplace-én keresztül használhatja az AGT-t. Ezek a lehetőségek szélesítik a megvalósítási felületet, de nem szüntetik meg az identitások, szabályzatok, naplók és kikényszerítési hibák működtetésének szükségességét.
Minden éles környezetben dolgozó csapatnak megfelel a toolkit?
Az AGT nyilvános előzetes (public preview) állapotban van, így az általános elérhetőség előtt a kiadások törő változásokat (breaking changes) tartalmazhatnak. A kritikus ágensfolyamatokhoz értékelő csapatoknak számolniuk kell a verziókezeléssel és a frissítések tesztelésével.
Akkor értékelje a toolkitet, ha az autonóm műveletek körül futtatható szabályzati döntésekre, ágensidentitásra, determinisztikus elfogásra és exportálható auditbizonyítékra van szüksége. Ne használja olyan működési modell helyettesítésére, amelyet csapata nem tud fenntartani.
Az irányítás csak akkor hiteles, ha a kontrollok aktívak, megfigyelhetők és karbantartottak. Az AGT biztosíthatja a kikényszerítési mechanizmust és a döntés körüli nyilvántartást. Az identitások, szabályzatok, integrációk, auditműveletek és a tiltás vagy hibás konfiguráció esetén szükséges reakció továbbra is a csapat felelőssége.
Gyakran ismételt kérdések
Helyettesíti az AGT az IAM-et vagy az OAuth-t?
Nem. Az IAM-szerepkörök és az OAuth-scope-ok a szolgáltatás-hozzáférést szabályozzák, míg az AGT azt értékeli ki, mit tesz az ágens a csatlakozás után. A hitelesítő adatok biztosítják a hozzáférést; a szabályzat-kikényszerítés dönti el, hogy egy adott eszközhívás, üzenetküldés vagy delegálás engedélyezett-e.
Nyújthatnak a promptutasítások ugyanolyan védelmet, mint az AGT?
Nem. A prompt injection elleni és a modellrétegbeli védelmek valószínűségi alapúak, ezért nem elegendők a determinisztikus tiltáshoz. Az AGT az eszközhívásokat, üzenetküldéseket és delegálásokat az alkalmazáskódban fogja el, mielőtt a modell szándéka elérné a hálózatot, a megtagadott műveleteket pedig a kernele strukturálisan letiltja.
Mit rögzít az AGT egy audithoz?
Az AGT az aktív szabályzatot, az ágens kérését és az engedélyező vagy tiltó döntést auditnaplóban rögzíti. Minden irányított hívás kiértékeli a YAML-szabályzatot, naplózza az eredményt, és tiltás esetén GovernanceDenied kivételt dob. A csapatoknak ezeket a nyilvántartásokat továbbra is megfelelően működtetniük és megőrizniük kell.
A toolkit megfelelőségi tanúsítványnak számít?
Nem. A forrás megfeleltetéseket közöl az OWASP Agentic Top 10, a NIST AI RMF 1.0, az EU AI Act és a SOC 2 vonatkozásában. Ezek a megfeleltetések és az auditbizonyítékok támogathatják az értékelést, de nem tanúsítják a megfelelőséget, és nem teszik szükségtelenné a szervezeti kontrollokat.
A legfontosabb tanulságok
- Az ágensek irányítását kezelje kikényszerítési határként, ne szabályzati dokumentumként: a kontrollnak még azelőtt kell lefutnia, hogy a művelet elérné a hálózatot.
- Tartsa külön az identitást és az engedélyezést. Az IAM és az OAuth a szolgáltatásokhoz való hozzáférést biztosítja, míg az AGT az ágens által kért műveletet értékeli ki.
- YAML-szabályzatokkal fejezze ki a különböző kockázatkezelési módokat, beleértve az alapértelmezett engedélyezést, a drop, delete és truncate műveletek tiltását, valamint az e-mail-küldés jóváhagyáshoz kötését.
- Az auditálhatóság a kikényszerítés része: az aktív szabályzatot, az ágens kérését és az engedélyező vagy tiltó döntést együtt őrizze meg.
- Ne tekintse a toolkit bevezetését az irányítás bizonyítékának, ha csapata nem tudja éles környezetben működtetni az identitás-, naplózási és szabályzati kontrollokat.
Gyakorlati tippek
- Tesztelje a Python wrappert egy megtagadott destruktív műveleten, mielőtt kritikus munkafolyamathoz kapcsolná.
- Határozza meg a szabályzatfájlok, az ágensidentitás-borítékok, a jóváhagyási folyamatok és az auditnapló-megőrzés felelőseit, mielőtt kiterjesztené az integrációt.
- Ellenőrizze, hogy minden releváns eszközhívás, üzenetküldés és delegálás áthalad-e a kikényszerítési rétegen; az elfogás csak ott érvényesül, ahol a forgalom áthalad rajta.
- Mivel a toolkit nyilvános előzetes állapotban van, frissítés előtt építse be a kiadási folyamatba a törő változások tesztelését.
Értékelje a kontrollhatárt
Kezdjen egyetlen irányított eszközzel, és ellenőrizze a teljes útvonalat: szabályzat-kiértékelés, ágensidentitás, tiltási viselkedés és auditbizonyíték. Csak akkor bővítsen, ha csapata megbízhatóan tudja működtetni ezeket a kontrollokat.