AWS Bedrock AgentCore è infrastruttura gestita per l’esecuzione di agenti di IA — il livello di calcolo, memoria, identità e accesso agli strumenti su cui gli agenti operano all’interno di AWS. Utilizza Cedar per l’autorizzazione granulare, lo stesso linguaggio di policy che Olivares AI impiega nel suo motore di governance. La convergenza su Cedar è la parte interessante; la divergenza risiede nel livello che ciascun prodotto occupa.
Nota: Questo confronto riguarda AgentCore come livello di infrastruttura di esecuzione degli agenti. AWS Bedrock include anche accesso ai modelli, Guardrails (sicurezza dei contenuti) e Knowledge Bases — tali capacità adiacenti sono trattate in vs AI gateways & Guardrails.
Cosa fa bene AgentCore (usalo per questo)
AgentCore è la risposta di AWS al problema operativo dell’esecuzione di agenti su larga scala su infrastruttura gestita:
- Runtime degli agenti. Calcolo gestito per l’esecuzione degli agenti — provisioning, scaling e ciclo di vita senza gestire la propria infrastruttura.
- Accesso agli strumenti. Connettività gestita tra agenti e servizi AWS (database, API, storage) con integrazioni di strumenti integrate.
- Autorizzazione Cedar. Controllo di accesso granulare, basato su attributi, con Cedar — lo stesso linguaggio di policy, le stesse proprietà di verifica formale.
- Osservabilità. Monitoraggio, logging e tracing integrati per l’esecuzione degli agenti all’interno dell’ecosistema AWS.
- Identità. Identità degli agenti legata a IAM — agenti come principal all’interno del modello di identità AWS.
Se il problema è “eseguire agenti su AWS con infrastruttura gestita, accesso agli strumenti con scope IAM e autorizzazione Cedar,” AgentCore lo risolve. Noi non reimplementiamo quel livello di esecuzione.
La lacuna di governance sopra il runtime
AgentCore governa ciò che gli agenti possono fare all’interno del confine del runtime AWS. Non risponde alle domande che sorgono quando gli agenti operano attraverso i confini infrastrutturali — cloud multipli, database on-premises, server MCP, strumenti self-hosted — o quando l’evidenza deve sopravvivere indipendentemente dalla piattaforma che l’ha prodotta.
| Lacuna lasciata dal runtime | Perché è importante | Cosa fornisce Olivares AI |
|---|---|---|
| Ambito multi-infrastruttura | AgentCore governa all’interno di AWS; molti ambienti abbracciano AWS, Azure, on-prem e strumenti self-hosted | Governance a livello infrastrutturale su qualsiasi ambiente — cloud, on-prem, air-gapped — attraverso un’unica mappa di accesso |
| Evidenza a prova di manomissione | I log del runtime sono record mutabili della piattaforma; un auditor necessita di prove verificabili in modo indipendente | Ledger append-only, concatenato tramite hash, firmato con Ed25519 — verificabile off-box, esportabile come evidenza OSCAL |
| Deployment agnostico rispetto al fornitore | AgentCore richiede AWS; i dati di governance risiedono nel servizio gestito di AWS | Self-hosted sulla propria infrastruttura — Linux, Docker, Kubernetes, air-gapped; i dati di governance non escono mai dal perimetro |
| Governance agnostica rispetto al framework | AgentCore governa agenti in esecuzione sul proprio runtime; gli agenti che utilizzano altri runtime necessitano di governance separata | Governa agenti di qualsiasi framework o runtime — Claude Code, AutoGen, LangGraph, custom — attraverso un unico piano |
| Intervento sulle sessioni attive | Controlli a livello di runtime; un kill switch o break-glass trasversale alle sessioni attive non è documentato | Approvazioni HITL, break-glass e un kill switch che nega ogni azione governata fino alla riattivazione con doppio controllo |
| Sovranità | Servizio gestito su AWS — i dati di governance risiedono nel cloud AWS | Self-hosted; le relazioni di accesso e il registro di governance restano sulla propria infrastruttura |
Queste non sono funzionalità del runtime. La lacuna è governance ed evidenza che si colloca sopra qualsiasi singolo runtime, non un runtime migliore.
La convergenza su Cedar
La decisione progettuale condivisa più significativa: sia Olivares AI sia AWS Bedrock AgentCore utilizzano Cedar per l’autorizzazione. Non si tratta di una sovrapposizione superficiale:
- Stesso linguaggio di policy. Il modello deny-by-default, basato su attributi, di Cedar fornisce proprietà di verifica formale che un RBAC ad-hoc non può eguagliare.
- Stesso modello mentale. Un’organizzazione che scrive policy Cedar per il runtime di AgentCore può scrivere policy Cedar per il piano di governance di Olivares con la stessa sintassi, la stessa semantica, gli stessi strumenti.
- Livelli componibili. AgentCore applica Cedar a livello di accesso agli strumenti del runtime; Olivares applica Cedar a livello di governance infrastrutturale. Stesso linguaggio, ambito differente, stesso archivio di policy a discrezione.
La convergenza su Cedar è la ragione per cui questi due prodotti si compongono in modo pulito anziché entrare in conflitto.
Quando AgentCore è la scelta giusta
- Si sta costruendo su AWS e si desidera infrastruttura di esecuzione gestita per gli agenti — provisioning, scaling, connettività degli strumenti, identità con scope IAM — senza gestire il proprio livello di calcolo.
- Il parco agenti è nativo AWS e il confine di governance coincide con il confine dell’account AWS.
- Si necessita di autorizzazione Cedar a livello di runtime e l’osservabilità gestita di AWS è sufficiente per i requisiti di conformità.
Quando Olivares è la scelta giusta
- Il parco agenti abbraccia cloud multipli, on-premises e infrastruttura self-hosted — e si necessita di un unico piano di governance per tutto.
- L’evidenza deve essere a prova di manomissione, verificabile in modo indipendente ed esportabile — non legata all’infrastruttura di logging di una singola piattaforma.
- Si necessita di un control plane self-hosted o air-gapped in cui i dati di governance non escano mai dal perimetro della propria infrastruttura.
- Si necessita di governance agnostica rispetto al fornitore che funzioni allo stesso modo sia che gli agenti siano eseguiti su AgentCore, su bare metal o nel proprio cluster Kubernetes.
Quando si compongono
Il deployment più solido combina entrambi:
- AgentCore come runtime gestito — esegue gli agenti su AWS, fornisce accesso agli strumenti con scope IAM e autorizzazione Cedar al confine del runtime.
- Olivares come piano di governance — fornisce visibilità a livello infrastrutturale, la mappa di accesso cross-runtime, evidenza a prova di manomissione e intervento sulle sessioni attive (kill switch, break-glass, HITL) sia per agenti su AgentCore sia per agenti altrove.
Stesso linguaggio Cedar a entrambi i livelli. Un unico modello mentale per le policy. Il runtime governa ciò che l’agente può chiamare; Olivares governa ciò che ha effettivamente raggiunto, e lo dimostra.
Correlati
- vs AI gateways & Guardrails — Bedrock Guardrails come hook di sicurezza dei contenuti, non come concorrente.
- vs AI control towers — dove si colloca la torre sopra il runtime e il piano di governance.
- Governing subscription-authed agents — come Olivares governa agenti che si autenticano con un abbonamento utente.