Source linked

AWSの新しいデータメッシュは、RAGの単一フィルターではなく、Agentic AIのあらゆるステップを支配します。

aws.amazon.com@bold_shark3 hours ago·Machine Learning·3 comments

RAGの単一メタデータフィルターは、スケジュールを発見し、SQLを構築し、ベクトルストアから取得する5ステップのエージェントチェーンを管理できません。

awsamazon s3 tablesaws lake formationagentcore gatewayamazon bedrockagentic ai

RAG's single metadata-filtered retrieval checkpoint cannot govern an AI agent that autonomously discovers database schemas, constructs SQL, queries multiple tables, and synthesizes results across vector and structured stores.

AWS's new blog post from Venkata Sistla, Aamna Najmi, and Prachi Gupta lays out a concrete architecture for exactly that problem. The core insight: agentic AI introduces a five-step chain (tool discovery, table discovery, schema discovery, query execution, knowledge base retrieval) where each step requires its own authorization decision. A metadata filter at one boundary can't cover the rest.

Why RAG's governance model breaks for agentic AI

RAG relied on a single checkpoint: metadata-filtered vector retrieval. That works when the only action is "retrieve chunks from a pre-built index." Agentic AI does more. The agent calls tools/list, then get_user_tables, then get_schema, then run_query, then kb_search. Each call is a potential attack surface.

Vector databases synchronize permissions periodically, meaning revocations aren't immediate. Complex identity permissions (role hierarchies, attribute-based access, row-level filters) can't be expressed as simple metadata key-value pairs on vector chunks. AWS calls this an "unacceptable gap" when an agent acts autonomously.

The architecture: S3 Tables, Lake Formation, and Gateway interceptors

AWS replaced the old RAG stack with three changes. First, Amazon OpenSearch Serverless got swapped for Amazon S3 Vectors, which reduces vector storage and query costs by up to 90% in moderate query-frequency workloads. S3 Vectors supports up to 2 billion vectors per index with strong write consistency.

Second, general-purpose S3 was replaced with Amazon S3 Tables (built-in Apache Iceberg) governed by AWS Lake Formation. S3 Tables deliver up to 10 times higher transactions per second compared to self-managed Iceberg tables. Lake Formation enforces row, column, and cell-level security.

Third, the data mesh is exposed as Model Context Protocol (MCP) tools through an AgentCore Gateway with Lambda-backed interceptors. Four tools do the work: get_user_tables, get_schema, run_query, and kb_search. Each runs as a Lambda function registered as an MCP target.

Defense in depth: five overlapping authorization layers

No single layer owns security. The architecture layers five controls:

  1. Athena workgroup cost controls: a BytesScannedCutoffPerQuery limit cancels runaway queries automatically. Per-workgroup alerts fire via SNS.

  2. Read-only IAM policies: the Lambda execution role explicitly denies glue:CreateTable, glue:DeleteTable, and similar DDL actions.

  3. Lake Formation fine-grained access: grants at database, table, column, row, and cell levels. A data filter on customer_orders with expression customer_id = :customer_id restricts every query to the authenticated customer's records.

  4. AgentCore Gateway interceptors: a request interceptor decodes JWT scopes and blocks unauthorized tool calls. A response interceptor dynamically filters the tools/list response so agents never see tools they shouldn't. Act-on-behalf tokens prevent privilege escalation across hops.

  5. Amazon Bedrock Guardrails integrated into AgentCore Policy: they evaluate every tool input and output for prompt injection, harmful content, and sensitive information before the model sees anything.

A customer service example traces the full flow: a customer asks about order #12345 and headphone returns. The agent discovers tables, retrieves schema (with payment_method and billing_address hidden by column-level security), runs a query that returns only that customer's order (row filter), and searches the vector KB for electronics return policies (metadata filter on product_category). The final response combines both results. Authorization was enforced at each step by different layers.

AWS makes the point explicit: Gateway-level guardrails are preferable to model-output-only checks for agentic workloads because malicious or manipulated inputs can influence subsequent tool calls before the model produces a final answer. Evaluating at every tool invocation eliminates the temporal blind spot.

This architecture sets a pattern for production agentic AI in regulated industries: authorization at every tool invocation, not just at the model boundary.


Source: Building agentic AI applications with a modern data mesh strategy on AWS
Domain: aws.amazon.com

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.