
Building a Production-Grade Multi-Agent Platform with Zero Trust Governance on Amazon Bedrock AgentCore
Enterprise AI agents without governance are insider threats that never sleep. We built a hierarchical multi-agent platform on Amazon Bedrock AgentCore that enforces Zero Trust on every tool call, deploys new agent versions with automatic rollback, detects rogue agents in real time, and produces compliance-ready audit trails for ITAR/EAR environments. Here's how.
Building a Production-Grade Multi-Agent Platform with Zero Trust Governance on Amazon Bedrock AgentCore
How We Built Enterprise Agent Lifecycle Management — From Onboarding to Canary Deployments — for a Semiconductor Company
Diksha Sharma | AWS Solutions Architect — Sr. AI/ML Specialist | Published April 28, 2026
TL;DR: We built a hierarchical multi-agent platform on Amazon Bedrock AgentCore that governs 12 AI agents across their full lifecycle — from qualification gates through canary deployments to automated quarantine. The platform enforces Zero Trust identity propagation on every tool call, detects rogue agents via AWS CloudTrail , and supports multi-framework interop (Strands, LangGraph, n8n) without vendor lock-in. Built for a semiconductor enterprise running 20,000+ agents at scale.
The Problem: Agents Without Governance Are a Liability
Every enterprise AI team hits the same wall. You've built impressive agent demos — they answer questions, call tools, retrieve documents. But when the CISO asks "who authorized that agent to access financial data at 2 AM?", you have no answer.
For semiconductor companies, the stakes are higher. Design IP worth billions flows through EDA tools. Revenue forecasts move stock prices. HR data is regulated. An ungoverned agent with broad tool access is an insider threat that never sleeps.
We built the Enterprise Multi-Agent Platform (EMP) to solve this — not as a framework, but as a complete governance system that treats agents as first-class identities requiring the same controls as human employees.
Architecture: Five Agents, One Orchestrator, Zero Trust Everywhere
The platform runs on Amazon Bedrock AgentCore with this topology:
Plain text
User (Flask UI) → Cognito Auth → JWT Token│▼Orchestrator Agent (Claude Sonnet 4.5)├── Zero Trust Gateway Interceptor ([AWS Lambda](https://aws.amazon.com/lambda/))├── AgentCore Memory (session persistence)├── Canary Router (weighted version selection)└── Routes to sub-agents:├── Finance Agent → [Bedrock Knowledge Base](https://aws.amazon.com/bedrock/knowledge-bases/) + [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)├── HR Agent → Knowledge Base + DynamoDB├── EDA Agent → [Strands Agents SDK](https://strandsagents.com/) Graph (RTL review loop)├── General Agent → Cross-cloud (Hugging Face Spaces)├── LangGraph Agent → A2A protocol adapter└── n8n Agent → On-prem workflow engine (webhooks)
Every arrow in this diagram passes through the AgentCore Gateway with a Lambda interceptor that enforces RBAC before any tool executes. The same query — "What's our Q3 revenue?" — returns different data depending on who's asking.
What Each Agent Actually Does
The orchestrator uses keyword-based routing to select the right sub-agent. Here's what a real conversation looks like:
Query | Routed To | What Happens |
|---|---|---|
"What are the Q4 2025 revenue metrics and analyst consensus?" | Finance Agent | RAG retrieval from Finance KB + DynamoDB scan of financial metrics table |
"Show me the engineering org chart and open requisitions" | HR Agent | RAG from HR KB + filtered scan of employee records table |
"Review the RTL design for the NextGen AI Accelerator ASIC" | EDA Agent | Strands Graph: intake → rtl_analysis → review_decision → approve/revise/escalate |
"Trigger the employee onboarding workflow" | n8n Agent | Webhook to on-prem n8n: validate → accounts → security → hardware → orientation → notify |
"Search local research papers for transformer optimizations" | Local Agent | MCP Server query against local paper index |
"What are the top AI chip demand trends for 2026?" | General Agent (HF) | Cross-cloud invocation to Hugging Face Spaces via AgentCore Gateway |
The EDA agent is particularly interesting — it uses the Strands Graph pattern with a conditional revision loop (up to 3 iterations) for RTL design reviews. If the review identifies issues, it cycles back through analysis before escalating to a human approver.
Key Insight #1: Identity Propagation Is Non-Negotiable
The most common failure in multi-agent systems is identity collapse. Agent A authenticates as a service account, calls Agent B, which calls a tool — and the tool has no idea which human initiated the request.
We solved this with an
IdentityContext dataclass that travels through every hop:Python
@dataclassclass IdentityContext:user_id: strrole: str # role_executive | role_manager | role_readonlybusiness_unit: str # finance | hr | eda | corporatesession_id: strpermitted_tools: List[str]data_scope: str # all | business_unit | summary
This context is passed via Strands
invocation_state — never exposed to the LLM's conversational context. The Gateway Interceptor checks it on every tool call. The tool Lambda checks it again independently. Two layers, neither trusts the other.The result: An executive sees all financial records. A manager sees only their business unit. A read-only user gets aggregate counts. Same agent, same query, different data — enforced at the data layer, not the prompt layer.
Why this matters for Zero Trust in agentic AI: Most enterprise platforms filter at the API gateway — if you can call the endpoint, you get the full dataset. That's insufficient when agents make autonomous tool calls on behalf of users with different clearance levels. In EMP, the tool Lambda itself applies
apply_rbac_filter() based on the caller's data_scope . Even if the gateway interceptor is misconfigured or bypassed, the data layer independently enforces access boundaries. This is defense-in-depth applied to AI — the same principle that makes Zero Trust architectures resilient to single-point failures.Here's what this looks like in practice. Same query, three roles, simultaneous execution:
Plain text
Query: "Show me the sensitive financial metrics — operating income,EBITDA, and cash flow for Q1 FY26"Executive (data_scope: all):→ Returns: Full financial data with analyst summaries,individual line items, YoY comparisonsManager (data_scope: business_unit):→ Returns: Only metrics for their assigned business unit,no cross-BU visibilityRead-Only (data_scope: summary):→ Returns: "3 financial metrics found for Q1 FY26"(count only — no actual figures)
The LLM sees the same prompt in all three cases. The difference is what data the tools return based on the caller's role. The model can't hallucinate data it was never given.
Key Insight #2: Agent Versioning with Automatic Rollback
Production agents need the same deployment discipline as microservices. You wouldn't deploy a new API version to 100% of traffic without canary testing — why would you do it with an agent?
We added versioning directly to the agent registry:
Python
# Registry schema additions per agent{"agent_id": "finance_agent_v2","agent_name": "finance_agent","version": 2,"traffic_weight": 10, # 10% of traffic"is_canary": True,"agent_arn": "arn:aws:bedrock-agentcore:..."}
The orchestrator's canary router does weighted random selection across versions:
Python
def select_version(agent_name: str) -> dict:versions = get_agent_versions(agent_name)weighted = [(v, v["traffic_weight"]) for v in versionsif v["traffic_weight"] > 0]# Weighted random pickr = random.randint(1, sum(w for _, w in weighted))cumulative = 0for version, weight in weighted:cumulative += weightif r <= cumulative:return version
Automatic rollback: If the canary version's composite evaluation score drops below 0.6 for 5 consecutive evaluations, traffic weight drops to zero and the stable version absorbs 100%. No human intervention required.
What happens during the 10% window? Users routed to the canary may receive lower-quality responses — but only 1 in 10 requests is affected, and the evaluation pipeline detects degradation within 5 invocations (typically under 2 minutes of active traffic). The moment rollback triggers, all traffic returns to the stable version. Users never see errors or data loss — just slightly worse answers for a brief, bounded window. This is the same trade-off every canary deployment makes: bounded blast radius in exchange for production validation that no staging environment can replicate.
Key Insight #3: Rogue Agent Detection via CloudTrail
Here's a scenario every enterprise will face: a developer deploys an agent outside the governed platform. It calls Bedrock directly, bypasses the gateway, and accesses data without RBAC filtering.
We detect this with a CloudTrail metric filter:
Python
# Matches API calls where the caller is NOT an AgentCore runtimefilter_pattern = FilterPattern.all(FilterPattern.exists("$.userIdentity.arn"),FilterPattern.string_value("$.userIdentity.arn", "!=", "*bedrock-agentcore*"),)
Alarm threshold: zero. Any single rogue call triggers an Amazon SNS notification. The UI shows a live comparison — compliant agent (full audit trail, RBAC enforced) vs. rogue agent (no governance, no filtering, no accountability).
Key Insight #4: Multi-Framework Without Vendor Lock-In
Enterprise customers won't standardize on one agent framework. Their ML team uses LangGraph. Their ops team built n8n workflows. Their platform team chose Strands.
EMP supports all three through the A2A (Agent-to-Agent) protocol:
Framework | Integration Pattern | Use Case |
|---|---|---|
Strands | Native (Agents-as-Tools) | Finance, HR, EDA agents |
LangGraph | A2A HTTP adapter | EDA design review (StateGraph) |
n8n | Webhook adapter | HR onboarding workflow (6 steps) |
External | Cross-cloud (HF Spaces) | General agent on Hugging Face |
The cross-cloud agent on Hugging Face Spaces isn't a novelty — it demonstrates that AgentCore primitives (Memory, Gateway, Identity) work regardless of where your agent is hosted. Your agents can live on any platform and still use AgentCore for persistence, governance, and observability. That's the point: AgentCore is the control plane, not the hosting constraint.
The orchestrator doesn't care what framework runs behind the A2A endpoint. It sends a payload, gets a response, logs the hop. Framework choice becomes a team-level decision, not a platform constraint.
n8n Integration: On-Prem Workflow Engines
The n8n integration deserves special mention because it mirrors the most common enterprise deployment pattern — the workflow engine stays where the sensitive data is (ERP, HR systems, design tools), and AgentCore orchestrates from the cloud.
When a user says "Trigger the employee onboarding workflow," the orchestrator calls n8n via a secure webhook. n8n executes a 6-step DAG: validate employee data → create accounts → configure security → order hardware → schedule orientation → notify manager. Each step writes to DynamoDB — action log (audit trail), approval queue (for escalations), token attribution (cost tracking), and evaluation scores (quality assessment).
The agent doesn't execute the workflow — it delegates to the workflow engine and reports back. This separation of concerns means the agent can be updated without touching the workflow, and vice versa.
Key Insight #5: Observability Is Not Optional
Every operation in EMP is observable through Amazon CloudWatch GenAI Observability — no custom dashboards required.
Plain text
CloudWatch GenAI Dashboard shows:├── Invocations — per agent, per round, with latency P50/P95├── Memory — write and read events per memory ID├── Latency — orchestrator is slowest (routing overhead)├── Identity — workload identity requests per agent└── Custom Metrics — EnterpriseAgentPlatform namespace├── RogueAgentAPICallCount (alarm threshold: 0)├── AgentInvocationCount (by agent_name)└── TokenUsage (by model, by agent)
But the real observability story is the structured audit logging. Every identity-bearing operation emits a JSON log entry:
JSON
{"event_type": "identity_audit","user_id": "exec_user","session_id": "sess-abc123","role": "role_executive","agent_name": "finance_agent","tool_name": "get_financial_metrics","action": "query","records_returned": 12,"records_filtered": 0,"timestamp": "2026-04-28T14:30:00Z"}
And every agent-to-agent delegation emits a hop log:
JSON
{"event": "agent_hop","source_agent": "orchestrator","target_agent": "finance_agent","latency_ms": 234,"user_id": "exec_user","timestamp": "2026-04-28T14:30:00Z"}
These logs answer the question every CISO asks: "Who accessed what data, through which agent, at what time?" Without them, a data breach investigation is impossible.
Key Insight #6: Persistent Memory Across Sessions
AgentCore Memory gives every agent a persistent memory that survives across sessions. The orchestrator loads memory at the start of each conversation and saves it at the end:
Python
# Load memory at conversation startmemory_events = ac.list_events(memoryId=memory_id,actorId="orchestrator",sessionId=session_id,maxResults=10)# Save memory after responseac.create_event(memoryId=memory_id,sessionId=session_id,actorId="orchestrator",eventTimestamp=datetime.now(timezone.utc),payload=[{"conversational": {"role": "USER", "content": {"text": query}}},{"conversational": {"role": "ASSISTANT", "content": {"text": response}}},],)
This means "last quarter's revenue" resolves correctly even in a new conversation — the agent remembers what "last quarter" meant in context. The cross-cloud agent on Hugging Face shares the same memory ID, proving that memory persistence works regardless of where the agent is hosted.
The Agent Lifecycle: From Birth to Retirement
Every agent in EMP goes through a governed lifecycle:
- QUALIFYING — Runs 4 qualification gates: property tests (≥0.95 pass rate), evaluation score (≥0.75), security scan, 48-hour pilot
- PILOT — Limited traffic via canary routing (10-20%)
- ACTIVE — Full production traffic
- UNDER_REVIEW — Flagged by drift detection or feedback loop; write tools blocked
- SUSPENDED — Credentials revoked, all tools blocked, requires two-approver reinstatement
- DECOMMISSIONED — Offboarded, removed from gateway
Behavioral drift detection: After 100 invocations establish a baseline, every 10th response is compared via cosine similarity. Drift score > 0.5 triggers a WARNING; drift > 0.7 triggers automatic quarantine — write permissions drop to read-only in real time.
Research basis: AgenticOps practices (InfoWorld, March 2026); NIST AI RMF MONITOR 2.2 (continuous monitoring of AI system behavior).
Agent Quality Assessment
Every agent response is scored on 4 dimensions in real time:
Dimension | Weight | What It Measures |
|---|---|---|
Completeness | 30% | Did the response fully address the query? |
Groundedness | 30% | Are claims backed by retrieved data (KB or DynamoDB)? |
Task Success | 25% | Did the agent achieve the user's stated goal? |
Hallucination Risk | 15% (inverted) | Lower is better — penalizes fabricated claims |
Composite Score = 0.3 × completeness + 0.3 × groundedness + 0.25 × task_success + 0.15 × (1 - hallucination_risk)
Scores below 0.7 for 3 consecutive evaluations trigger an SNS alert. The quality chart in the UI shows the trend over time — you can visually spot degradation before it hits the threshold.
How we implemented it: A judge agent (Claude Sonnet 4.5) evaluates each response against the original query and the retrieved context. The evaluation runs asynchronously — it doesn't block the user response. Results are stored in a DynamoDB evaluation scores table with a GSI on
agent_id + timestamp for efficient time-series queries.Research basis: Andrew Ng's agentic evaluation patterns (2025); Gartner prediction that 40% of enterprise AI projects will require continuous evaluation by 2027.
Human-in-the-Loop Approval Queue
Not every agent action should execute autonomously. HIGH-risk operations (financial writes, credential changes, data deletions) pause mid-execution and wait for human approval.
Python
# In the gateway interceptorif risk_tier == "HIGH" and action_type == "write":# Create approval request in DynamoDBtable.put_item(Item={"action_id": str(uuid4()),"agent_id": agent_id,"tool_name": tool_name,"payload": json.dumps(tool_input),"status": "PENDING","requested_by": identity_context.user_id,"requested_at": datetime.now(timezone.utc).isoformat(),})return {"status": "PENDING_APPROVAL", "message": "Action requires human review"}
The UI shows pending approvals grouped by agent. A reviewer can approve (execution resumes), reject (action cancelled), or request modification. Every decision is logged with reviewer ID and timestamp.
Research basis: EU AI Act Article 14 (human oversight requirements for high-risk AI systems); NIST AI RMF GOVERN 1.7 (human oversight mechanisms).
Reversible Action Log
Every write operation in EMP captures before/after state — making any action reversible with one click.
JSON
{"action_id": "act-7f3a2b","agent_id": "finance_agent","tool_name": "update_financial_metric","pre_state": {"metric_id": "rev-q4", "value": 2847000, "status": "draft"},"post_state": {"metric_id": "rev-q4", "value": 3102000, "status": "published"},"user_id": "exec_user","timestamp": "2026-04-28T14:30:00Z","rollback_available": true,"status": "PENDING"}
When a reviewer clicks "Rollback," the system executes the inverse operation — restoring
pre_state — and logs the rollback as a new action entry. The audit trail is append-only; nothing is ever deleted.Research basis: Broadcom "reversible autonomy" research (2025); NIST AI RMF MANAGE 2.4 (mechanisms to revert AI system actions).
Cost and Token Attribution
At 20,000+ agent scale, you need to know exactly where your AI spend is going. EMP tracks token usage per invocation with full attribution:
JSON
{"attribution_id": "tok-9c4e1a","agent_id": "finance_agent","model_id": "claude-haiku-4.5 (via global on-demand inference profile)","input_tokens": 1247,"output_tokens": 892,"cost_usd": 0.0018,"user_id": "exec_user","business_unit": "finance","timestamp": "2026-04-28T14:30:00Z"}
The UI shows 4 cost views: by agent, by business unit, by user profile, and by model. This answers "which team is spending the most on AI?" and "should we move this agent from Sonnet to Haiku to save cost?"
Token pricing rates are stored in AWS Systems Manager Parameter Store — not hardcoded — so they update without redeployment when model pricing changes.
Research basis: FinOps Foundation AI Cost Framework (2025); enterprise customer requirement for chargeback at 20,000+ agent scale.
Context Compression
Long multi-turn conversations accumulate tokens fast. When context exceeds the threshold, EMP automatically compresses the conversation into a KnowledgeBlock:
Python
# Triggered when context > token_thresholdsummary = compress_context(conversation_history=full_history,strategy="knowledge_block", # preserves key facts, preferences, entities)# Typical savings: 35-65% token reduction
The compression event is logged with tokens before/after and compression ratio. The UI shows a timeline of compression events per session — useful for debugging when an agent "forgets" something from early in a long conversation.
Agent Qualification Gates
No agent goes to production without passing 4 gates:
Gate | Criterion | What It Tests |
|---|---|---|
Gate 1 | Property tests ≥ 0.95 pass rate | Routing correctness, RBAC enforcement, lifecycle transitions |
Gate 2 | Evaluation score ≥ 0.75 | Response quality across 20+ test queries |
Gate 3 | Security scan pass | Injection resistance, credential handling, data leakage |
Gate 4 | 48-hour pilot stable | No drift, no errors, no approval queue overflows |
The qualification workflow runs as a DAG — gates execute sequentially, and failure at any gate blocks progression. The UI shows live gate status during qualification.
Research basis: NIST AI RMF MANAGE 1.3 (pre-deployment testing requirements); enterprise customer verbatim: "ensure 5 things before production."
Privilege Quarantine
When a security engineer spots a misbehaving agent, they need a middle ground between "do nothing" and "shut it down." Quarantine provides that:
- Agent transitions to
UNDER_REVIEWstate
- Gateway permissions immediately override to read-only (within 5 seconds)
- Agent continues serving read queries — no business disruption
- Two-approver reinstatement review is required to restore write access
Quarantine can be triggered manually from the UI (from the Agent Registry or directly from an Action Log entry) or automatically by drift detection when drift score exceeds 0.7.
Research basis: NIST SP 800-61 (incident response — immediate containment); NIST SP 800-207 (Zero Trust — continuous re-evaluation, access reduction on anomalous behavior); NIST AI RMF RESPOND 1.1.
Structured Offboarding
When an agent reaches end-of-life, it goes through a 6-step offboarding workflow:
- Revoke credentials — ephemeral credentials invalidated
- Remove from gateway — tool access terminated
- Archive registry entry — marked DECOMMISSIONED with timestamp
- Export evidence package — compliance archive generated
- Notify stakeholders — SNS to agent owner and security team
- Clean up resources — memory, logs retained per retention policy
This mirrors the HR offboarding process for human employees — because agents ARE digital employees with the same governance requirements.
Research basis: Forbes "AI agents as digital employees" (2025); cydenti agent lifecycle research (2025); enterprise customer verbatim: "digital employee... offboarding."
Feedback Loop and Self-Improvement
Users rate agent responses (1-5 stars) with optional failure categories: incomplete, irrelevant, inaccurate, wrong tone. When negative feedback accumulates:
-
negative_countincrements per agent
- Threshold reached → agent becomes
FEEDBACK_CANDIDATE
- System generates revised prompt based on failure patterns
- Revised prompt runs regression tests against historical queries
- If regression passes → deploy as canary (10% traffic)
- If regression fails 3x →
ESCALATED(human intervention required)
- If fails 5x →
RETIREMENT_CANDIDATE
This creates a closed loop: user feedback → automated improvement → validated deployment → monitoring. No human needs to manually rewrite prompts.
Research basis: Andrej Karpathy's autoresearch loop (2025); Andrew Ng's agentic self-reflection patterns (2025).
Compliance Evidence Export
One-click export generates a tamper-evident compliance package:
- All audit logs for the selected time window
- Agent registry state at time of export
- Evaluation scores and drift history
- Approval queue decisions with reviewer IDs
- SHA-256 hash of the entire package for tamper detection
This is designed for SOC 2 Type II auditors, ITAR/EAR compliance officers, and ISO 27001 certification reviews. The auditor gets a single ZIP file that proves the complete chain of accountability — no manual log assembly required.
Research basis: SOC 2 Type II CC7.2 (system monitoring); EU AI Act Articles 12-13 (logging and transparency requirements).
What We Learned Building This
1. Defense-in-depth is worth the complexity. Two independent RBAC checks (gateway + tool) caught 3 bugs during development where one layer would have silently passed unauthorized requests.
2. Agent versioning pays for itself immediately. The first time we deployed a prompt change that degraded finance agent quality, the canary router caught it at 10% traffic and rolled back automatically. Without it, 100% of users would have seen degraded responses.
3. Rogue detection changes behavior. Once developers know unregistered agents trigger alerts, they voluntarily onboard through the platform. The governance system becomes self-reinforcing.
4. The audit trail is the compliance story. 19 DynamoDB tables capture structured audit logs for every identity-bearing operation — who accessed what data, through which agent, at what time, with what role. Hop-by-hop tracing across multi-agent chains produces a tamper-evident accountability record. For semiconductor companies operating under ITAR/EAR export controls, SOC 2 Type II, or ISO 27001, this audit chain is the difference between "interesting demo" and "we can actually deploy this in production."
5. The orchestrator is not a single point of failure. It's stateless by design — no local state between invocations. If it fails mid-request, the client retries with the same
session_id and AgentCore Memory rehydrates the full conversation context. The orchestrator is replaceable infrastructure, not a bottleneck.6. Memory persistence is table stakes. AgentCore Memory means the orchestrator remembers context across sessions — "last quarter's revenue" resolves correctly even in a new conversation because the agent remembers what "last quarter" meant in context.
Try It Yourself
The platform runs on standard AWS services — no custom hardware, no exotic dependencies:
- Compute: Amazon Bedrock AgentCore (5 runtimes deployed via
agentcore launch)
- Models: Claude Sonnet 4.5 (orchestrator), Claude Haiku 4.5 (sub-agents) — all via global on-demand inference profiles
- Data: DynamoDB (19 tables, PAY_PER_REQUEST, KMS encrypted, 90-day TTL)
- Knowledge Bases: 3 Bedrock Knowledge Bases (Finance, HR, EDA) backed by S3
- Auth: Amazon Cognito (User Pool with 4 demo personas: Executive, Manager, Analyst, Read-Only)
- Memory: AgentCore Memory (5 memory IDs — one per agent)
- Observability: CloudWatch GenAI dashboard, AWS X-Ray active tracing, CloudTrail metric filters, SNS alerts
- Gateway: AgentCore Gateway with Lambda interceptor (RBAC + lifecycle + injection detection)
- UI: Flask with Jinja2 templates (8 tabs)
- Local services: n8n workflow server, MCP paper index, local A2A agent
- Cross-cloud: Hugging Face Space with AgentCore Memory + Gateway registration
Configuration Pattern
Nothing is hardcoded. All config lives in AWS Systems Manager Parameter Store under a project-specific prefix, with secrets in AWS Secrets Manager . Lambda functions receive only two environment variables (
APP_REGION , SSM_PREFIX ) and fetch everything else at cold start — agent ARNs, KB IDs, memory IDs, pricing rates, and thresholds are all centralized and update without redeployment.
A Note on AgentCore Registry
Since we built this platform, Amazon Bedrock AgentCore has launched its own Registry primitive — a managed service for agent discovery, metadata storage, and lifecycle tracking. Several capabilities we custom-built in DynamoDB now have native equivalents:
Capability | What We Built (Custom) | What AgentCore Registry Provides Natively |
|---|---|---|
Agent registration & metadata | DynamoDB table with agent_id , owner, BU, risk tier, status | Managed registry with agent metadata, descriptions, and tags |
Agent discovery | Custom discovery table + keyword routing | Semantic search across registered agents by capability |
Lifecycle state tracking | Custom state machine (6 states) in DynamoDB | Built-in lifecycle states with transition rules |
Version management | version + traffic_weight fields in registry | Native versioning with alias support |
Cross-account visibility | Manual scan via CloudTrail | Federated registry across accounts and organizations |
What we still needed to custom-build — governance logic that goes beyond what any single primitive provides today:
- Behavioral drift detection — cosine similarity scoring against a baseline, with auto-quarantine triggers
- Canary routing with automatic rollback — weighted traffic splitting with quality-gated rollback logic
- Privilege quarantine — instant read-only override with two-approver reinstatement
- Feedback loop → self-improvement — closed loop from user ratings to automated prompt revision and canary deployment
- Compliance evidence export — tamper-evident ZIP with SHA-256 hash aggregating data from multiple sources for auditors
- Agent qualification gates — multi-gate DAG (property tests + eval score + security scan + pilot) as a promotion workflow
The takeaway: if you're starting a new multi-agent project today, use AgentCore primitives as your foundation — they eliminate significant custom code. Then layer the governance logic (drift detection, quarantine, feedback loops, qualification DAGs) on top. The primitives give you the building blocks; the governance layer answers "should this agent be allowed to do this right now?"
What's Next: Migrating Custom Code to AgentCore Primitives
Several capabilities we custom-built are now available — or becoming available — as native AgentCore primitives. Here's our migration roadmap:
What We Built Custom | AgentCore Primitive to Migrate To | Status |
|---|---|---|
Custom RBAC tool filtering ( TOOL_ROLE_MAP in Lambda) | AgentCore Gateway Policy — Cedar policies for tool-level authorization based on JWT claims | Available now |
Custom DynamoDB agent registry | AWS Agent Registry — managed catalog with semantic search, approval workflows, cross-account federation | Available now |
Custom token tracking in DynamoDB | AgentCore Observability — native CloudWatch metrics for token usage, cost allocation via tags, GenAI dashboard | Available now |
CloudTrail metric filter for rogue detection | Agent Registry approval workflows — preventive control (unregistered agents can't enter the catalog) + Gateway Policy denies unregistered callers | Available now |
Custom quality assessment (judge agent) | AgentCore Evaluation — built-in evaluation metrics and scoring | Evolving |
Custom identity propagation code | AgentCore Identity — workload identity with OAuth2/JWT, automatic token propagation across hops | Available now |
Still Exploring
Beyond the migration, we're building toward:
- Automated prompt improvement — using the feedback loop to generate and A/B test prompt revisions without human intervention
- Cost-aware routing — factoring AgentCore Observability's native token metrics into the canary router's selection algorithm alongside quality scores
- LLM-managed Knowledge Base — replacing traditional RAG with Karpathy-style markdown files that the agent itself maintains, updates, and cross-references — a self-healing knowledge base that improves with every interaction
- AgentCore Registry migration — replacing our custom DynamoDB registry with the native Agent Registry primitive for all supported capabilities (metadata, discovery, lifecycle, versioning)
- EC2-hosted on-prem services — moving the local MCP server and n8n workflow engine from localhost to a dedicated EC2 instance for persistent availability
- Terminal-based demo mode — a rich CLI interface (
richlibrary) for running the full demo from the command line — persona selection, query execution, RBAC comparison, trace visualization, and governance simulations with colored panels and tables. No browser needed.
- Cedar policy migration — replacing our custom
TOOL_ROLE_MAPLambda with AgentCore Gateway's native Policy engine for declarative, auditable access control
Complete Feature List
For reference, here's every capability implemented in EMP:
# | Feature | How It Works |
|---|---|---|
1 | Hierarchical multi-agent orchestration | Orchestrator routes to 7 sub-agents via keyword matching |
2 | Zero Trust Gateway with RBAC | Lambda interceptor checks role against TOOL_ROLE_MAP on every tool call |
3 | Identity propagation (end-to-end) | IdentityContext dataclass travels via invocation_state through every hop |
4 | Defense-in-depth (2 independent checks) | Gateway interceptor + tool Lambda both verify role independently |
5 | Agent lifecycle management (6 states) | QUALIFYING → PILOT → ACTIVE → UNDER_REVIEW → SUSPENDED → DECOMMISSIONED |
6 | Agent versioning + canary routing | Weighted random selection across versions; automatic rollback on quality drop |
7 | Behavioral drift detection | Cosine similarity every 10th invocation; auto-quarantine at threshold |
8 | Rogue agent detection | CloudTrail metric filter for non-AgentCore API calls; zero-threshold alarm |
9 | Quality assessment (4 dimensions) | Judge agent scores completeness, groundedness, task success, hallucination risk |
10 | Human-in-the-loop approval queue | HIGH-risk writes pause for human review; approve/reject/modify |
11 | Reversible action log | Before/after state for every write; one-click rollback |
12 | Cost and token attribution | Per-invocation tracking by agent, user, BU, model |
13 | Context compression | KnowledgeBlock summarization when context exceeds token threshold |
14 | Persistent memory (AgentCore Memory) | Session context survives across conversations; cross-cloud shared |
15 | Agent qualification gates (4 gates) | Property tests, eval score, security scan, 48h pilot |
16 | Privilege quarantine | Read-only override within 5 seconds; two-approver reinstatement |
17 | Structured offboarding (6 steps) | Credential revocation → gateway removal → archive → evidence → notify → cleanup |
18 | Feedback loop + self-improvement | User ratings → failure analysis → prompt revision → canary deploy |
19 | Compliance evidence export | One-click ZIP with SHA-256 hash for SOC 2/ITAR auditors |
20 | Multi-framework interop (Strands/LangGraph/n8n) | A2A protocol adapters; framework-agnostic orchestration |
21 | Cross-cloud agent hosting (HF Spaces) | AgentCore Memory + Gateway work with agents hosted outside AWS |
22 | On-prem workflow integration (n8n) | Webhook-based delegation to self-hosted workflow engines |
23 | Strands Graph pattern (EDA agent) | Conditional revision loop for RTL design reviews (≤3 iterations) |
24 | Structured audit logging | JSON logs for every identity-bearing operation |
25 | Hop-by-hop tracing | Every agent delegation logged with source, target, latency, user |
26 | CloudWatch GenAI Observability | Native dashboard — invocations, memory, latency, identity |
27 | X-Ray distributed tracing | Active tracing on every Lambda and Runtime |
28 | Injection detection | Gateway scans for instruction-override patterns in tool inputs |
29 | Credential TTL enforcement | Expired ephemeral credentials return 401 |
30 | Cognito authentication | JWT-based auth with 4 demo personas |
31 | Portable infrastructure | Parameterized for any AWS account — no hardcoded values |
32 | Demo simulation (12 scenarios) | Baseline, drift, qualification, quarantine, rogue, HITL, canary, offboarding |
33 | Property-based testing (36+ properties) | pytest + hypothesis covering routing, RBAC, lifecycle, drift, compression |
Research References
This platform was informed by the following research and standards:
Source | What We Used It For |
|---|---|
| NIST NCCoE, "Accelerating Adoption of AI Agent Identity and Authorization" (Feb 2026) | Identity propagation architecture, workload identity model |
| Marro et al., "Authenticated Delegation and Authorized AI Agents" — arXiv:2501.09674 (ICML 2025) | Delegation chain design, credential scoping |
| IETF, "OAuth 2.0 Extension for Multi-AI Agent Collaboration" (2025) | Token propagation patterns |
| EU AI Act Articles 12-14 (August 2026) | Logging, transparency, and human oversight requirements |
| NIST AI RMF (GOVERN, MANAGE, MONITOR, RESPOND functions) | Qualification gates, drift monitoring, incident response |
| NIST SP 800-207 (Zero Trust Architecture) | Defense-in-depth, continuous re-evaluation |
| NIST SP 800-61 (Incident Response) | Privilege quarantine as immediate containment |
| AWS Well-Architected Reliability Pillar — Canary Deployments | Agent versioning and traffic splitting |
| Andrew Ng, "Agentic Design Patterns" (2025) | Self-reflection, tool use, planning patterns |
| Andrej Karpathy, "Autoresearch Loop" (2025) | Feedback-driven self-improvement |
Satya Nadella on Agent Provenance (2026) | Decision lineage and accountability |
| MuleSoft Agent Fabric (2026) | Federated agent discovery, cross-platform governance |
| InfoWorld, "AgenticOps Practices" (March 2026) | Behavioral drift detection, operational governance |
| FinOps Foundation AI Cost Framework (2025) | Token attribution and chargeback at scale |
Broadcom "Reversible Autonomy" Research (2025) | Action log with rollback capability |
| SOC 2 Type II CC7.2 | Compliance evidence export requirements |
| Forbes, "AI Agents as Digital Employees" (2025) | Lifecycle management, onboarding/offboarding |
The Enterprise Multi-Agent Platform is an open reference implementation for AWS Solutions Architects working with enterprise customers who need governed, auditable AI agent systems. Built on Amazon Bedrock AgentCore, Strands Agents SDK, and standard AWS services.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Related Resources:
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article