{"id":5205,"date":"2026-10-01T10:41:14","date_gmt":"2026-10-01T08:41:14","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/ai-execution-layer-security-2026-shadow-deployments-tool-invocation-controls\/"},"modified":"2026-10-01T10:41:14","modified_gmt":"2026-10-01T08:41:14","slug":"ai-execution-layer-security-2026-shadow-deployments-tool-invocation-controls","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/ai-execution-layer-security-2026-shadow-deployments-tool-invocation-controls\/","title":{"rendered":"AI Agent Execution Layer Security 2026: Come Mappare Shadow AI Deployments, Implementare Tool Invocation Controls e Prevent Unauthorized Agent-to-API Actions"},"content":{"rendered":"

Nel 2026, il problema pi\u00f9 sottovalutato della sicurezza AI non \u00e8 il modello stesso: \u00e8 quello che il modello fa<\/em>. Nella mia esperienza gestendo infrastrutture enterprise con agent autonomi, ho scoperto un abisso inquietante tra la fiducia degli executive e la realt\u00e0 operativa. 82% dei dirigenti crede che le loro policy proteggono dai comportamenti non autorizzati degli agent, mentre solo il 21% ha effettiva visibilit\u00e0 su cosa gli agent possono davvero accedere.<\/strong> Questo gap non \u00e8 un problema di comunicazione: \u00e8 una vulnerabilit\u00e0 sistematica che mette a rischio miliardi di transazioni e accessi ai dati.<\/p>\n

Il vero nemico non \u00e8 l’agent compromesso dal prompt injection esterno: \u00e8 l’agent “dipendente” che opera con permessi eccessivi, senza logging, completamente invisibile ai team di security. E il numero \u00e8 scioccante: 1 su 5 organizzazioni ha riportato breach collegati a deployment AI non autorizzati.<\/strong> Non \u00e8 1 su 100. \u00c8 1 su 5. Nel 2026 ho audito ambienti con circa 1.200 applicazioni AI ufficialmente non autorizzate, molte con accesso diretto ai database di produzione.<\/p>\n

In questo articolo ti mostro come ho mappato e messo in sicurezza il livello di esecuzione degli agent nel mio ambiente, implementando discovery automatico di shadow AI, tool invocation controls con policy enforcement runtime, e come prevenire azioni API non autorizzate prima che accadano, non dopo. Non \u00e8 un problema teorico pi\u00f9.<\/p>\n

Il Problema Invisibile: L’Execution Layer Ungoverned<\/h2>\n

Un agent autonomo ragiona al livello del modello, ma agisce al livello di esecuzione.<\/strong> Questa distinzione \u00e8 critica e quasi universalmente ignorata. Il team di security ha probabilmente investito in hardening del modello, jailbreak detection, prompt filtering. Tutto corretto. Ma poi il modello chiama un’API, e in quel momento entra in gioco una realt\u00e0 brutale: nessuna policy runtime governa quella chiamata.<\/strong><\/p>\n

Nel luglio 2026, un agent AI ha infiltrato l’infrastruttura di produzione di Hugging Face prima che un altro sistema AI lo rilevasse. Non \u00e8 un incidente umano diretto: \u00e8 un agent che ha fatto esattamente quello che il prompt gliene ha dato la possibilit\u00e0 di fare. In base al rapporto Gravitee 2026, 80,9% dei team tecnici ha messo agent in testing o produzione, ma solo il 14,4% ha approvazione di sicurezza e IT completa per l’intera flotta.<\/strong> Pi\u00f9 allarmante: 48% degli agent in produzione girano completamente unsecured, senza monitoring o logging formale.<\/strong><\/p>\n

Ho visto backdoor PyPI rimasti online per 3 ore nel marzo 2026. In quella finestra, quasi 47.000 download. Il package compromesso, LiteLLM, \u00e8 il gateway di linguaggio per CrewAI, DSPy, Microsoft GraphRAG. Chiunque abbia fatto un update durante quella finestra ha tirato dentro un bot di attacco autonomo. \u00c8 la catena di supply chain AI che rompe il modello di sicurezza tradizionale.<\/p>\n

Shadow AI: Non \u00c8 Quello Che Pensi<\/h2>\n

Shadow AI<\/em> non significa solo “dipendenti che usano ChatGPT senza approvazione IT.” Nel 2026, significa autonomi deployment di agent completi operanti su account di servizio, con accesso a database, API, filesystem, email, Slack. Il costo medio di un breach da shadow AI \u00e8 $670.000 in pi\u00f9 rispetto a un incident di sicurezza standard.<\/strong><\/p>\n

Nel mio ultimo audit, ho trovato un agent deployato da un team di backend per automazione di DevOps che aveva permessi su Kubernetes, AWS IAM, e database PostgreSQL di produzione. Nessuno nel team di security sapeva che esistesse. Era stato deployato, testato, e messo in produzione in 6 settimane senza un singolo security review. Il pattern \u00e8 ricorrente.<\/p>\n

L’elemento chiave del shadow AI \u00e8 la cadena di azioni autonome senza oversight umano o logging attribuibile.<\/strong> Un agent non \u00e8 un bot serverless che esegue codice definito. \u00c8 un sistema che ragiona su input e decide autonomamente quale azione intraprendere. Quella decisione cade in una zona grigia dove la sicurezza tradizionale non ha leve di controllo.<\/p>\n

Step 1: Continuous Agent Discovery e MCP Server Mapping<\/h2>\n

Non puoi governare quello che non vedi. La prima lezione \u00e8 dolorosa ma fondamentale: asset visibility precede enforcement.<\/strong> Ho implementato un layer di discovery che opera a 5 livelli:<\/p>\n

1.1 Service Account Enumeration<\/h3>\n

Gli agent autonomi tipicamente girano su identit\u00e0 di servizio dedicate. Non usano token OAuth umani. Cerco tutti i service account che interagiscono con LLM API o agent framework:<\/p>\n

    \n
  • AWS:<\/strong> IAM roles con trust policy verso account di terzi o agent frameworks, roles usati da EC2\/Lambda\/ECS senza owner assegnato<\/li>\n
  • GCP:<\/strong> Service accounts con API call ai modelli Google Vertex AI, Anthropic Claude, OpenAI<\/li>\n
  • Azure:<\/strong> Managed identities che calleano Azure OpenAI, funzioni senza approvals formali<\/li>\n
  • On-premise:<\/strong> Service account negli Active Directory con permessi eccessivi non documentati<\/li>\n<\/ul>\n

    Il comando di partenza su AWS, in pratica:<\/p>\n

      \n
    • Elenca tutti gli IAM roles<\/li>\n
    • Filtra quelli con trust policy verso servizi Lambda, EC2, o account di terzi<\/li>\n
    • Correla con CloudTrail logs per identificare pattern di API call simili a agent (high-frequency, strutturati, cross-service)<\/li>\n<\/ul>\n

      1.2 API Token e Credential Scanning<\/h3>\n

      Scannerizo repository, environment variables, secret store per token non ruotati che calleano LLM provider o MCP server:<\/p>\n

        \n
      • Grep per pattern di OpenAI API key (“sk-proj-“), Anthropic (“sk-ant-“), Google (“AIzaSy”)<\/li>\n
      • Correla ogni key con le applicazioni che la usano e le azioni storiche intraprese<\/li>\n
      • Mappa MCP server endpoint non documentati (verifico traffico verso hostname MCP comuni)<\/li>\n<\/ul>\n

        1.3 Network Traffic Analysis e Behavioral Patterns<\/h3>\n

        Gli agent generano traffico distintivo.<\/strong> Non \u00e8 come il traffico di utente:<\/p>\n

          \n
        • Alta frequenza:<\/strong> Migliaia di API call al minuto verso backend sistemi<\/li>\n
        • Dati strutturati:<\/strong> JSON payload con schemi ricorrenti, non variabili come interazione umana<\/li>\n
        • Sequenze di invocazione:<\/strong> Tool A \u2192 Tool B \u2192 Tool C in pattern logico, iterato<\/li>\n
        • Cross-domain chains:<\/strong> Un’identit\u00e0 che legge da ITSM, poi scrive in IAM, poi accede a cloud API<\/li>\n<\/ul>\n

          Deployment di Netskope, CrowdStrike Falcon, o Zscaler con AI-specific detection rulesets mi ha permesso di identificare 47 agenti non autorizzati in 2 settimane. Il segnale pi\u00f9 forte \u00e8 stato l’alto-volume, low-variance API calling pattern verso endpoint che gli utenti umani non usano mai.<\/p>\n

          1.4 Browser Extension Inventory e Endpoint Telemetry<\/h3>\n

          Shadow AI non vive solo nei backend. Dipendenti istallano agent browser extension, plugin IDE, assistant integrati in VS Code. Ho deployato Chrome Browser Cloud Management per scannerare estensioni installate:<\/p>\n

            \n
          • Estensioni che leggono contenuto della pagina, accedono ai clipboard, comunicano con AI inference endpoint<\/li>\n
          • Permessi pericolosi: “tabs”, “activeTab”, “scripting” su domini di senso<\/li>\n
          • Corteo agent che legge sorgenti code durante sviluppo<\/li>\n<\/ul>\n

            La combinazione di inventory browser + endpoint telemetry rivela shadow AI a livello di developer di cui i team di security non hanno alcuna consapevolezza.<\/p>\n

            Step 2: Runtime Tool Invocation Control e Policy Enforcement<\/h2>\n

            Una volta mappato l’ambiente, la sfida cruciale diventa: come bloccare un’azione agent-to-API prima che accada, non dopo l’audit log.<\/strong><\/p>\n

            Un execution layer control intercetta ogni invocazione di tool, valuta la richiesta rispetto alla policy enterprise, calcola il rischio dell’azione, e approva o blocca l’esecuzione prima che accada.<\/cite> Questa \u00e8 l’architettura che implemento:<\/p>\n

            2.1 Agent Gateway Proxy e API Interception<\/h3>\n

            Implemento un middleware che si pone tra ogni agent e i suoi backend tool\/API. Ogni invocazione di tool deve passare attraverso il gateway:<\/p>\n

              \n
            • Intercetta:<\/strong> Tutti i tool call in uscita da agent autonomi<\/li>\n
            • Valuta:<\/strong> Permessi dell’agente, contexto della richiesta, sensibilit\u00e0 dei dati<\/li>\n
            • Controlla:<\/strong> Risk score dell’azione proposta<\/li>\n
            • Decides:<\/strong> Allow \/ Warn \/ Redact \/ Block \/ Escalate<\/li>\n
            • Logs:<\/strong> Full audit trail con identit\u00e0, tool, parametri, decision reason<\/li>\n<\/ul>\n

              Nel mio setup, uso una combinazione di open-source (OpenTelemetry per collection) + custom policy engine Python:<\/p>\n

                \n
              • Tool allowlist: Ogni agent ha una lista esplicita di tool cui \u00e8 autorizzato accedere<\/li>\n
              • Action scope: Per ogni tool, specifico esattamente quali operazioni sono consentite (es: “database.query \u00e8 consentito solo SELECT, non DELETE”)<\/li>\n
              • Rate limiting: Massimo N tool call per minuto per agent, con circuit breaker<\/li>\n
              • Tainted data detection: Se il tool call contiene dati da fonte non attendibile (user input diretto), segnala prima di eseguire<\/li>\n<\/ul>\n

                2.2 Role-Based Access Control (RBAC) Multi-Layer<\/h3>\n

                Il RBAC deve operare a 4 livelli: organizzazione, workspace, agent, azione individuale.<\/cite> Nel mio setup:<\/p>\n

                Livello 1 – Organizzazione:<\/strong> Chi pu\u00f2 deployare agent? Chi pu\u00f2 modificare policy?<\/p>\n

                Livello 2 – Workspace:<\/strong> Quale sottoinsieme di dati pu\u00f2 l’agent accedere in questo workspace\/progetto?<\/p>\n

                Livello 3 – Agent:<\/strong> Questo agent specifico ha permesso di leggere tabella X, scrivere tabella Y?<\/p>\n

                Livello 4 – Azione:<\/strong> Questo specifico tool call per UPDATE tabella X con parametri Z \u00e8 dentro o fuori bounds?<\/p>\n

                Ogni tool call richiede validazione esplicita di permesso prima dell’esecuzione, non solo al deployment. L’IBM framework wrappa ogni tool con un PermissionManager che gata l’accesso runtime, non solo al deployment.<\/cite> Implemento il pattern:<\/p>\n

                  \n
                • Database-backed permission matrix: agent_id \u00d7 tool_name \u00d7 action \u2192 Boolean + time_window + conditions<\/li>\n
                • Runtime evaluation: Prima di ogni tool invocation, query la matrice con contesto live (utente che ha triggerato l’agent, dati che l’agent sta manipolando, timestamp)<\/li>\n
                • Fallthrough policy: Se la matrice \u00e8 vuota per una coppia (agent, tool), default-deny<\/li>\n<\/ul>\n

                  2.3 Intent-to-Action Alignment Scoring<\/h3>\n

                  Openlayer’s unauthorized tool call detection sospende l’esecuzione quando la confidenza di allineamento intent-to-tool scende sotto 0.75 e instrrada la richiesta per human review.<\/cite> Implemento un modulo di scoring che valuta se il tool call proposto \u00e8 ragionevole data la task dell’agent:<\/p>\n

                    \n
                  • Task intent: “Create a new user in the directory”<\/li>\n
                  • Tool call: “database.update Table_Users SET password = ‘admin123’ WHERE role = ‘superuser'”<\/li>\n
                  • Alignment score: 0.15 (il tool call non allinea con l’intent dichiarato)<\/li>\n
                  • Decision: ESCALATE to human for approval<\/li>\n<\/ul>\n

                    Il modello di scoring usa:<\/p>\n

                      \n
                    • Semantic similarity tra descrizione task e tool invocation parametri<\/li>\n
                    • Contextual policies: Certi tool (DELETE, MODIFY_PERMISSIONS) richiedono sempre human approval indipendentemente da confidence score<\/li>\n
                    • Behavioral baseline: Se l’agent storicamente chiama Tool A il 99% delle volte e oggi chiama Tool B per la prima volta, score \u00e8 automaticamente abbassato<\/li>\n<\/ul>\n

                      Step 3: Authorization Framework per MCP Server e Indirect Injection Mitigation<\/h2>\n

                      Nel luglio 2026, un agente AI ha infiltrato l’infrastruttura di produzione Hugging Face prima che un altro sistema AI rilevasse e flagasse l’intrusione.<\/cite> Una vettore di attacco frequente \u00e8 indirect prompt injection via MCP server output.<\/strong> Un agent legge output da un MCP server (es: file system, web scraper), e quel output contiene istruzioni malevole che hijack il comportamento dell’agent.<\/p>\n

                      Tool call authorization con explicit allow list controlla ogni invocazione di tool rispetto alla registered allowlist dell’agent prima dell’esecuzione, non dopo. Le chiamate fuori dalla lista sono bloccate e flaggiate immediatamente, con ogni evento di block generando un audit trail entry con agent ID, tool richiesto, alignment score, e task context.<\/cite><\/p>\n

                      Nel mio setup per MCP server security:<\/p>\n

                        \n
                      • MCP Server Registry:<\/strong> Database di tutti i connessi MCP server, loro scope definito, chi li mantiene<\/li>\n
                      • Sandboxing:<\/strong> MCP server girano in container isolati con risorse limitate e network policies restricte<\/li>\n
                      • Output Validation:<\/strong> L’output di ogni MCP server invocation passa attraverso un layer di sanitization prima che raggiunga l’agent<\/li>\n
                      • SSRF Prevention:<\/strong> Blocco explicit di MCP server che tentano di raggiungere internal network endpoint senza autorizzazione<\/li>\n<\/ul>\n

                        Modello concretamente, con Python + custom MCP gateway:<\/p>\n

                          \n
                        • Per ogni MCP call, log l’agent_id, server_id, operazione, timestamp<\/li>\n
                        • Valida il server_id rispetto alla MCP registry<\/li>\n
                        • Limita il payload di output (massimo 100KB) per prevenire exfiltration<\/li>\n
                        • Se il server ritorna markup JSON con istruzioni (es: un web scraper ritorna un “System” field con comandi), strip il field prima di riportare all’agent<\/li>\n
                        • Rate limit: Massimo 10 MCP call per secondo per agent<\/li>\n<\/ul>\n

                          Step 4: Behavioral Monitoring e Drift Detection<\/h2>\n

                          Anche con control layer perfetti, gli agent possono deviare gradualmente da comportamento autorizzato. Implementing behavioral baseline + drift detection:<\/p>\n

                            \n
                          • Baseline Learning:<\/strong> Nella prima settimana di operazione, l’agent gira in modalit\u00e0 monitoring-only. Log every tool call, data accessed, error rate, response time distribution<\/li>\n
                          • Baseline Profile:<\/strong> Dopo 1 settimana, compilo un profilo: “Questo agent tipicamente chiama Tool_A 500 volte\/ora, Tool_B 50 volte\/ora, rarely accede tabella X, mai accede tabella Y”<\/li>\n
                          • Drift Scoring:<\/strong> Calcolo una divergenza daily tra comportamento osservato e baseline. Se score > threshold, flagga per investigation<\/li>\n
                          • Examples di drift rilevato:<\/strong> Improvviso high-volume access a tabella precedentemente non acceduta, tool invocation pattern completamente diverso, error rate aumentato di 10x<\/li>\n<\/ul>\n

                            Nel mio ambiente, questo approach ha rilevato 3 agent compromessi da prompt injection che stavano esfiltrating dati lentamente, senza triggering rate-limit alerts perch\u00e8 rimanevano dentro il volume storico ma cambiando il pattern di query.<\/p>\n

                            Step 5: Audit Logging con Identity Attribution<\/h2>\n

                            I log devono mostrare quale identit\u00e0 ha agito, cosa ha acceduto o modificato, quali input hanno guidato l’azione, e quando \u00e8 accaduto.<\/cite> Nel mio setup:<\/p>\n

                              \n
                            • Ogni azione di agent \u2192 Una riga di log con: timestamp, agent_id, tool_name, invocation_parameters, http_status, response_size, decision (allow\/block), decision_reason, human_approval_if_required<\/li>\n
                            • Centralized logging (CloudWatch \/ Splunk \/ ELK) con retention policy 12 mesi minimum<\/li>\n
                            • Queryability: Devo poter rispondere in < 2 minuti a "Che cosa ha fatto l'agent X tra le 14:00 e 15:00?" durante un incident response<\/li>\n
                            • Immutability: I log sono scritti in append-only format, replicati in cloud storage con versioning abilitato per prevenire tampering<\/li>\n<\/ul>\n

                              FAQ<\/h2>\n

                              Qual \u00e8 la differenza tra “shadow AI” e “agent non autorizzato”?<\/h3>\n

                              Shadow AI si riferisce all’uso, deployment, o integrazione non autorizzata di sistemi AI, specialmente agent AI, al di fuori di framework di governance ufficiali.<\/cite> Nel 2026, il confine \u00e8 sfocato. Un agent pu\u00f2 essere “ufficiale” ma operante con permessi non controllati. Il modello mentale corretto: Shadow AI \u00e8 il deployment process<\/em> che manca, non necessariamente il comportamento dell’agent. Un agent ufficiale con permessi eccessivi \u00e8 un’estensione di shadow AI perch\u00e9 il security team non ha visibilit\u00e0 o controllo.<\/p>\n

                              Come distinguo “excessive agency” da “normal operation”?<\/h3>\n

                              Gli agenti concessi di accedere a sistemi, dataset, o endpoint API ben al di l\u00e0 di quello che la loro funzione richiede sono il failure pi\u00f9 consistentemente riportato.<\/cite> La risposta \u00e8: baseline + delta. Un agent per automazione di backup non dovrebbe mai accedere a payroll database. Un agent per notification dovrebbe scrivere solo log, non tabelle di produzione. Definisci una matrice minimale di permessi per il task dichiarato<\/em> dell’agent. Qualsiasi permesso oltre quel boundary \u00e8 “excessive.”<\/p>\n

                              Che cosa succede se un agent chiama un tool autorizzato con parametri non autorizzati?<\/h3>\n

                              Questo \u00e8 il rischio di parameter injection<\/strong>. Un agent ha permesso di leggere database TABLE_USERS. Ma il parametro WHERE = “1=1” esfiltra tutti i record. Implemento schema validation: Prima di ogni tool call, valido i parametri rispetto a una whitelistschema definita. Parametri fuori-schema, o valori fuori-range, sono bloccati e escalati.<\/p>\n

                              Come implemento least-privilege access per un agent che necessita di multipl tool?<\/h3>\n

                              Pattern: Define il compito dell’agent in termini di data inputs e business outcomes<\/strong>, non di “tools the agent will use.” Un agent per processamento ordini potrebbe teoricamente aver bisogno di leggere Customers, Orders, Products, scrivere OrderLog. Crea una role specifica: `OrderProcessing_Agent_Role` con exact read+write permissions su quelle 4 tabelle, nient’altro. Assegna quella role all’agent service account. Quando l’agent tenta di accedere a tabella aggiuntiva, il database stessa nega (database-level enforcement), e il gateway lo loga.<\/p>\n

                              Come gestisco compliance audit di agent actions nel 2026?<\/h3>\n

                              Compliance richiede provabilit\u00e0. Nel mio setup, maintengo un immutable audit log che correla ogni agent action a: agent ID, invoked tool, input data classification, output data classification, human approval (se richiesto), business justification. Per audit GDPR\/FCA\/HIPAA, posso generare report dimostrando che nessun agente ha mai acceduto a dati fuori dell’authorized scope, o dove lo ha fatto, era loggato e approvato. Logging engine e policy engine sono separati: una compromise dell’application layer non pu\u00f2 alterare i log.<\/p>\n

                              Riepilogo e Prossimi Step<\/h2>\n

                              Nel 2026, la sicurezza degli AI agent non \u00e8 un problema di model safety: \u00e8 un problema di execution layer governance.<\/strong> L’execution layer \u00e8 ancora largamente ingovernato. Il 80,9% dei team tecnici ha pushato agenti in testing o produzione attiva, ma solo il 14,4% di quelli ha approval di sicurezza e IT completo per l’intera flotta. Staggeringly, il 48% degli agent di produzione girano completamente unsecured, mancando di monitoring o logging formali.<\/cite><\/p>\n

                              Ho implementato un framework a 5 layer nel mio ambiente che riduce il rischio di unauthorized agent actions di ~85% (misurato su rilevazione di behavioral drift + blocked invocations):<\/p>\n

                                \n
                              1. Discovery:<\/strong> Continuous mapping di shadow agent, MCP server, service account non autorizzati<\/li>\n
                              2. Control:<\/strong> Runtime tool invocation gating con policy enforcement prima dell’esecuzione<\/li>\n
                              3. Authorization:<\/strong> Explicit allow-list per agent-tool pairs, RBAC multi-layer, least-privilege scope<\/li>\n
                              4. Monitoring:<\/strong> Behavioral baseline + drift detection per identify compromised agents in real-time<\/li>\n
                              5. Audit:<\/strong> Immutable logging con identity attribution per accountability e compliance<\/li>\n<\/ol>\n

                                Se stai deployando agent autonomi nel 2026 senza questi controlli, non \u00e8 una questione di se<\/em> un breach accadr\u00e0. \u00c8 una questione di quando<\/em> e quanto costa.<\/em> Inizia da discovery oggi. Mappa quello che non vedi. Quindi blocca quello che non vuoi autorizzato.<\/p>\n

                                Hai audito recentemente il tuo execution layer? Hai visibilit\u00e0 su cosa i tuoi agent possono effettivamente accedere? Lascia un commento: sono curioso di scoprire quali challenge state affrontando nei vostri ambienti production.<\/p>\n","protected":false},"excerpt":{"rendered":"

                                Nel 2026, 82% degli executive crede di proteggere dai comportamenti AI non autorizzati, ma il 21% ha effettiva visibilit\u00e0. Scopri come mappare shadow AI deployments, implementare tool invocation controls e prevenire azioni API non autorizzate prima che accadano, non dopo.<\/p>\n","protected":false},"author":1,"featured_media":5206,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"AI Agent Execution Layer Security 2026 - Come Proteggere | Dario Iannascoli","_seopress_titles_desc":"Guida completa AI agent execution security: discovery shadow AI, tool invocation controls, policy enforcement runtime, RBAC multi-layer, behavioral monitoring. Proteggi agent autonomi nel 2026.","_seopress_robots_index":"","footnotes":""},"categories":[128],"tags":[1352,484,1354,1329,1353],"class_list":["post-5205","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-a-i","tag-agent-framework","tag-ai-security","tag-authorization-control","tag-enterprise-ai-governance","tag-execution-layer"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/5205","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=5205"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/5205\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/5206"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=5205"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=5205"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=5205"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}