How to Build Agentic AI on AWS: A Governed Serverless Data Mesh with Amazon Bedrock and S3 Tables

Layer 1: Agent Layer

AgentCore Runtime hosts the LangGraph agent in isolated microVM environments with session isolation. The agent integrates with MCP tools through the MCPClient class. This is your execution environment — serverless, isolated, and stateless per session.

Layer 2: Gateway Layer

The Gateway is where deterministic access control lives. It includes:

• A request interceptor that validates JWT tokens and enforces scope before any tool executes.
• A response interceptor that filters tool lists, redacts sensitive data, and writes audit logs.
• AgentCore Policy with Bedrock Guardrails that evaluates every tool invocation for prompt injection, harmful content, and sensitive information exposure in real time.

Layer 3: Tools Layer

Four Lambda-backed MCP tools provide governed data access: get_user_tables, get_schema, run_query, and kb_search. Each tool is scoped, audited, and constrained by the layers above and below it.

Layer 4: Governed Data Mesh

This is the data foundation. It consists of S3 Tables (Apache Iceberg format) registered in the AWS Glue Data Catalog, Amazon Athena with workgroup cost controls, Lake Formation enforcing row/column/cell-level security, and S3 Vectors powering Amazon Bedrock Knowledge Bases.

Setting Up S3 Tables with Apache Iceberg

For structured transactional data, use Amazon S3 Tables. It is the first cloud object store with built-in Apache Iceberg support, delivering up to 10x higher transactions per second compared to self-managed Iceberg tables on general-purpose S3 buckets. Compaction, snapshot management, and unreferenced file removal are handled automatically.

S3 Tables integrates with Amazon SageMaker Lakehouse, which populates the Glue Data Catalog and federates access through Lake Formation.

For the customer service agent, the Order Management domain publishes three data products:

• customer_orders
• customer_profiles
• interaction_history

All three are queryable from Athena, governed by Lake Formation permissions, and automatically compacted by S3 Tables.

Enforcing Row-Level and Column-Level Security with Lake Formation

This is where the governance gets precise. Lake Formation data filters enforce row-level security so the agent can only access records belonging to the authenticated customer.

A data filter on customer_orders with the row filter expression customer_id = :customer_id restricts every query to the current customer’s records — regardless of how the agent constructs its SQL. The run_query Lambda function injects the authenticated customer’s identity as a session parameter before submitting queries to Athena.

Column-level security hides sensitive fields like payment_method and billing_address from query results entirely. The agent never sees those columns, even if it tries to select them.

Building the Knowledge Base with Amazon S3 Vectors

Structured data answers transactional questions. Unstructured knowledge — return policies, product manuals, FAQs, troubleshooting guides — requires semantic search.

Amazon S3 Vectors provides native vector storage and querying as a fully serverless service. It supports up to 2 billion vectors per index with strong write consistency, meaning newly added vectors are immediately queryable.

Cost advantage: S3 Vectors can reduce vector storage and query costs by up to 90% compared to specialized vector database solutions in moderate query-frequency workloads. For high-QPS workloads requiring single-digit millisecond latency, Amazon OpenSearch Serverless remains the better fit. AWS provides a single-step export path from S3 Vectors to OpenSearch Serverless for workloads that outgrow the S3 Vectors performance profile.

S3 Vectors supports filterable metadata with string, number, boolean, and list types using operators like $eq, $ne, $gt, $in, $and, and $or. Store documents with filterable metadata keys like product_category and document_type to enable targeted semantic search.

A metadata filter that retrieves only electronics return policies looks like this:

{"$and": [{"product_category": {"$eq": "electronics"}}, {"document_type": {"$eq": "return"}}]}

The Four Core MCP Tools

Each tool is scoped to a specific data access pattern:

• get_user_tables — Queries the Glue Data Catalog filtered by Lake Formation permissions. Returns only the tables the authenticated user is authorized to see.
• get_schema — Retrieves column names, types, and descriptions for a specified table. Lake Formation column-level security automatically excludes restricted fields.
• run_query — Validates SQL against a read-only allowlist, injects customer identity for row-level filtering, and executes through Athena with byte-scan cost limits enforced.
• kb_search — Performs metadata-filtered semantic search against Amazon Bedrock Knowledge Bases backed by S3 Vectors.

The tool schema registration for run_query looks like this:

{
  "name": "run_query",
  "description": "Executes a read-only SQL query against governed Iceberg tables via Athena.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": {"type": "string", "description": "A read-only SQL SELECT statement."},
      "database": {"type": "string", "description": "The Glue Data Catalog database name."}
    },
    "required": ["sql", "database"]
  }
}

Note on native Knowledge Base targets: Amazon Bedrock Managed Knowledge Base is now available as a native pre-built target type in AgentCore Gateway. For production workloads where custom interceptor logic is not required, the native Managed KB target type eliminates the Lambda function entirely while retaining MCP compatibility and AgentCore Policy enforcement. The custom kb_search Lambda in this architecture demonstrates how Gateway interceptors enforce fine-grained authorization at the tool invocation boundary.

Three Interceptor Patterns That Matter

JWT scope-based tool invocation control. The request interceptor decodes the JWT scope claim and blocks unauthorized tool invocations before they execute.

Dynamic tool filtering. The response interceptor removes unauthorized tools from the tools/list response based on per-user scopes. The agent never discovers tools it cannot use.

Act-on-behalf identity propagation. Each hop receives a separate, scoped-down token. The Order tool gets only order:read. The KB tool gets only kb:search. An unauthorized downstream tool cannot reuse an overly privileged token.

The authorization check in the request interceptor:

def check_tool_authorization(scopes, tool, target):
    if target in scopes:
        return True
    return f"{target}:{tool}" in scopes

The response interceptor for dynamic tool filtering:

def lambda_handler(event, context):
    gateway_response = event['mcp']['gatewayResponse']
    auth_header = gateway_response['headers'].get('Authorization', '')
    token = auth_header.replace('Bearer ', '')
    claims = decode_jwt_payload(token)
    scopes = claims.get('scope', '').split()
    tools = gateway_response['body']['result'].get('tools', [])
    filtered_tools = [
        t for t in tools
        if check_tool_authorization(scopes, t['name'].split('.')[1], t['name'].split('.')[0])
    ]
    return {
        "interceptorOutputVersion": "1.0",
        "mcp": {
            "transformedGatewayResponse": {
                "statusCode": 200,
                "headers": {"Authorization": auth_header},
                "body": {"result": {"tools": filtered_tools}}
            }
        }
    }

Gateway interceptors enforce authorization deterministically at the tool invocation boundary before the model sees or executes tools. Athena byte-scan limits, read-only IAM policies, and Lake Formation row filters serve as compensating controls that bound the scope of any malformed queries the model might produce.

Step-by-Step Execution

Step 1 — Tool Discovery. The agent calls tools/list. The response interceptor filters the tool list based on JWT scopes and returns four authorized tools.

Step 2 — Table Discovery. get_user_tables is invoked. The request interceptor validates the JWT and confirms the order:read scope. The Lambda returns three tables: customer_orders, customer_profiles, and interaction_history.

Step 3 — Schema Discovery. get_schema on customer_orders reveals visible columns: order_id, status, ship_date, estimated_delivery, product_name. Lake Formation column-level security has already excluded payment_method and billing_address — they do not appear in the response.

Step 4 — Query Execution. The agent constructs:

SELECT order_id, status, ship_date, estimated_delivery
FROM customer_orders
WHERE order_id = '12345'

run_query injects the authenticated customer’s identity to resolve the Lake Formation row filter. Athena workgroup enforces a BytesScannedCutoffPerQuery limit. The query returns only records belonging to the authenticated customer.

Step 5 — Knowledge Base Retrieval. kb_search runs with query "return policy for electronics" and metadata filter {"product_category": {"$eq": "electronics"}}. The knowledge base returns: “Electronics may be returned within 30 days of purchase in original packaging for a full refund.”

Step 6 — Response Synthesis. The agent combines both results: “Your order #12345 shipped on March 20 and is estimated to arrive by March 25. Regarding the headphones, our electronics return policy allows returns within 30 days of purchase in original packaging. I can initiate a return for you. Would you like to proceed?”

Authorization was enforced at a different layer at each step — Gateway interceptors for steps 1–2, Lake Formation for steps 3–4, Athena workgroup limits for step 4, and S3 Vectors metadata filtering for step 5.

Why Gateway-Level Guardrails Beat Model-Only Guardrails

Applying guardrails solely at the model inference boundary is insufficient for agentic workloads. Agents invoke multiple tools and synthesize results across several hops. A guardrail at the model boundary only sees the final output — it misses what happened in between.

Gateway-level guardrails evaluate every agent-to-tool interaction at the point of action, not after the fact.