Ha egy agent céges adatot olvas, e-mailt küld, rekordot módosít vagy jóváhagyást kezdeményez, adj neki önálló identitást, szűk jogokat és lejáró hozzáférést. Ezt a meglévő identitáskezeléssel, API-jogosultságokkal és jóváhagyási szabályokkal is megteheted.
A Microsoft 2026. október 19-én bejelentette a Dynamic Permissions, a Dynamic Agent Risk és a Dynamic Conditional Access nevű képességeket. A Dynamic Permissions a leírás szerint feladathoz és időtartamhoz kötné az agent jogait. Kizárólag e bejelentés miatt még ne válts Microsoft 365 E7-re: előbb kérd el írásban a termékstátuszt és az EU-s elérhetőséget.
Miért kell különválasztanod az agent és a felhasználó jogait?
Egy munkatárs hozzáférése általában több feladatot és rendszert fed le, mint amennyire egy agentnek szüksége van. Ha az agent automatikusan megkapja ezeket a jogokat, egy hibás eszközhívás vagy manipulált bemenet olyan adatot és műveletet is elérhetővé tehet, amely nem tartozik a kijelölt feladathoz.
A Microsoft október 19-i biztonsági bejelentése szerint az agent hibázhat, manipulálható vagy feltörhető, és a viselkedése a kontextus változásával módosulhat. A javasolt modellben minden agent önálló identitást kap, amely független az agentet használó vagy az érte felelős embertől.
A gyártó egy költségelszámolást jóváhagyó agenttel mutatja be a problémát. Az agent olvashatja a benyújtott elszámolásokat, ellenőrizheti a szabályzatot és kezelheti a rutineseteket. Az agentért felelős munkatárs teljes hozzáférésére ehhez nincs szüksége. Az önálló identitás abban is segít, hogy a napló elkülönítse a munkatárs saját műveletét attól, amit az agent végzett a nevében.
Ha az agent internetet vagy külső eszközöket használ, a külső műveletek korlátozásáról szóló útmutató további teszteseteket ad.
Mit jelentene a Dynamic Permissions a gyakorlatban?
A Microsoft leírásában a szervezeti szabályzat adja a külső határt: az agent nem kaphat olyan jogosultságot, amellyel a felhasználó sem rendelkezik. Ezen belül a hozzáférés a feladatra és meghatározott időre szűkíthető. A feladat változásakor a jogok csökkenthetők, a befejezésekor pedig visszavonhatók. A nagyobb következménnyel járó műveletekhez igazolt emberi jóváhagyás kérhető.
A bejelentett Dynamic Agent Risk az identitásból, az adatokból, a végpontokból, a cloud-környezetből, a hálózatból, a futtatókörnyezetből és az agent aktivitásából származó jeleket kapcsolná össze. A hozzá tartozó Dynamic Conditional Access erre válaszul csökkenthetné a jogosultságot, megtarthatná az olvasást az írás letiltása mellett, szűkíthetné az elérhető erőforrásokat, vagy leállíthatná a futást.
A táblázat a bejelentés elveit pilot- és beszerzési követelményként foglalja össze.
| Ellenőrzési pont | Elvárt beállítás | Pilotban ellenőrizendő |
|---|---|---|
| Identitás | Az agent saját azonosítót kap | A napló elkülöníti az agent és a felhasználó műveleteit |
| Jogosultság | Csak a jóváhagyott feladathoz szükséges jogokat kapja meg | Nem ér el más postafiókot, fájlt vagy üzleti rendszert |
| Időkorlát | A hozzáférés a feladat végén lejár | A korábbi tokennel nem folytatható a művelet |
| Írási művelet | A következményekkel járó lépéshez emberi jóváhagyás kell | A jóváhagyás hiányában az írás meghiúsul |
| Kockázati válasz | Az olvasás és az írás külön korlátozható | Gyanús bemenetnél megszűnik az írási jog, miközben az ellenőrzéshez szükséges olvasás megmarad |
Forrás: a Dynamic Permissions és Dynamic Conditional Access gyártói leírása.
Hogyan alkalmazd ezt egy pénzügyi jóváhagyásnál?
A költségelszámolási példa közvetlenül alkalmazható egy Microsoft 365-ben futó jóváhagyási folyamatra. Az agent önálló identitással olvassa az elszámolást és a rá vonatkozó szabályzatot. A hozzáférése nem terjed ki a szabályzat módosítására, a beszállítói törzsadatokra vagy más munkatársak teljes pénzügyi mappáira.
A rutinszerű ellenőrzés után az agent javaslatot készíthet. A kifizetést engedélyező döntés maradjon egy kijelölt munkatársnál. A napló mutassa meg a felhasznált adatokat, az agent műveleteit és az emberi döntést.
A pilotban adj az agentnek manipulált dokumentumot, illetve olyan bemenetet, amely a feladattól eltérő eszközhívást próbál elindítani. A megfelelő kontroll ilyenkor letiltja az írást, megőrzi a vizsgálathoz szükséges adatokat, és emberi döntést kér a folytatáshoz.
Ha a folyamat kizárólag Teams- és SharePoint-tartalmak összefoglalására szolgál, kevesebb egyedi integráció is elegendő lehet. A Copilot és az egyedi automatizálás közötti döntési útmutató segít meghatározni, mikor lépi át a folyamat ezt a határt.
Ha saját agentet tervezel, a jogosultságokat és az emberi jóváhagyási pontokat már a rendszertervben rögzítsd. AI agent fejlesztés
Mennyibe kerül az Agent 365?
A Microsoft 2026. május 1-jei Agent 365-oldala havi 15 dolláros felhasználónkénti árat közölt az önálló változatra. Az Agent 365 a Microsoft 365 E7 részeként is elérhető volt üzleti ügyfeleknek. Egy licenc azt az embert fedi le, aki agentet kezel vagy felel érte, illetve agentet használ a munkájához. A licencigényt ezért az érintett emberek száma határozza meg.
A májusi termékoldal a háttérben, saját hozzáféréssel futó agenteket általánosan elérhetőként sorolta fel. A csapatmunkában részt vevő agentek Public Preview státuszban voltak. A Windows 365 for Agents akkor csak az Egyesült Államokban volt elérhető, Public Preview keretében.
A Microsoft biztonsági blogja az október 19-i képességeket a Microsoft 365 E7 és a Project Perception újdonságaiként mutatja be. Az egyes funkciók SKU-besorolása, bevezetési dátuma, EU-s elérhetősége és ára nincs felsorolva. A Project Perceptionről szóló vállalati bejegyzés szerint a rendszert 2026 júliusában jelentették be; az októberi leírás Guardian Agents és folyamatos felügyelet használatát vázolja fel.
Kérd, hogy a viszonteladói ajánlatban szerepeljen a képességek termékstátusza, a szükséges SKU, az EU-s tenantokra vonatkozó elérhetőség és a licenccel lefedendő emberek meghatározása.
Mikor érdemes várni az E7-beszerzéssel?
Ha egy agent már e-mailt küld, adatot módosít, jóváhagyást végez vagy üzleti rendszerben hajt végre műveletet, a jogosultságait most szűkítsd a meglévő eszközökkel. Az önálló identitás és a legkisebb szükséges jogosultság már beállítható.
Ha még nincs agent a cégnél, először készíts leltárt és jogosultsági szabályzatot. Akkor várj a beszerzéssel, ha kizárólag a Dynamic Permissions vagy a Project Perception miatt fizetnél elő, és a termékfeltételek még nem szerepelnek az ajánlatban.
A Microsoft szerint 35 új helyi agent-típussal bővíti a felderítést, így összesen 60 típust támogat, köztük a Claude Code-ot, az OpenAI Codexet és a GitHub Copilotot. Ha ilyen eszközök futnak a fejlesztői gépeken, elsőként azonosítsd a tulajdonosukat, a használt identitást és az elérhető erőforrásokat.
Milyen ellenőrzésekkel zárd le a pilotot és a beszerzést?
- A leltárban minden agent mellett szerepeljen a tulajdonos, az üzleti cél, a futtatási hely és a kapcsolódó rendszerek listája.
- Exportáld az agent és az érte felelős felhasználó jogait. Vedd el azokat, amelyek nem szükségesek a kijelölt feladathoz.
- Teszteld külön az olvasást, az írást, a feladattól eltérő eszközhívást és a prompt injection utáni viselkedést. A napló külön mutassa az agent műveleteit a felhasználóéitól.
- Pénzmozgás, adattörlés, jogosultságmódosítás és külső félnek küldött információ előtt kérj emberi jóváhagyást.
- A beszerzési döntést csak olyan ajánlat alapján hozd meg, amely megadja a termékstátuszt, a SKU-t, az EU-s tenant elérhetőségét és a licencelés alapját.