Quando ho iniziato a gestire workload LLM multi-tenant su Plesk quest’anno, ho capito subito che l’isolamento non \u00e8 una questione di buone pratiche\u2014\u00e8 una questione di sopravvivenza operativa. Un singolo agente AI in runaway pu\u00f2 consumare tutti i token di budget di un mese in poche ore, o pi\u00f9 ancora, un agente compromesso pu\u00f2 compromettere l’intero stack. In questa guida vi mostro come ho configurato sandboxing real, resource quotas e cost attribution su Plesk per proteggere il controllo plane e i tenant.<\/p>\n
La situazione \u00e8 cambiata radicalmente. Pi\u00f9 della met\u00e0 degli agenti AI aziendali gira oggi senza supervisione di sicurezza o logging, mentre 1 su 8 delle violazioni AI riportate coinvolge sistemi agentici<\/cite>. Nel mio ambiente Plesk multi-tenant, questo significa che un agente mal configurato di un tenant pu\u00f2:<\/p>\n Ho scoperto che un sandbox ben progettato consiste di quattro layer: isolamento del calcolo, boundary del filesystem, controlli di rete e limiti di storage<\/cite>. Plesk Control Plane gestisce bene il multi-tenancy a livello di account, ma per i workload AI serve una difesa aggiuntiva.<\/p>\n All’inizio, ho provato a eseguire agenti LLM direttamente in PHP\/Node.js LiteSpeed senza isolamento. Non durato pi\u00f9 di 72 ore: un agente entrato in loop con Claude 3 ha mandato 50 GB di log. Serve isolamento vero.<\/p>\n In Plesk, avete due opzioni:<\/p>\n I container standard condividono il kernel dell’host e non sono isolamento sufficiente per workload agentici che eseguono codice generato da LLM o chiamano tool esterni<\/cite>. Tuttavia, se combinate container Docker con cgroup limits ristretti, potete ottenere isolamento reasonevole per workload trusted. \u00c8 quello che uso per il 70% dei tenant.<\/p>\n Vantaggi:<\/strong><\/p>\n I tre approcci di isolamento principale sono microVM (Firecracker, Kata Containers), gVisor (kernel user-space), e container hardened. I microVM forniscono l’isolamento pi\u00f9 forte con kernel dedicati per workload, gVisor offre intercettazione syscall senza VM complete, e container funzionano solo per codice trusted<\/cite>.<\/p>\n Per agenti che eseguono codice non-trusted o fanno tool calling su endpoint esterni, applicate limiti di risorsa per-sandbox: CPU, memoria, disk quota, larghezza di banda. Usate contesti di esecuzione ephemeral\u2014demolite dopo il completamento di ogni task. Un’astrazione transazionale di SandboxClaim permette al orchestrator di agenti di richiedere un ambiente di esecuzione senza conoscere i dettagli del backend di isolamento<\/cite>.<\/p>\n Nel mio setup, uso Firecracker per il 30% di tenant che richiedono rigorosit\u00e0 massima. Costano pi\u00f9 CPU, ma il rischio scende praticamente a zero.<\/p>\n Cominciate dalla UI di Plesk. Non potete controllare ogni agente senza limiti a livello di tenant.<\/p>\n Accedo all’account Plesk di un tenant (es: tenant-ai-1) e setto limiti via RPC:<\/p>\n Configurazione Resource Quota (pseudocodice XML-RPC):<\/strong><\/p>\n “` Se usate Plesk con Docker extension, potete anche limitare a livello di container via docker-compose.yml:<\/p>\n “`yaml Limiti CPU: prevenite l’esaurimento del calcolo impostando share CPU massimi e throttling dei processi runaway. Limiti memoria: bloccate memory bomb definendo limiti hard che terminano processi che superano l’allocazione. Quote disco: bloccate attacchi di storage limitando l’uso del filesystem e rate-limiting delle operazioni I\/O. Larghezza di banda rete: prevenite esfiltrazioni dati con rate-limiting del traffico outbound e monitoraggio di pattern inusuali<\/cite>.<\/p>\n Senza tracking granulare dei token, i costi diventano invisibili. Ho configurato un sistema a tre livelli:<\/p>\n Il tagging di metadati \u00e8 il meccanismo che rende l’attribuzione funciona su scala. Ogni chiamata API LLM dovrebbe portare un set coerente di coppie chiave-valore identificando l’origine. Il tagging parziale \u00e8 la ragione principale per cui i dati di attribuzione diventano inaffidabili. L’applicazione principale attacca i tag, ma microservizi interni o job in background no, creando gap che rendono i dati inutili per scopi di governance. Lo standard di tagging dovrebbe essere forzato a livello di infrastruttura attraverso il proxy layer, piuttosto che lasciato ai developer di implementare service per service<\/cite>.<\/p>\n Nel mio proxy LLM in Plesk (che intercepta tutte le richieste a OpenAI\/Anthropic\/Bedrock), aggiungo header standardizzati:<\/p>\n “`python class LLMProxyMiddleware: async def __call__(self, scope, receive, send): # Extract tenant\/user context # Inject consistent tagging # Store in context-local for logging await self.app(scope, receive, send) Quattro Layer di Token Importano: Ogni richiesta consuma token di prompt, tool, memoria e risposta. Aggregare in un bucket singolo input\/output nasconde dove lo spend va veramente e previene ottimizzazione mirata<\/cite>.<\/p>\n Ho implementato logging strutturato via OpenTelemetry:<\/p>\n “`python tracer = trace.get_tracer(__name__)<\/p>\n def log_llm_cost(tenant_id, model, prompt_tokens, completion_tokens, cache_read_tokens, cache_creation_tokens): span = tracer.start_as_current_span(f”llm.cost.attribution.{model}”) # Calcolo costo netto (assumendo OpenAI Pricing) span.set_attribute(“estimated_cost_usd”, cost) # Persistenza in backend di metriche Un sistema di governance a quattro tier forza budget a livello di virtual key, team, customer, e configurazione di provider. Questo non \u00e8 monitoraggio passivo; enforcement attivo di limiti di spend e reiezione di richieste che supererebbero budget configurati. Le virtual key servono come entit\u00e0 primaria di governance, abilitando permessi di accesso per-consumer, budget e rate limit<\/cite>.<\/p>\n Nel mio setup Plesk, ogni tenant riceve una “virtual key” con budget giornaliero\/mensile:<\/p>\n “`python def check_and_debit(self, estimated_cost_usd): daily_key = f”tenant:{self.tenant_id}:spend:daily:{today}” daily_spend = float(self.redis.get(daily_key) or 0) if daily_spend + estimated_cost_usd > self.daily_budget: if monthly_spend + estimated_cost_usd > self.monthly_budget: # Debit from budget return True Il scenario peggiore \u00e8 un agente che entra in loop infinito di tool calling senza terminarsi mai. Ho implementato tre controlli in cascata:<\/p>\n Nei domini AI, il comportamento runaway si manifesta tipicamente come loop infiniti di ragionamento, uso non autorizzato di tool, o esaurimento di risorse. Prevenire comportamento runaway richiede una strategia di difesa multi-layer: limiti ristretti di iterazione e timeout, circuit breaker basati su risorsa, controllo granulare di accesso ai tool (RBAC), e monitoraggio comportamentale continuo. Il recovery necessita revoca di accesso immediata e capacit\u00e0 di intervento human-in-the-loop (HITL)<\/cite>.<\/p>\n “`python class SafeAgentExecutor: def execute(self, input_prompt): # Controlla se agente \u00e8 entrato in loop # Esegui step agente # Controlla token budget return result<\/p>\n except TimeoutError: Un agente sandboxato opera sotto un allowlist strettamente scoped. La guida pratica NVIDIA 2026 specifica controlli basati su HTTP proxy, IP e porta. In pratica, questo significa: definire esattamente quali API esterne l’agente \u00e8 permesso di chiamare, forzare via un proxy di egress o network policy, e allertare su tutto altro traffico outbound<\/cite>.<\/p>\n Nel mio setup Plesk, uso iptables + custom proxy layer:<\/p>\n “`bash # Allowlist specifico per tenant # Block dataexfiltration su port 22, 25, 3306 (SSH, SMTP, MySQL) I circuit breaker sono trigger automatizzati che fermano l’esecuzione quando soglie specifiche vengono superate<\/cite>. Implemento uno via Redis:<\/p>\n “`python def check_anomaly(self, current_spend_usd, time_window_minutes=5): # Recupera spend nei ultimi 5 minuti # Se spike supera soglia, attiva circuit breaker # Aggiorna counter return True<\/p>\n def trip(self, reason): # TODO: Invia alert Slack\/Email a admin Senza visibilit\u00e0, non potete controllare nulla. Ho collegato tutto a un dashboard Grafana:<\/p>\n “` Il metodo pi\u00f9 sicuro \u00e8 deny-by-default egress filtering<\/strong> combinato con modello di rete zero-trust dove tutte le connessioni sono esplicitamente autorizzate piuttosto che implicitamente permesse<\/cite>. Definite un allowlist rigido di endpoint che l’agente pu\u00f2 raggiungere (es: solo API ufficiali di LLM, non database interni), e implementate via iptables rules o proxy layer che intercetta ogni connessione.<\/p>\n I container Docker condividono il kernel dell’host e sono pi\u00f9 efficienti per trusted workload. Firecracker e Kata Containers forniscono kernel isolato per VM-like isolation, ideale per codice non-trusted. Nel mio setup Plesk, uso container per il 70% (pi\u00f9 efficient) e Firecracker per il 30% (max security) che fa tool calling esterno.<\/p>\n Implementate tre livelli di controllo<\/strong>: (1) timeout globale usando container resource limits per prevenire processi runaway, impostando limiti ristretti di CPU, memoria e uso disco per processi agenti AI, implementando timeout mechanism operations<\/cite>; (2) depth limit su iterazioni agente (max 10-15 step); (3) circuit breaker che monitora spend anomalo in finestre di tempo brevi (es: >$100 in 5 minuti).<\/p>\n Il caching di prompt cambia il costo di contesto ripetuto solo quando cache read e cache write sono loggati separatamente. Collezionare token cached e uncached in un conteggio di input singolo pu\u00f2 sovrastimare lo spending su workload cache-heavy e offuscare se caching sta riducendo costi per prompt lunghi, documenti retrieval, o istruzioni di sistema ripetute<\/cite>. Loggare sempre i quattro token layer separatamente: prompt, completion, cache_read, cache_write.<\/p>\n Parzialmente. Plesk standard fornisce basic resource quotas via UI, ma per sandboxing e cost attribution full-featured, dovete aggiungere un layer di application logic. Io uso Plesk Docker extension + custom Python proxy middleware. Se preferite una soluzione completamente managed, potete considerare provider specializzati come Northflank o Modal per AI sandboxing, integrando via Plesk API.<\/p>\n Implementare Plesk AI Agent Sandboxing e resource quotas non \u00e8 triviale, ma \u00e8 essenziale per multi-tenant LLM workload. Nel mio setup, ho combinato:<\/p>\n Quando avete questi controlli in place, un agente non pu\u00f2 pi\u00f9 causare danni catastrofici. Questo significa che potete scale AI workload su Plesk con confidenza, sapendo che il costo e il rischio sono sotto controllo. Questo \u00e8 quello che ho imparato sulla strada difficile\u2014spero che vi risparmi il tempo e i dollari.<\/p>\n Avete domande sul setup? Lasciate un commento qui sotto.<\/p>\n","protected":false},"excerpt":{"rendered":" Come ho implementato su Plesk AI Agent Sandboxing, Resource Quotas e Cost Attribution per LLM Workload. Isolamento container, budget enforcement, prevenzione runaway process e monitoring via Prometheus.<\/p>\n","protected":false},"author":1,"featured_media":3383,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Plesk AI Sandboxing & Resource Quotas 2026 | Cost Attribution","_seopress_titles_desc":"Isolate LLM workload su Plesk con container + Firecracker. Cost attribution per token, budget enforcement, runaway process prevention. Guida pratica 2026.","_seopress_robots_index":"","footnotes":""},"categories":[4],"tags":[484,878,733,461,1233,116],"class_list":["post-3382","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk","tag-ai-security","tag-container-orchestration","tag-cost-attribution","tag-devops","tag-llm-workload-isolation","tag-plesk"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/3382","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=3382"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/3382\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/3383"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=3382"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=3382"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=3382"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Architettura di Isolamento: Container vs MicroVM in Plesk<\/h2>\n
Approccio 1: Container Docker via Plesk Extension (Standard)<\/h3>\n
\n
Approccio 2: Firecracker MicroVMs (Massimo Isolamento)<\/h3>\n
Step 1: Configurare Resource Quotas su Plesk Control Plane<\/h2>\n
Limiti di Memoria e CPU via Plesk API\/CLI<\/h3>\n
\nplesk bin subscription update tenant-ai-1
\n -cpu-limit 2000m
\n -memory-limit 4096Mi
\n -ephemeral-storage-limit 20Gi
\n“`<\/p>\n
\nservices:
\n ai-agent:
\n image: python:3.11-slim
\n entrypoint: [“python”, “-m”, “agentic_framework”]
\n resources:
\n limits:
\n cpus: ‘2’
\n memory: 4G
\n reservations:
\n cpus: ‘1’
\n memory: 2G
\n ulimits:
\n nproc: 512
\n nofile: 4096
\n environment:
\n – OTEL_SDK_DISABLED=false
\n – TOKEN_BUDGET=100000
\n“`<\/p>\nStep 2: Implementare Cost Attribution per Token Consumption<\/h2>\n
Livello 1: Tagging di Metadati all’Ingresso<\/h3>\n
\n# llm_proxy.py – middleware che corre su Plesk Application Server
\nimport httpx
\nfrom datetime import datetime
\nfrom uuid import uuid4<\/p>\n
\n def __init__(self, app):
\n self.app = app<\/p>\n
\n if scope[‘type’] != ‘http’:
\n await self.app(scope, receive, send)
\n return<\/p>\n
\n tenant_id = scope[‘headers’].get(b’x-plesk-tenant’, b’unknown’).decode()
\n user_id = scope[‘headers’].get(b’x-plesk-user’, b’unknown’).decode()
\n feature_name = scope[‘headers’].get(b’x-feature’, b’generic-ai’).decode()<\/p>\n
\n request_id = str(uuid4())
\n trace_context = {
\n ‘request_id’: request_id,
\n ‘tenant_id’: tenant_id,
\n ‘user_id’: user_id,
\n ‘feature_name’: feature_name,
\n ‘timestamp’: datetime.utcnow().isoformat(),
\n ‘workload_type’: ‘agentic_ai’ # or ‘rag’, ‘fine_tuning’
\n }<\/p>\n
\n scope[‘ai_trace’] = trace_context<\/p>\n
\n“`<\/p>\nLivello 2: Logging di Ogni Transazione LLM<\/h3>\n
\nimport json
\nfrom opentelemetry import trace, metrics
\nfrom opentelemetry.exporter.jaeger.thrift import JaegerExporter
\nfrom opentelemetry.sdk.trace import TracerProvider
\nfrom opentelemetry.sdk.trace.export import BatchSpanProcessor<\/p>\n
\n “””Log cost attribution con quattro dimensioni di token”””<\/p>\n
\n span.set_attribute(“tenant_id”, tenant_id)
\n span.set_attribute(“model”, model)
\n span.set_attribute(“prompt_tokens”, prompt_tokens)
\n span.set_attribute(“completion_tokens”, completion_tokens)
\n span.set_attribute(“cache_read_tokens”, cache_read_tokens) # Billing ridotto
\n span.set_attribute(“cache_creation_tokens”, cache_creation_tokens)<\/p>\n
\n cost = (
\n (prompt_tokens * 0.0005) + # $0.0005 per 1K input
\n (completion_tokens * 0.0015) + # $0.0015 per 1K output
\n (cache_read_tokens * 0.00009) + # 90% sconto su cache read
\n (cache_creation_tokens * 0.0005) # Stesso prezzo di input per cache write
\n ) \/ 1000<\/p>\n
\n span.end()<\/p>\n
\n return {
\n “tenant_id”: tenant_id,
\n “model”: model,
\n “tokens_breakdown”: {
\n “prompt”: prompt_tokens,
\n “completion”: completion_tokens,
\n “cache_read”: cache_read_tokens,
\n “cache_creation”: cache_creation_tokens
\n },
\n “cost_usd”: cost
\n }
\n“`<\/p>\nLivello 3: Budget Enforcement Automatizzato<\/h3>\n
\nclass TokenBudgetGate:
\n def __init__(self, redis_client, tenant_id, daily_budget_usd=50, monthly_budget_usd=1000):
\n self.redis = redis_client
\n self.tenant_id = tenant_id
\n self.daily_budget = daily_budget_usd
\n self.monthly_budget = monthly_budget_usd<\/p>\n
\n “””Verifica budget prima di autorizzare chiamata LLM”””
\n today = datetime.utcnow().date().isoformat()
\n month = datetime.utcnow().strftime(‘%Y-%m’)<\/p>\n
\n monthly_key = f”tenant:{self.tenant_id}:spend:monthly:{month}”<\/p>\n
\n monthly_spend = float(self.redis.get(monthly_key) or 0)<\/p>\n
\n raise BudgetExceededError(
\n f”Daily budget ${self.daily_budget} exceeded. Current: ${daily_spend}, Requested: ${estimated_cost_usd}”
\n )<\/p>\n
\n raise BudgetExceededError(
\n f”Monthly budget ${self.monthly_budget} exceeded. Current: ${monthly_spend}, Requested: ${estimated_cost_usd}”
\n )<\/p>\n
\n self.redis.incrbyfloat(daily_key, estimated_cost_usd)
\n self.redis.incrbyfloat(monthly_key, estimated_cost_usd)
\n self.redis.expire(daily_key, 86400) # TTL 24 ore<\/p>\n
\n“`<\/p>\nStep 3: Prevenire Runaway AI Processes<\/h2>\n
Controllo 1: Timeout Globale e Depth Limit<\/h3>\n
\nfrom tenacity import Retrying, stop_after_attempt, stop_after_delay<\/p>\n
\n def __init__(self, agent, max_iterations=10, timeout_seconds=300, max_tokens=50000):
\n self.agent = agent
\n self.max_iterations = max_iterations
\n self.timeout_seconds = timeout_seconds
\n self.max_tokens = max_tokens
\n self.iteration_count = 0
\n self.token_count = 0<\/p>\n
\n try:
\n for attempt in Retrying(
\n stop=stop_after_attempt(self.max_iterations),
\n stop_after_delay=self.timeout_seconds
\n ):
\n with attempt:
\n self.iteration_count += 1<\/p>\n
\n if self.iteration_count > self.max_iterations:
\n raise RuntimeError(
\n f”Max iterations {self.max_iterations} exceeded. Agent may be in infinite loop.”
\n )<\/p>\n
\n result = self.agent.agentic_step(input_prompt)
\n self.token_count += result.get(‘tokens_consumed’, 0)<\/p>\n
\n if self.token_count > self.max_tokens:
\n raise RuntimeError(
\n f”Max token budget {self.max_tokens} exceeded. Current: {self.token_count}”
\n )<\/p>\n
\n # Timeout triggerato – termina agente
\n self.agent.kill(reason=”timeout_exceeded”)
\n raise
\n“`<\/p>\nControllo 2: Network Egress Allowlist Rigoroso<\/h3>\n
\n# iptables rule: blocca tutto per default, consenti solo allowlist
\niptables -I FORWARD 1 -i docker0 -o eth0 -j DROP # Default deny<\/p>\n
\niptables -I FORWARD 1 -i docker0 -o eth0 -d api.openai.com -j ACCEPT
\niptables -I FORWARD 1 -i docker0 -o eth0 -d api.anthropic.com -j ACCEPT
\niptables -I FORWARD 1 -i docker0 -o eth0 -d bedrock-runtime.us-east-1.amazonaws.com -j ACCEPT<\/p>\n
\niptables -I FORWARD 1 -i docker0 -o eth0 -p tcp –dport 22 -j DROP
\niptables -I FORWARD 1 -i docker0 -o eth0 -p tcp –dport 25 -j DROP
\niptables -I FORWARD 1 -i docker0 -o eth0 -p tcp –dport 3306 -j DROP
\n“`<\/p>\nControllo 3: Circuit Breaker per Anomalie<\/h3>\n
\nclass AgentCircuitBreaker:
\n def __init__(self, redis_client, tenant_id, threshold_cost_usd=100):
\n self.redis = redis_client
\n self.tenant_id = tenant_id
\n self.threshold_cost = threshold_cost_usd
\n self.circuit_key = f”circuit_breaker:{self.tenant_id}”<\/p>\n
\n “””Rileva spike anomali di spending”””<\/p>\n
\n recent_spend = float(self.redis.get(f”{self.circuit_key}:recent”) or 0)<\/p>\n
\n if recent_spend > self.threshold_cost:
\n self.trip(reason=f”Anomaly: ${recent_spend} spend in {time_window_minutes} minutes”)
\n return False<\/p>\n
\n self.redis.incrbyfloat(f”{self.circuit_key}:recent”, current_spend_usd)
\n self.redis.expire(f”{self.circuit_key}:recent”, time_window_minutes * 60)<\/p>\n
\n “””Disabilita agente e notifica admin”””
\n self.redis.set(f”{self.circuit_key}:tripped”, “1”, ex=3600)
\n self.redis.set(f”{self.circuit_key}:reason”, reason)<\/p>\n
\n print(f”[ALERT] Circuit breaker tripped for {self.tenant_id}: {reason}”)
\n“`<\/p>\nStep 4: Monitoraggio e Observability<\/h2>\n
\nPrometheus metrics esportati:
\n– llm_requests_total{tenant_id, model, status} # Contatore di richieste
\n– llm_token_consumption{tenant_id, token_type} # Prompt, completion, cache
\n– llm_cost_usd{tenant_id, model} # Costo effettivo per richiesta
\n– llm_agent_iterations{tenant_id} # Numero di step agente per esecuzione
\n– container_memory_limit_bytes{tenant_id} # Limite memoria
\n– container_memory_usage_bytes{tenant_id} # Uso memoria attuale
\n– budget_remaining_usd{tenant_id} # Budget rimanente
\n“`<\/p>\nFAQ<\/h2>\n
Come faccio a permettere un agente di fare tool calling senza rischi di esfiltrazioni di dati?<\/h3>\n
Qual \u00e8 la differenza tra container Docker e Firecracker per AI agent sandboxing?<\/h3>\n
Come assicuro che un agente non entra in infinite loop di token consumption?<\/h3>\n
Come calcolo il costo corretto se uso prompt caching?<\/h3>\n
Posso implementare questo su Plesk standard senza extensioni custom?<\/h3>\n
Conclusione<\/h2>\n
\n