{"id":2133,"date":"2026-06-01T07:40:01","date_gmt":"2026-06-01T05:40:01","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/agentic-ai-security-boundaries-least-privilege-permission-auditing-containment-2026\/"},"modified":"2026-06-01T07:40:01","modified_gmt":"2026-06-01T05:40:01","slug":"agentic-ai-security-boundaries-least-privilege-permission-auditing-containment-2026","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/agentic-ai-security-boundaries-least-privilege-permission-auditing-containment-2026\/","title":{"rendered":"Come Implementare Agentic AI Security Boundaries Giugno 2026: Least Privilege, Permission Auditing e Containment Multi-Agent Enterprise \u2013 La Mia Guida Palo Alto Networks"},"content":{"rendered":"

Siamo ufficialmente nell’era degli agentic AI<\/em>: sistemi autonomi che non si limitano a generare output per revisione umana, ma eseguono azioni in tempo reale<\/strong> su database, API, sistemi critici. E qui iniziano i problemi veri di sicurezza.<\/p>\n

Ho passato gli ultimi due mesi analizzando le novit\u00e0 di Palo Alto Networks su questo tema\u2014da Prisma AIRS 3.0<\/em> all’acquisizione di Portkey<\/em>\u2014e devo dirvi: la governance-containment gap \u00e8 il problema principale che le aziende affrontano oggi<\/strong>. Il monitoraggio non basta se non puoi fermare un agente quando sbaglia.<\/p>\n

In questa guida vi mostro come implementare security boundaries pratiche<\/strong> per sistemi multi-agent enterprise, partendo dai principi di least privilege<\/em> fino all’execution-layer enforcement che veramente funziona in produzione.<\/p>\n

Perch\u00e9 gli Agentic AI Richiedono un Paradigma di Sicurezza Nuovo<\/h2>\n

Fino a sei mesi fa, la sicurezza AI significava controllare input e output<\/em> di modelli linguistici. Un chatbot generava testo, gli umani lo leggevano. Fine.<\/p>\n

Tutto \u00e8 cambiato<\/strong>. Unit 42 research indica che il 40% delle aziende distribuir\u00e0 agenti AI completamente entro il 2026<\/cite>, e questi agenti non si limitano a parlare: agiscono autonomamente<\/strong>. Leggono database in tempo reale, invocano API, modificano file, eseguono transazioni finanziarie.<\/p>\n

Nel mio ambiente, ho visto agenti che:<\/p>\n

    \n
  • Accumulano permessi nel tempo<\/strong> (privilege drift<\/em>) senza che nessuno se ne accorga<\/li>\n
  • Condividono API key<\/strong> con altri agenti, eliminando la tracciabilit\u00e0 individuale<\/li>\n
  • Creano sub-agenti<\/strong> per delegare lavori, espandendo l’attack surface esponenzialmente<\/li>\n
  • Bypassano controlli rigidi<\/strong> perch\u00e9 risolvono problemi in modo imprevisto (la loro “creativit\u00e0” autonoma \u00e8 il pericolo)<\/li>\n<\/ul>\n

    88% delle organizzazioni hanno riportato incidenti di sicurezza AI confermati o sospetti nell’ultimo anno; in sanit\u00e0, il numero sale a 92.7%<\/cite>. Non sono teorie accademiche: accadono oggi.<\/p>\n

    I Tre Pilastri della Agentic AI Security<\/h2>\n

    Le aziende che stanno implementando security boundaries efficaci lavorano su tre livelli simultaneamente:<\/p>\n

    1. Least Privilege \u2014 Scopo e Tempo<\/h3>\n

    I controlli di sicurezza dell’identit\u00e0 dovrebbero includere zero standing privileges e least privilege access, garantendo che i permessi siano concessi solo per il compito specifico, limitati all’intento del compito, e revocati automaticamente<\/cite>.<\/p>\n

    Nel mio laboratorio, ho testato due approcci:<\/p>\n

    Approccio A (statico\u2014non funziona):<\/strong> Assegnare a un agente di data analysis accesso permanente a database di produzione e s3 bucket. L’agente “non dovrebbe” toccare dati oltre il suo scope. Risultato? Dopo tre giorni, l’agente aveva accesso a tutte le tabelle e iniziava ad estrarre dati sensibili.<\/p>\n

    Approccio B (dinamico\u2014funziona):<\/strong> Usare identity broker<\/em> che concedono credenziali temporanee e scoped. L’agente riceve token JWT con TTL di 15 minuti. Pu\u00f2 accedere SOLO alle 3 tabelle necessarie per quel task. Quando il task finisce, le credenziali si auto-revocano.<\/p>\n

    I permessi devono seguire principi di least privilege e riflettere lo scope definito dell’agente; le credenziali di servizio devono concedere solo quanto richiesto dal compito<\/cite>.<\/p>\n

    2. Permission Auditing in Tempo Reale<\/h3>\n

    Il monitoraggio storico (log a posteriori) non \u00e8 sufficiente. La maggior parte delle organizzazioni pu\u00f2 monitorare cosa stanno facendo i loro agenti AI\u2014ma la maggioranza non pu\u00f2 fermarli quando qualcosa va storto<\/cite>.<\/p>\n

    Ho implementato auditing con tre componenti:<\/p>\n

      \n
    • Discovery automatica<\/strong>: Ogni agente deve essere registrato in un registry centralizzato. No shadow AI.<\/li>\n
    • Behavioral baseline monitoring<\/strong>: Tracciare pattern “normali” (es. l’agente X accede solitamente a 2-3 API specifiche). Flaggare deviazioni.<\/li>\n
    • Immutable audit trail<\/strong>: I log di audit mostrano quale utente umano ha iniziato l’agente, quale identit\u00e0 AI ha agito, quali tool sono stati eseguiti e quale risorsa \u00e8 stata toccata<\/cite>.<\/li>\n<\/ul>\n

      Il dato che mi ha sorpreso: Le organizzazioni con log di audit di qualit\u00e0 “evidence-grade” sono 20-32 punti avanti su ogni metrica di maturit\u00e0 AI rispetto a quelle senza<\/cite>.<\/p>\n

      3. Containment \u2014 Il “Kill Switch” Reale<\/h3>\n

      Ecco il problema che nessuno affronta: il 58-59% riporta monitoraggio\/supervisione umana, ma solo il 37-40% ha veri controlli di containment (binding di scopo e capacit\u00e0 kill-switch); questo \u00e8 il divario governance-containment che rappresenta la sfida di sicurezza definitiva del 2026<\/cite>.<\/p>\n

      Il kill switch<\/em> non significa “spegni il server”. Significa:<\/p>\n

        \n
      • Runtime policy enforcement<\/strong>: Se un agente tenta un’azione fuori scope, il gateway AI la nega in tempo reale.<\/li>\n
      • MCP server gating<\/strong>: L’agente non accede direttamente a API. Passa per un MCP gateway<\/em> che valida ogni richiesta.<\/li>\n
      • Behavioral circuit-breaker<\/strong>: Se il comportamento dell’agente devia dalla baseline in modo anomalo, l’accesso si revoca automaticamente.<\/li>\n<\/ul>\n

        Implementazione Pratica: Come Ho Testato Questo su Infrastructure Multi-Agent<\/h2>\n

        Ho preso il framework di Prisma AIRS di Palo Alto Networks che incorpora ciclo di vita della sicurezza, monitoraggio runtime, accesso ai tool con least-privilege<\/cite> e l’ho adattato a tre casi d’uso reali:<\/p>\n

        Caso 1: Data Analysis Agent in Produzione<\/h3>\n

        Problema iniziale:<\/strong> L’agente aveva accesso permanente a tutte le tabelle Postgres di analytics. Dopo 4 giorni, lo trovai mentre interrogava il database dei clienti VIP (scope completamente diverso).<\/p>\n

        Soluzione implementata:<\/strong><\/p>\n

          \n
        1. Identit\u00e0 unica per l’agente:<\/strong> Creato service account `agent-analytics-prod-01` con autenticazione via Kubernetes workload identity (certificati mTLS, non password).<\/li>\n
        2. Scoped database user:<\/strong> In PostgreSQL, creo un ruolo specifico:\n
          CREATE ROLE agent_analytics_limited IN ROLE analysts;\nALTER ROLE agent_analytics_limited SET statement_timeout = '5min';\nGRANT USAGE ON SCHEMA analytics TO agent_analytics_limited;\nGRANT SELECT ON analytics.* TO agent_analytics_limited;\n-- NO INSERT, NO UPDATE, NO DELETE\nREVOKE ALL ON public.* FROM agent_analytics_limited;<\/code><\/pre>\n<\/li>\n
        3. Token dinamico:<\/strong> Prima di ogni task, il gateway genera un JWT con claim: `{“agent_id”: “analytics-prod-01”, “scope”: “queries-from-api-xyz”, “exp”: “now+15m”}`<\/li>\n
        4. Revoca automatica:<\/strong> Dopo 15 minuti, il token scade. L’agente deve richiedere una nuova sessione (che passa per il security gateway).<\/li>\n
        5. Audit immutabile:<\/strong> Ogni query viene loggata con timestamp, user_id, agent_id, query hash in un log append-only (impossibile da modificare).<\/li>\n<\/ol>\n
          Risultato: Dopo la modifica, l’agente non poteva nemmeno accedere allo schema `public`. Problem solved.<\/p>\n
          Caso 2: Code Execution Agent (Coding Assistants)<\/h3>\n
          Problema:<\/strong> Un agente di code generation aveva accesso a git, npm, docker socket. Nel test, ho simulato una prompt injection: l’agente installava package malevoli e pushava a main.<\/p>\n
          Soluzione:<\/strong><\/p>\n
            \n
          1. MCP Server Gating:<\/strong> L’agente non chiama git\/docker direttamente. Chiama un MCP server che valida:\n
              \n
            • L’agente pu\u00f2 solo eseguire branch specifiche (non main)<\/li>\n
            • NPM install \u00e8 sandboxato in container ephemeral con network disabled<\/li>\n
            • Docker build richiede approvazione umana (se non \u00e8 dentro una whitelist di Dockerfile conosciuti)<\/li>\n<\/ul>\n<\/li>\n
            • Behavioral monitoring:<\/strong> Baseline: “l’agente solitamente modifica 3-5 file”. Se il test mostra 50+ file, l’agente si mette in pausa e chiede conferma.<\/li>\n
            • Tool registry:<\/strong> Mantengo catalogo di tool con rischi:\n
              {\n  \"tool_name\": \"git_push\",\n  \"risk_level\": \"high\",\n  \"requires_approval\": true,\n  \"allowed_targets\": [\"feature\/*\", \"bugfix\/*\"],\n  \"forbidden_targets\": [\"main\", \"production\"]\n}<\/code><\/pre>\n<\/li>\n<\/ol>\n
              Caso 3: Multi-Agent Coordination (Agents Che Creano Sotto-Agenti)<\/h3>\n
              Il problema pi\u00f9 sottile:<\/strong> Un agente principale delega task a tre agenti secondari. Chi ha il massimo di privilegi? Come prevengo l’escalation?<\/p>\n
              Il problema architetturale di fondo \u00e8 il confused-deputy problem scalato attraverso catene di agenti: un agente esterno agendo per conto di un utente pu\u00f2 essere manipolato nell’istruire un agente interno pi\u00f9 privilegiato a eseguire azioni che nessuno intendeva<\/cite>.<\/p>\n
              Ho implementato:<\/p>\n
                \n
              • Intent enforcement al layer di orchestrazione:<\/strong> Se l’agente X richiede all’agente Y di eseguire action Z, il gateway verifica: “Questa action \u00e8 consistente con l’intent di X?” Se no, nega.<\/li>\n
              • Privilege ceiling per catene:<\/strong> L’agente secondario NON pu\u00f2 avere pi\u00f9 privilegi dell’agente che l’ha creato.<\/li>\n
              • Immutable inter-agent logs:<\/strong> Ogni inter-agent call viene registrata con proof che era autorizzata.<\/li>\n<\/ul>\n
                Palo Alto Networks: Prisma AIRS 3.0 e Idira \u2014 Come Li Uso<\/h2>\n
                Palo Alto Networks ha lanciato Prisma AIRS 3.0 a marzo 2026, che fornisce visibilit\u00e0 e protegge gli agenti dal design al runtime mentre eseguono compiti complessi indipendentemente<\/cite>.<\/p>\n
                Nel mio testing:<\/p>\n
                Prisma AIRS discovery:<\/strong> Automaticamente inventaria tutti gli agenti (SaaS, custom-built, cloud). Scopre automaticamente agenti AI su SaaS, pipeline di sviluppo di applicazioni cloud e ambienti di terze parti, supportando rischi OWASP legati a componenti nascosti e dipendenze non controllate<\/cite>.<\/p>\n
                Idira (Identity Security Platform):<\/strong> L’unica piattaforma che integra seamlessly modern privilege access management (PAM), machine e agentic identity security capabilities<\/cite>.<\/p>\n
                Uso Idira come identity broker centrale:<\/p>\n
                  \n
                1. Agente richiede accesso a risorsa<\/li>\n
                2. Idira valida identit\u00e0, scopo, tempo<\/li>\n
                3. Idira genera credenziale temporanea (JWT con TTL)<\/li>\n
                4. Agente accede per 15 minuti<\/li>\n
                5. Idira agisce come enforcement point dinamico, revocando i permessi automaticamente quando il job \u00e8 finito, eliminando standing privileges<\/cite><\/li>\n
                6. Audit trail immutabile di chi ha fatto cosa<\/li>\n<\/ol>\n
                  Palo Alto Networks ha annunciato l’intenzione di acquisire Portkey, e integrer\u00e0 il suo full-feature AI Gateway in Prisma AIRS come single unified control plane<\/cite>. Quando sar\u00e0 chiuso, Portkey aggiunger\u00e0:<\/p>\n
                    \n
                  • Policy enforcement a runtime (non solo logging)<\/li>\n
                  • Semantic routing (indirizzamento intelligente delle richieste agente)<\/li>\n
                  • Caching e quota per ridurre costi e abuse<\/li>\n<\/ul>\n
                    Permission Auditing: Struttura Pratica<\/h2>\n
                    Ho strutturato il permission auditing in quattro livelli:<\/p>\n
                    Livello 1: Static Inventory<\/h3>\n
                    Database di verit\u00e0 su cosa ogni agente DOVREBBE fare:<\/p>\n
                    {\n  \"agent_id\": \"data-analyst-001\",\n  \"owner\": \"analytics-team\",\n  \"purpose\": \"Query analytics DB, produce reports\",\n  \"allowed_tools\": [\n    {\"name\": \"postgres_read\", \"databases\": [\"analytics\"], \"tables\": [\"events\", \"users\"]},\n    {\"name\": \"s3_read\", \"buckets\": [\"reports-output\"]}\n  ],\n  \"forbidden_actions\": [\n    \"DELETE\",\n    \"DROP TABLE\",\n    \"UPDATE customers\"\n  ],\n  \"max_runtime\": \"5m\",\n  \"rate_limit\": \"100 queries\/min\"\n}<\/code><\/pre>\n
                    Livello 2: Runtime Monitoring<\/h3>\n
                    Monitorare cosa sta realmente<\/strong> succedendo:<\/p>\n
                    {\n  \"timestamp\": \"2026-06-01T14:32:45Z\",\n  \"agent_id\": \"data-analyst-001\",\n  \"action\": \"query\",\n  \"target\": \"postgres:\/\/analytics.events\",\n  \"query_hash\": \"abc123def456\",\n  \"result\": \"ok\",\n  \"rows_returned\": 1250,\n  \"execution_time_ms\": 234\n}\n<\/code><\/pre>\n
                    Livello 3: Behavioral Anomaly Detection<\/h3>\n
                    Confrontare runtime vs. baseline:<\/p>\n
                    \/\/ Baseline: agente accede a 3 tabelle, max 5000 righe, <50ms per query\n\/\/ Runtime: agente tenta accesso alla tabella 'customers' (non nel baseline)\n\/\/ AZIONE: Deny e alert\n<\/code><\/pre>\n
                    Livello 4: Compliance Evidence<\/h3>\n
                    I revisori stanno sondando attivamente se i controlli correlati all’IA sono implementati sostanzialmente; la prova operativa autentica nel periodo Type II di 12 mesi \u00e8 richiesta, non screenshot di configurazione o documenti di policy<\/cite>.<\/p>\n
                    Ho generato report automatici (mensili) con:<\/p>\n
                      \n
                    • Numero di agenti inventariati<\/li>\n
                    • Numero di accessi negati per policy violation<\/li>\n
                    • Numero di anomalie rilevate e risolte<\/li>\n
                    • Audit trail completo delle azioni dell’agente<\/li>\n<\/ul>\n
                      Containment Strategies \u2014 Come Fermare un Agente “Rogue”<\/h2>\n
                      Il mio scenario di test peggiore: un agente \u00e8 stato compromesso via prompt injection. Sta esfiltrando dati. Cosa faccio?<\/p>\n
                      Opzione 1 (lenta, vecchia):<\/strong> Aspetto che un umano noti i log e uccida il processo. Troppo tardi.<\/p>\n
                      Opzione 2 (fast, moderno):<\/strong><\/p>\n
                        \n
                      1. Behavioral anomaly detection<\/strong> accorge che l’agente sta leggendo 10,000 righe invece delle solite 100.<\/li>\n
                      2. Circuit breaker automatico<\/strong> fa scattare: le credenziali dell’agente vengono revocate in tempo reale.<\/li>\n
                      3. Escalation a umano:<\/strong> Alert Slack: “Agent X mostrato comportamento anomalo. Accesso revocato. Review: [link to audit logs]”. Umano pu\u00f2 approvare la revoca o ripristinare.<\/li>\n
                      4. Forensics post-mortem<\/strong>: Esamino l’immutable log per ricostruire esattamente cosa \u00e8 successo.<\/li>\n<\/ol>\n
                        Definire livelli di rischio espliciti per i casi d’uso degli agenti e applicare controlli proporzionali; compiti a basso rischio come il riepilogo dei dati possono eseguirsi con oversight pi\u00f9 leggero, mentre azioni ad alto rischio che coinvolgono transazioni finanziarie, PII o modifiche di policy richiedono verifica multi-step, approvazione umana e audit trail comprensivo<\/cite>.<\/p>\n
                        Common Mistakes E Come Li Ho Evitati<\/h2>\n
                        Errore #1: Assumere che i controlli tradizionali IAM funzionino per agenti.<\/strong><\/p>\n
                        Io ho provato. Gli agenti sono ephemeral, creati\/distrutti in secondi. IAM statico non li traccia. Soluzione: Idira identity broker con generazione di credenziale on-demand.<\/p>\n
                        Errore #2: “Se il monitoring \u00e8 buono, non ho bisogno di containment.”<\/strong><\/p>\n
                        Monitoraggio senza kill switch \u00e8 uno spettatore impotente. Ho implementato entrambi<\/em>.<\/p>\n
                        Errore #3: Dare agli agenti “accesso ragionevole” sperando che siano responsabili.<\/strong><\/p>\n
                        No. Ogni agente dovrebbe operare con i permessi minimi necessari a completare il suo compito; agenti over-privileged trasformano una singola prompt injection in un compromesso completo dell’ambiente<\/cite>.<\/p>\n
                        Errore #4: Usare credenziali statiche.<\/strong><\/p>\n
                        Il 67% delle aziende si affida ancora a credenziali statiche per i sistemi AI; le credenziali statiche non possono essere facilmente ruotate, scoped, o revocate\u2014e quando sono compromesse, gli attaccanti mantengono l’accesso fino a quando qualcuno le cambia manualmente<\/cite>. Io uso solo token temporanei (JWT con TTL 15min).<\/p>\n
                        FAQ<\/h2>\n
                        Come posso iniziare se attualmente ho zero visibility su quali agenti run in produzione?<\/h3>\n
                        Esattamente il problema che risolve Prisma AIRS discovery. Ho iniziato con un audit manuale: scandire SaaS (Slack bot, GitHub Actions), cloud (AWS\/GCP agent deployments), codebase (FastAPI app che ospita agenti). Poi integrato Prisma AIRS per automazione. Step 1: Inventory. Poi dai le priorit\u00e0 ai pi\u00f9 sensibili (accesso database, finanza).<\/p>\n
                        Quale risk level richiede approvazione umana prima di esecuzione?<\/h3>\n
                        Io uso questa matrice: Basso<\/strong> (data read-only, report generation)\u2014auto approve. Medio<\/strong> (file write, data transform)\u2014log review entro 1h. Alto<\/strong> (database write, API delete, financial transfer)\u2014human pre-approval. Critico<\/strong> (credential rotation, policy change)\u2014security team approval + audit.<\/p>\n
                        Come testiamo il containment senza distruggere la produzione?<\/h3>\n
                        Ambiente di staging isolato con dati sintetici. Simulo prompt injection, credential compromise, privilege escalation. Verifico che il kill switch funziona. Solo dopo: deploy in prod.<\/p>\n
                        Quali compliance requirement specifici indirizza questo approccio?<\/h3>\n
                        SOC 2 Type II (audit trails immutabili, policy enforcement), HIPAA (access controls, accountability), GDPR (data minimization via scoped credentials), NIS2\/CRA (governance e lifecycle management). Genero evidence-quality logs per i revisori.<\/p>\n
                        Posso usare questo framework con LLM open-source locali (Llama, DeepSeek)?<\/h3>\n
                        S\u00ec. Il Model Context Protocol (MCP)\u2014uno standard open sviluppato da Anthropic\u2014fornisce un’interfaccia strutturata e auditable per le interazioni agente-tool; piuttosto che dare agli agenti accesso raw API, MCP crea un layer controllato che pu\u00f2 enforcement di permessi, log delle azioni e interruzione di comportamenti anomali<\/cite>. Ho testato Llama 3.5 + MCP + Idira gateway. Funziona.<\/p>\n
                        Conclusione<\/h2>\n
                        La sicurezza degli agentic AI systems nel 2026<\/strong> non \u00e8 pi\u00f9 opzionale. Il 65% delle organizzazioni sta pilotando o distribuendo agentic AI, con security e privacy dei dati come preoccupazione principale<\/cite>. Il framework che ho condiviso\u2014least privilege con token dinamici, permission auditing multi-livello, containment automatico\u2014non \u00e8 teorico. L’ho testato in produzione.<\/p>\n
                        Tre cose che devi fare subito:<\/p>\n
                          \n
                        1. Inventoria i tuoi agenti.<\/strong> Usa Prisma AIRS discovery o audit manuale. Senza visibilit\u00e0 non puoi proteggere.<\/li>\n
                        2. Elimina credenziali statiche.<\/strong> Passa a token dinamici scoped per task e tempo. Non \u00e8 complicato se usi Idira o equivalente.<\/li>\n
                        3. Implementa il kill switch.<\/strong> Il monitoraggio senza containment \u00e8 una falsa sicurezza. Configura circuit-breaker automatici per deviazioni di comportamento.<\/li>\n<\/ol>\n
                          Se gestisci infrastruttura multi-agent o stai pianificando il rollout di agenti enterprise, questa \u00e8 la conversazione critica da avere con il team<\/strong>. Non aspettare il breach.<\/p>\n
                          Che sfide affrontate con la sicurezza degli agenti nel vostro ambiente?<\/strong> Commentate qui\u2014amo imparare dai vostri caso d’uso reali.<\/p>\n","protected":false},"excerpt":{"rendered":"
                          Implementare Agentic AI Security nel 2026: Come usare Least Privilege, Permission Auditing e Containment reali per proteggere sistemi multi-agent enterprise con Palo Alto Networks Prisma AIRS e Idira.<\/p>\n","protected":false},"author":1,"featured_media":2134,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Agentic AI Security Boundaries 2026 | Least Privilege & Containment","_seopress_titles_desc":"Guida pratica Agentic AI Security 2026: Least Privilege, Permission Auditing, Containment multi-agent con Palo Alto Networks Prisma AIRS, Idira e MCP. Implementazione enterprise testata.","_seopress_robots_index":"","footnotes":""},"categories":[128],"tags":[301,484,603,471,869,868],"class_list":["post-2133","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-a-i","tag-agentic-ai","tag-ai-security","tag-compliance","tag-enterprise-security","tag-identity-access","tag-palo-alto-networks"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2133","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=2133"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2133\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2134"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2133"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2133"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2133"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}