Tíz éven át egy dologra tanítottuk a rendszereinket: ismerd fel a botot, és tartsd kint. Jó okkal — a bot terheléses támadást indít, lemásolja a katalógust, lassítja a kiszolgálót, és éjszaka térdre kényszeríti a webshopot.
Ez a veszély ma sem tűnt el; a káros automatizált forgalom továbbra is valós, a védelem továbbra is indokolt. Csakhogy 2026-ra a bot fogalma kettévált. A kód mögött már nem feltétlenül egy támadó ül — egyre gyakrabban egy valódi vásárló áll ott, aki egy ágenst bízott meg, hogy keressen, válasszon és fizessen helyette.
Kártyával, valódi szándékkal, valódi pénzzel. És itt keletkezik a paradoxon: amikor a bot, akit tíz éve kizársz, vásárolni jön, a saját védelmi rendszered utasítja el azt a vásárlót, akit a legjobban szeretnél. Erről az ok-okozatról szól ez a cikk — hogyan lett a védelemből, észrevétlenül, bevételi kockázat, és mit tud ezzel kezdeni egy cégvezető, mielőtt a döntést helyette hozza meg egy beállítás, amit évekkel ezelőtt senki nem erre tervezett.
Mi történik, amikor egy vásárló ágense kopogtat a webshopod ajtaján?
Az ágens lehet fogyasztói vásárló-ágens — egy magánember, aki magának rendel —, vagy üzleti beszerzési ágens (buyer agent), aki beszerzést intéz. Mindkettő ugyanazzal a szándékkal érkezik: vásárolni, terméket vagy szolgáltatást, mert arra kérték.
A jelenség konkrét, és már nem holnapi. A vásárló ma leül egy AI-asszisztenshez, elmondja, mit szeretne, az asszisztens pedig keresni kezd, összeállít egy kosarat, majd a fizetésig viszi a folyamatot.
A háttérben protokollok szabványosítják ezt a mozdulatot: az OpenAI és a Stripe közösen fejlesztett nyílt szabványa, az Agentic Commerce Protocol a ChatGPT-n belül, a Google kereskedelmi protokollja a keresőjében és a Geminiben, a Visa és a Mastercard pedig kifejezetten az ágensek számára tervezett, korlátozott érvényű fizetési tokeneket ad ki.
A Mastercard Agent Pay programot 2025 áprilisában indították, és 2026 elejére élő, hitelesített agentikus tranzakciók zajlottak a hálózatán — Európában elsőként a Santanderrel, szabályozott banki keretben. Ez tehát nem koncepció egy konferencia-színpadról, hanem élő forgalom, amely a te webshopod felé is elindult.
A lényeg, amit egy vezetőnek elsőként érdemes rögzítenie: ez a forgalom a te oldaladról nézve botként jelenik meg. Automatizált kliens, amely gyorsan mozog, szokatlan mintázatot mutat, és nem úgy viselkedik, mint egy ember az egérrel. A mögötte álló szándék viszont a lehető legértékesebb: vásárlás.
Miért utasítja el a rendszered pont a legjobb szándékú vásárlót?
A fal, amit tíz éve építesz
A védelmi réteg, amely ma a webshopodat óvja, egy világos ellenségkép köré épült. A reCAPTCHA, a webalkalmazás-tűzfal és az anti-scraping megoldások mind arra tanultak, hogy az automatizált forgalmat gyanúsnak tekintsék, mert évekig az automatizált forgalom volt a fenyegetés: a katalógus lemásolása, a készletadatok kiszívása, a terheléses támadás, az árazás visszafejtése. Ez a védelem nem hiba — a káros botok ma is léteznek, és a fal továbbra is szükséges. A probléma nem az, hogy a fal áll. Hanem az, hogy a fal egyetlen kérdést tesz fel: „ember vagy vagy gép?" — és a válaszra épülő logika a gépet automatikusan a gyanú oldalára sorolja.
A vásárló-ágens, aki kártyával és valódi szándékkal jön
Az agentikus vásárló szétfeszíti ezt a bináris logikát. Technikailag gép, szándékában viszont a legértékesebb emberi vásárló. A régi kérdés — „ember vagy gép?" — rossz kérdéssé vált, mert a helyes kérdés immár az: „felhatalmazott, jó szándékú ágens ez, vagy káros automatizáció?"
A mai védelmi rendszerek túlnyomó része erre a kérdésre nem tud válaszolni. Nem azért, mert rosszul van beállítva, hanem mert egy olyan világra tervezték, amelyben ez a megkülönböztetés még nem létezett. A következmény üzleti, nem technikai: a védelem, amely a kárt zárja ki, most a bevételt is kizárja — csendben, mérés nélkül, a checkout előtti utolsó lépésben.
Felhasználói engedély vagy platform-felhatalmazás?
Az Amazon kontra Perplexity tanulsága
2026 márciusában egy amerikai bírósági döntés élesen megvilágította a kérdés jogi magvát. Az Amazon eljárást indított a Perplexity ellen, amiért annak vásárló-ágense a felhasználók fiókjain keresztül lépett be és cselekedett a platformon. A bíróság előzetes megállapítása lényegre törő volt: az ágens a felhasználó engedélyével, de a platform felhatalmazása nélkül járt el. Ez a két fogalom nem ugyanaz, és a különbségük az egész téma tengelye.
A felhasználó engedélye annyit jelent, hogy a vásárló megbízta az ágenst, cselekedjen a nevében. A platform felhatalmazása viszont arról szól, hogy te, a kereskedő, beengeded-e ezt az ágenst a rendszeredbe, és milyen feltételekkel. A kettő elválik. Egy ágens, amelyet a vásárló felhatalmazott, még nem jogosult automatikusan belépni a te infrastruktúrádba — és fordítva, a te szabályaid döntik el, milyen felhatalmazott ágens-forgalmat fogadsz. (Az ügy egyébként nem zárult le: a döntést fellebbezés alatt felfüggesztették, a végső szót a fellebbviteli bíróság mondja ki — de a jogi különbségtétel már most irányadó.)
Miért nem véd meg önmagában a szerződésed?
Sokan azt feltételezik, hogy a felhasználási feltételek elrendezik a kérdést. A valóság összetettebb. A szerződéses tiltás és a technikai kapu két külön dolog: egy jogi kikötés önmagában nem akadályozza meg a belépést, csak jogalapot ad utólag. A hozzáférés valódi szabályozása ott dől el, ahol a technikai réteg felismeri és kategorizálja az ágenst — nem ott, ahol a felhasználási feltételekben szerepel egy mondat. Aki csak a szerződésre támaszkodik, az egy zárat feltételez ott, ahol valójában csak egy tábla lóg a nyitott ajtón.
Beengedni vagy blokkolni? A cégvezető döntési mátrixa
Itt válik a téma vezetői kérdéssé, és itt szűnik meg IT-feladat bejelentése. A Fábius módszertan szerint ez nem elsősorban technikai kérdés, hanem IT és digitális érettségi kérdés: a szervezet készen áll-e egyáltalán arra, hogy ágens-forgalmat fogadjon, kategorizáljon és kezeljen — vagy csak reflexből enged, illetve reflexből tilt.
Mi szól a beengedés mellett?
A beengedés mellett a legerősebb érv a csatorna maga. Az agentikus vásárló magas szándékú: nem böngészni jött, hanem vásárolni. Egy új, növekvő értékesítési felület nyílik, amelyen keresztül a fiatalabb, AI-natív vásárlói kohorszokat érheted el ott, ahol ők ténylegesen döntenek. Aki korán, kontrolláltan beengedi ezt a forgalmat, az egy formálódó szokásrendszer elején van jelen, nem a végén.
Mi szól beengedés ellene?
Az ellenérvek épp ilyen valósak, és nem söpörhetők félre. A fiók-átvételi és csalási kockázat nő, amikor automatizált kliensek járnak el emberek nevében. Az ágens-forgalom kapacitást és költséget fogyaszt, gyakran a vásárlási arányhoz nem illeszkedő mértékben. Az attribúció és a hirdetési logika torzul, mert az ágens kikerüli a megszokott vásárlói utat — ez volt az Amazon egyik fő kifogása is. És a felelősség kérdése tisztázatlan: ha egy ágens tévesen vagy manipuláltan vásárol, a keletkező kár ma nagyrészt a kereskedőn csapódik le. A döntés tehát nem „haladó vagy maradi", hanem egy valódi mérlegelés, amelynek mindkét serpenyőjében súlyos tételek vannak.
Hogyan dönt erről egy érett IT szervezet?
Verifikált-ágens kapuzás, nem minden-vagy-semmi
A jó hír, hogy a válasz nem a két szélsőség egyike. Nem kell mindent beengedni, és nem kell mindent blokkolni.
Kialakulóban van egy középút: a kriptográfiailag hitelesített ágens-identitás. A gyakorlatban ez azt jelenti, hogy a felhatalmazott ágens aláírja a kéréseit, a rendszered pedig ellenőrzi ezt az aláírást, mielőtt beengedi.
A szabvány, amely ezt lehetővé teszi, a Web Bot Auth néven futó IETF-munka — a HTTP-üzenetaláírások (RFC 9421) ratifikált szabványára épül, jelenleg tervezet stádiumban, immár önálló IETF-munkacsoporttal a háta mögött, de még nem véglegesített RFC. A nagy tartalomkézbesítő és biztonsági szolgáltatók viszont már élesben építik be. A logika egyszerű: a védelem megmarad az ismeretlen automatizációra, miközben a hitelesített, jó szándékú ágens szabályozott kaput kap. Nem a fal ledöntéséről van szó, hanem egy megbízható bejáratról a falon.
Az IT-governance keret
A technikai kapu azonban csak eszköz. A döntés kerete a szervezet kormányzási érettsége.
Az ISO 42001, az AI-menedzsmentrendszerek első tanúsítható szabványa, pontosan azt kéri számon, ami itt hiányzik: emberi felügyelet, eszkalációs út, felülbírálati lehetőség és auditálható nyom minden agentikus tranzakció mögött.
Az ISO 27001 a biztonsági réteget fedi, a COBIT (az ISACA kerete) pedig a döntési jogköröket rendezi — ki dönt, ki felel, ki ellenőriz. Ezek nem plugin-kérdések, hanem szervezeti kérdések.
The Precursorius Modell (Fábius módszertan) szerint 2,5-ös érettségi szintig ágens-pilotot javaslok, nem éles ágens-forgalmat. Ez alatt a előzmények nélküli iroda-autómatizáció pl. ágens korai: a üzleti szervezetnek nincs meg az adat-, folyamat- és irányítási alapja, amelyre az agentikus réteg biztonságosan ráülhetne. Egyetlen kivétel van — ha nulláról építünk fel valamit, és nem egy meglévő, kiforrott működést bontunk vissza az ágenshez. Aki a fejlettséget átugorva ugrik az ágensre, az nem a jövőt hozza előre, hanem a szinkronicitási rést mélyíti: a technológia elszalad, a céges működödés teljs szervezete lemarad, és a különbség kudarcként csapódik le.
Ki dönti el ezt nálad — és mikor?
A kényelmetlen kérdés a végére marad. Van-e a cégednél írott szabály arra, milyen ágens-forgalmat engedsz be, és milyet nem? A legtöbb szervezetnél a válasz nem az, hogy „igen" vagy „nem" — hanem az, hogy a kérdés még fel sem merült. Ez azt jelenti, hogy a döntést jelenleg egy beállítás hozza meg, amelyet évekkel ezelőtt, egy másik problémára konfiguráltak. A rés maga a kockázat: nem az a veszélyes, ha tudatosan tiltasz vagy tudatosan engedsz, hanem az, ha a döntésnek nincs gazdája.
Ez a döntés most kerül a vezetői asztalra, és nem oldható meg egyetlen technikai kapcsolóval. Ahhoz, hogy tudatosan dönts, előbb látni kell, hol tart a szervezeted: kész-e egyáltalán ágens-forgalmat fogadni, megvan-e a kormányzási alap, és van-e belső gazdája a kérdésnek. Fábius szerint a kérdés nem az, hogy a technológia kész-e. Az kész. A kérdés, hogy a szervezeted kész-e.
Pontosan ezt méri fel a 360 fokos Fábius diagnózis — az a belépő, ahol kiderül, hol áll a szervezeted ehhez a döntéshez, és milyen sorrendben érdemes lépnie. Nem javaslatot hagyok az asztalon, hanem együtt visszük végig a döntést és a bevezetést, külső vezetőként, belső hatáskörrel. Amikor ez a kérdés most a te asztalodon van, kezdjük ott, ahol minden tiszta döntés kezdődik: a helyzet őszinte felmérésénél.
Források
- Agentic Commerce Protocol (OpenAI + Stripe), hivatalos bejelentés: https://stripe.com/newsroom/news/stripe-openai-instant-checkout
- Mastercard Agent Pay, program-bejelentés (2025. április): https://www.mastercard.com/us/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html
- Santander & Mastercard – Európa első élő, ágens által végrehajtott fizetése: https://www.mastercard.com/news/europe/en/newsroom/press-releases/en/2026/santander-and-mastercard-complete-europe-s-first-live-end-to-end-payment-executed-by-an-ai-agent/
- Amazon kontra Perplexity, bírósági döntés (CNBC, 2026. március): https://www.cnbc.com/2026/03/10/amazon-wins-court-order-to-block-perplexitys-ai-shopping-agent.html
- Amazon kontra Perplexity, jogi elemzés (engedély vs. felhatalmazás): https://moginlawllp.com/courts-weigh-computer-access-in-age-of-agentic-ai-in-amazon-perplexity-case/
- Web Bot Auth, IETF Internet-Draft: https://datatracker.ietf.org/doc/draft-meunier-web-bot-auth-architecture/
- HTTP Message Signatures, RFC 9421 (IETF, 2024): https://www.rfc-editor.org/rfc/rfc9421
- Web Bot Auth élesben (Cloudflare): https://blog.cloudflare.com/web-bot-auth/
- ISO/IEC 42001 – AI-menedzsmentrendszer szabvány: https://www.iso.org/standard/42001
