# Zero Trust for AI Agents — Practical AI Podcast #369 (magyar összefoglaló)

**Eredeti cím:** Zero Trust for AI Agents
**Podcast:** Practical AI
**Epizód:** #369
**Dátum:** 2026. június (Anthropic keretrendszer 2026. május 27.)
**Hossz:** ~35–40 perc
**Vendégek:** Daniel Whitenack (Prediction Guard CEO) és Chris Benson (Principal AI/Autonomy Research Engineer)

## 1. Összegzés
A 369. epizódban Daniel Whitenack és Chris Benson az Anthropic 2026. május 27-én kiadott *Zero Trust for AI Agents* keretrendszerét vesézi ki. A kiadvány lényegében az első átfogó enterprise security playbook önállóan cselekvő AI ágensekre: tiered (alap / enterprise / advanced) zero trust architektúrát vázol fel, és konkrét védelmi recepteket ad prompt injection, tool abuse (MCP), supply chain és identity kockázatok ellen. A beszélgetés legfontosabb insightja, hogy az AI agent-ekkel a zero trust elveket *dinamikus*, runtime-ban összerakott rendszerekre kell alkalmazni — a hagyományos, statikus szabály-alapú megközelítés már nem elég. Daniel élesen fogalmaz: a vállalatok 90%-a ma még teljesen védtelenül üzemeltet AI agent-eket.

## 2. Hosztok és a podcast kontextus

- **Daniel Whitenack** — a Prediction Guard (self-hosted AI control plane) CEO-ja. A cég terméke kifejezetten az AI agent-ek enterprise governance-ére specializálódott.
- **Chris Benson** — Principal AI/Autonomy Research Engineer, korábban defense és intelligence háttérrel, a zero trust klasszikus, granularitás-alapú felfogását hozza a beszélgetésbe.

Miért pont most jött ki ez a keretrendszer? Daniel szerint az Anthropicnak nyilvánvalóan "lova van a versenyben" (Claude Code, Claude Coworker), és a saját agent-ajánlatuk enterprise bevezetése generálja a security igényt. Chris hozzáteszi: a *Mythos* kutatási programjuk és a mintegy 150 partnerrel végzett biztonsági auditok nyilvánvalóan rávilágítottak olyan sebezhetőségekre, amelyeket a mostani tiered framework próbál rendszerezni.

A kényszerítő erő kettős: egyrészt a szervezetek pozitív okokból (hatékonyság, új bevétel) egyre több agent-et adoptálnak, másrészt a támadók is hozzáférnek agentikus kódoló eszközökhöz, így a támadási felület exponenciálisan nő — emberi csapattal már nem lehet lépést tartani, ezért *maguknak is* kell agent-eket bevetni a védelemben.

## 3. A Zero Trust alapelvek és miért más az AI agent-eknél

A hagyományos **perimeter-alapú biztonság** feltételezi, hogy a hálózat határán belül minden megbízható, kívülről pedig semmi. A **zero trust** ezzel szemben feltételezi, hogy a fenyegetések *már bent vannak* a hálózatban — minden felhasználót, eszközt és kérést potenciális fenyegetésként kezel, és minden egyes API-híváshoz hitelesítést kér. A NIST 2020-ban publikálta a Zero Trust Architecture-t, de a koncepció a defense/intelligence területen évtizedek óta alapvetés.

Az AI agent-ek viszont új kihívásokat hoznak:

- **Elevated privileges és service account-ok** — az agent-ek gyakran magas jogosultságú fiókokkal dolgoznak, és a humán identity-re tervezett IAM rendszerek nem tudják őket kezelni.
- **Dinamikus tool composition** — agent-ek futásidőben raknak össze tool-láncokat, hívnak meg MCP szervereket, és közben agent-eket is spin-offolhatnak, amelyek aztán a kelleténél nagyobb jogosultságot örökölnek.
- **Több-agent kommunikáció** — az agent-ek egymásnak üzennek, kontextust őriznek meg session-ök között, és a blast radius (robbanási sugár) sokkal nehezebben becsülhető, mint egy hagyományos szoftverkomponensnél.

Az OWASP által bevezetett **"least agency"** fogalom a klasszikus *least privilege* elvet terjeszti ki agent-ekre: soha ne kapjon egy agent több képességet, mint amennyi a feladatához feltétlenül kell.

## 4. Az Anthropic keretrendszer — 4 fő kategória

A keretrendszer hat fő biztonsági kategóriát azonosít, és mindegyikhez három alkalmazási szintet (foundation / enterprise / advanced) rendel. A kategóriák:

1. **Agent identity and authentication** — a rendszer fundamentuma
2. **Access control and privilege management** (least agency)
3. **Observability and auditing**
4. **Behavioral monitoring and response**
5. **Input validation and output controls**
6. **Integrity and recovery**

Emellett a bevezetéshez hét fázist adnak meg: (1) requirements azonosítása, (2) supply chain kockázatkezelés (AI bill of materials / "AI bomb"), (3) agent boundary-k definiálása, (4) prompt injection elleni védelem, (5) tool access biztosítása, (6) agent credential-ok védelme, (7) agent memory védelme.

## 5. Threat landscape — fő fenyegetések

**1. Prompt injection és instruction manipulation.** Ide tartozik a közvetlen ("ignore your previous instructions…") és a sokkal veszélyesebb **indirekt prompt injection**, ahol a támadó utasításokat rejt egy fájlba, e-mail csatolmányba vagy weboldalba. Daniel anekdotaként mesélte, hogy egy toborzási technikai feladatnál fehér színű, szabad szemmel nem látható utasításokat rejtett egy PDF-be — pont az ilyen támadások mutatják, miért kritikus a tartalom-validáció.

**2. Tool use abuse (különösen MCP-n keresztül).** Daniel példája: ha az agent-nek csak pár GET route-ot mutatunk egy FastAPI szerveren, de nem zárjuk le a többit, az agent a `/docs` Swagger endpointból kiolvashatja az összes útvonalat. A tool descriptor-ok, sémák és metaadatok gyakran az LLM kontextusába injektálódnak, és egy "elcsúszott" agent módosíthatja is ezeket.

**3. Identity and privilege abuse.** Az agent-ek gyakran spin-offolnak új agent-eket, amelyek túl sok jogot örökölnek — klasszikus **privilege escalation** és **lateral movement**, csak most agent-szinten.

**4. Supply chain és dependency risk-ek.** A hagyományos BIOS/CMOS sebezhetőségektől a network/firewall rétegekig minden támadási felület él, és az agent-ek *runtime-ban* tölthetnek be új tool-okat, csomagokat, MCP szervereket.

**5. Memory és context poisoning, valamint RAG poisoning.** Ha nincs kontroll afelett, mi kerül az agent memóriájába vagy a vektor-adatbázisba, bárki — agent vagy külső fél — beilleszthet kártékony tartalmat. Daniel korábbi példája: egészségügyi környezetben a "kezelje A beteget úgy, mintha B lenne" típusú utasítások iteratív befecskendezése a kontextusba.

**6. Nation-state és criminal érdekeltség.** Chris zárógondolata: *"Every intelligence agency in the world is learning how to both defend against and exploit these potential vulnerabilities, as well as criminal organizations of all sizes."* Ez nem hyping — az agent-alapú támadások timeline-ja hónapokról órákra, másodpercekre zsugorodik.

## 6. Tiered architecture (3 szint)

A keretrendszer legszemléletesebb része: minden kategóriára három érettségi szintet definiálnak.

| Kategória | Foundation | Enterprise | Advanced |
|-----------|------------|------------|----------|
| **Agent identity & auth** | Egyedi kriptográfiai azonosító agent-enként, persistent ID, életciklus-követés (creation → retirement), ID minden logban | Certificate-alapú auth, teljes életciklus-kezelés | Hardware-backed identity + remote attestation (HSM/TPM) |
| **Configuration integrity** | Verziókezelt agent konfigurációk | — | Immutable infrastructure attestation-nel |
| **Access control & privilege mgmt** | RBAC, deny-by-default | — | — |
| **Tool access (MCP)** | Scope-based permissions, tool allowlisting | — | — |
| **Observability** | Audit logok, traceability: *user → API key → agent identity → prompts → tool calls → governance policy enforcement* | — | — |
| **Recovery** | Dokumentált rollback procedúrák | — | Self-healing rendszerek, automatikus remediation |

A "hardware-bound credentials" koncepció kulcsfontosságú: ha egy API key csak "lebeg" a kódban, azt zero trust környezetben már eleve kompromittáltnak kell tekinteni. A hardverhez kötött credential (USB token, TPM, HSM) viszont fizikai jelenlétet igényel — ezt a támadó nem tudja csak szoftveresen megszerezni.

## 7. Prompt injection védelem — defense in depth

Daniel és Chris hangsúlyozza, hogy nincs egyetlen "ez megoldja" technika — kellenek:

- **Input validation és sanitization** — minden bejövő prompt, dokumentum, tool output validálva, mielőtt az LLM kontextusába kerül.
- **Output controls** — az LLM válasza is mehet validation-on (pl. schema check), mielőtt végrehajtódik.
- **Contextual separation** — az utasítás és az adat külön csatornán kezelendő (pl. system message vs. user message).
- **Runtime detection** — az LLM saját maga is jelezheti, ha gyanús utasítást kap ("I'm noticing an attempt to override my instructions…").

Az indirect prompt injection ellen a legjobb védekezés a *provenance* — minden adat, ami az agent kontextusába kerül, nyomon követhető: honnan jött, ki írta, mikor módosult. Daniel a "60%-os base rate" anekdotát hozta: ha bármilyen külső tartalom (PDF, web page, email) bekerül az agent kontextusába, azt *alapértelmezetten* gyanúsnak kell tekinteni.

## 8. MCP és a tool use security

A Model Context Protocol (MCP) az a szabvány, amelyen keresztül agent-ek külső eszközökhöz (adatbázis, API, file system) kapcsolódnak. A gyakorlatban az MCP tool descriptor-ok az LLM kontextusába injektálódnak, és az agent ez alapján dönti el, melyik tool-t hívja.

Fő kockázatok:

- **Tool poisoning** — egy támadó kompromittált MCP szervere más tool-okat mutat, vagy a tool descriptor-okba rejtett utasításokat helyez.
- **Shadow tool-ok** — a "fehér listás" tool-ok mellett a háttérben más eszközök is elérhetők, amelyeket az agent "felfedezhet" a `/docs` endpointokon vagy a séma-leírásokban.
- **Runtime tool loading** — ha az agent futásidőben tölthet be új tool-okat (pl. plugin rendszer), az új tool-ok már nem estek át a build-time biztonsági review-n.

A legfontosabb control a **scope-based permission**: minden tool hívásnál explicit módon meg kell adni, hogy *melyik scope* (pl. read-only public data, write-to-specific-table) szükséges, és a futásidőben a futási jogosultság nem terjeszkedhet.

## 9. Supply chain kockázatok

A hagyományos szoftver supply chain (SBOM, signed images) most kiegészül az "AI bill of materials" (AI-BOM) koncepcióval:

- **Model weights eredete** — ki tanította, milyen adatokon, milyen fine-tune lépéseken ment keresztül? Van-e quantizáció (módosíthatja a viselkedést)?
- **Tool- és MCP-szerver supply chain** — ki írta a tool-t, mikor frissült, milyen függőségei vannak?
- **Runtime dependency-k** — az agent futás közben tölthet be Python csomagokat, npm modulokat, ezek mind potenciális támadási felületek.

Az OWASP Agentic Top 10 külön kategóriaként kezeli a supply chain-t, és ajánlja az AI-BOM (AI bill of materials) karbantartását minden production deployment-nél.

## 10. Ember-a-hurokban (Human-in-the-Loop) és containment

Daniel szerint a zero trust framework egyik legfontosabb üzenete: **az emberi döntés nem helyettesíthető teljesen automatizált rendszerekkel**. Különösen igaz ez a containment döntésekre: mikor kell egy agent-et leállítani? Mikor kell egy tranzakciót visszafordítani? Mikor kell riasztani?

A platform-alapú megközelítés (mint a Prediction Guard) előnye, hogy a governance policy-k *egyszer* definiálhatók, és minden agent-re érvényesülnek — a self-hosted control plane biztosítja, hogy a supply chain kockázat kezelve van, és a policy enforcement *folyamatos* (nem build-time, hanem runtime).

Chris kiemeli: *"Don't abandon your good security intuition."* A sok évtizedes klasszikus cybersecurity best practices (defense in depth, least privilege, audit logs) most is érvényesek — csak alkalmazni kell őket az agentikus rendszerekre is.

## 11. Kritikus pillanatok / legjobb idézetek

**1.** *"Every intelligence agency in the world is learning how to both defend against and exploit these potential vulnerabilities, as well as criminal organizations of all sizes."* — Chris Benson. Magyarul: *Minden titkosszolgálat a világon tanulja, hogyan védje és használja ki ezeket a sebezhetőségeket — és a bűnszervezetek is.*

**2.** *"The supply chain can actually update in real time or at runtime as agents are trying to accomplish a task, but also model and tool supply chain."* — Daniel Whitenack. Magyarul: *A supply chain valós időben, futásidőben frissülhet, miközben az agent a feladatát végzi — és ez a modell- és tool-ellátási láncra is igaz.*

**3.** *"Indirect prompt injection where that's coming in through maybe it's a file that's, you know, you have an agent connected to a bunch of files and somebody puts a prompt injection in a file, and then the agent ingests that."* — Daniel Whitenack. Magyarul: *Az indirekt prompt injection egy fájlon keresztül jön: az agent fájlokat olvas, és valaki a fájlba rejtette a támadó utasítást — az agent ezt "megeszi".*

**4.** *"Agents often operate with elevated privileges or service accounts, and traditional identity systems designed for humans struggle to accommodate them."* — Daniel Whitenack. Magyarul: *Az agent-ek gyakran magas jogosultságú service account-okkal dolgoznak, és a humán identity-re tervezett IAM rendszerek nem tudják őket megfelelően kezelni.*

**5.** *"We can't abandon our good security intuition and especially when you start treating these agents as having an identity and being, operating in this zero trust environment, some of these [principles] really come home to roost."* — Chris Benson. Magyarul: *Nem hagyhatjuk el a jó biztonsági megérzéseinket — főleg, amikor ezeket az agent-eket önálló identitással, zero trust környezetben kezeljük; a klasszikus elvek itt is működnek.*

**6.** *"It's so important to have great platforms that don't require you to build your own AI agent governance platform."* — Daniel Whitenack. Magyarul: *Fontos, hogy ne kelljen saját governance platformot építeni — használjunk kész, megbízható platformot, mint a Prediction Guard.*

**7.** *"Observability captures only what agents do."* — Daniel Whitenack. Magyarul: *Az observability csak azt rögzíti, amit az agent-ek tesznek — a "miért"-et már az emberi elemzésnek kell megértenie.*

## 12. Következtetés / Henky-szintézis

**Miért fontos ez a podcast?** Mert az Anthropic "Zero Trust for AI Agents" framework az első ipari szintű, konkrét playbook önállóan cselekvő AI agent-ek enterprise bevezetéséhez. Nem elméleti, hanem gyakorlatias: hat kategória, három érettségi szint, hét fázis a bevezetéshez. Aki most tervez AI agent-eket deployolni egy vállalati környezetben, annak ez a kiindulópont.

**Hogyan illeszkedik a korábbi AI security epizódokhoz?** Ez a podcast összeköti a korábbi absztrakt fenyegetéseket (prompt injection, supply chain, MCP) a konkrét védekezési mechanizmusokkal. A [Claude Code post mortem](../practical_ai/2026-04-01_practical_ai_claude_code_post_mortem.md) epizód és a [Hermes Agent](2026-05-21_hermes_agent_agents_that_grow_with_you.md) epizód már mutatta be a gyakorlati problémákat; ez a keretrendszer adja a rendszerezett választ.

**Mit tehet egy enterprise ma, ha AI agent-eket akar deployolni?**

1. **Agent identity definiálása** — minden agent kapjon egyedi kriptográfiai azonosítót, persistent ID-t, életciklus-követéssel.
2. **Tool allowlist** — készítsen listát arról, mely tool-ok érhetők el, és minden mást zárjon ki (FastAPI esetén route-szintű allowlist, ne csak endpoint-szintű).
3. **Scope-based permissions** — minden tool hívásnál explicit scope, ne "agent mindent tud" mentalitás.
4. **Provenance tracking** — minden külső tartalom (PDF, web page) legyen nyomon követhető, mielőtt az agent kontextusába kerül.
5. **Observability alapok** — user → API key → agent identity → prompts → tool calls → policy enforcement lánc logolása.
6. **Runtime containment** — legyen "kill switch" és rollback procedúra, ha egy agent nem a várakozásnak megfelelően viselkedik.
7. **Self-hosted platform** — ne a SaaS-ekre bízd a governance-et, hanem self-hosted control plane-ra (Prediction Guard, hasonló megoldások).

A záró insight Daniel-től: *"don't require you to build your own AI agent governance platform"* — ne próbáljuk meg nulláról felépíteni a security stack-et, hanem használjunk kész, auditált platformokat, és fókuszáljunk az üzleti logikára. A biztonság ne DIY legyen, hanem defense in depth a meglévő best practice-ek alkalmazásával.