.png)
An AI agent can answer a customer question only as well as the information it is allowed to use. Consider a service agent asked, “Why has this order not shipped, and what can the customer do next?” A useful answer may require the latest order status, inventory data, a delivery policy, and the customer’s support history. Those sources have different owners, update schedules, and access rules.
Giving the agent broad access to every source would be simple to prototype and difficult to govern. A production design needs to give the agent current, relevant information while enforcing the same data permissions the organization applies to its people and applications.
AWS provides the components for this approach. Apache Iceberg tables in Amazon S3 Tables can hold structured business data. Amazon S3 Vectors can support semantic search across documents. AWS Lake Formation can govern table access, while Amazon Bedrock AgentCore Gateway can expose approved data operations as tools.
Together, these services form a serverless data foundation that an agent can use through controlled, auditable requests. This article shows how these services fit together to support governed, production-ready agentic AI applications on AWS.
.png)
A conventional retrieval-augmented generation application usually follows a fairly fixed path: receive a question, retrieve relevant document passages, and use them to produce an answer. An agent can take a less predictable route. It may discover available tools, inspect a table schema, generate a query, search a knowledge base, combine results, and decide whether another tool call is needed.
Each step creates a separate access decision. A user may be allowed to see shipping dates but not payment details. The agent may be allowed to search a returns policy but not an internal fraud procedure. Even when a query is permitted, its result may contain fields that should not appear in the final response.
Governance therefore has to follow the full request:
1. Tool discovery: Which operations may this user’s agent see?
2. Tool invocation: Is this user allowed to run the selected operation?
3. Data access: Which tables, rows, columns, and documents may that operation read?
4. Query execution: Is the request valid, read-only, and within cost limits?
5. Response handling: Does the returned content need filtering or redaction?
These checks belong in the services and tool implementations that execute the request. A prompt can tell an agent to respect a permission boundary, but it cannot enforce that boundary.
A data mesh organizes data around the business teams that understand and own it. For an agentic application, that might mean the orders domain publishing order and shipment tables, while a support domain publishes approved policies and case guidance. Each domain (or department) remains responsible for data quality and access rules; the agent receives a consistent way to request information across them.
On AWS, the structured side of this architecture can use S3 Tables, AWS Glue Data Catalog, AWS Lake Formation, and Amazon Athena. The document side can use S3 Vectors and a retrieval tool that applies the appropriate metadata and identity filters. AgentCore Gateway then presents approved operations to the agent through a common tool interface.
The separation matters operationally. A data owner can update a table or policy document without redesigning the agent. A security team can change permissions without relying on a new prompt. The agent can answer a question using both live business records and written guidance, while each source retains its own governance controls.
Apache Iceberg is an open table format for large analytical datasets. The data itself is stored in files, while Iceberg maintains metadata describing which files belong to a table and how they should be read. A table change creates a new snapshot. Readers can use a consistent snapshot even while new data is being written.
That design solves several problems that arise when an application queries files directly in object storage. Iceberg supports atomic table changes, schema evolution, partition evolution, and access to earlier snapshots. A data team can add a column or change how a table is partitioned without rebuilding every consumer around a folder layout. Snapshot history also helps teams investigate what data was available when an agent produced a particular answer. Retention settings determine how long that history remains available.
Iceberg makes particular sense on AWS because S3 provides durable storage for the table’s data, while AWS analytics services can work with Iceberg tables through catalog integrations. S3 Tables adds a managed home for Iceberg tables, including maintenance operations such as compaction and snapshot management. Teams gain the flexibility of an open format while reducing the work involved in maintaining table files and metadata themselves.
For an AI agent, the practical benefit is a dependable view of changing business data. An agent answering a question about an order should query a governed table with a defined schema and a consistent snapshot. It should not have to infer the latest state from a collection of raw files.
Many agent use cases need structured facts: an order’s current state, an account’s service tier, a product’s availability, or the date a claim was submitted. Those facts may change frequently, so a static document index is a poor substitute for a query against current records.
S3 Tables stores this tabular data as managed Iceberg tables. Data engineers can publish curated tables with clear names and documented fields, then register and govern them for analytics access. Athena can query the tables, and Lake Formation can help control which data a role is permitted to read. S3 Tables also performs table maintenance, including compaction, which helps address the small-file problem that can accumulate as data changes.
An agent should still reach these tables through a narrow tool. For example, a get_order_status tool could accept an order ID, verify that the caller is authorized for that order, execute an approved query, and return only the fields needed for the answer. A more flexible analytical tool might permit selected read-only queries, but it would require stronger SQL validation, permissions, and cost limits.
This distinction keeps the table useful beyond a single AI application. Analysts and other approved systems can use the same governed data product, while the agent receives a purpose-built interface suited to its task.
Structured tables explain what happened. Documents often explain what it means and what should happen next. A shipment table might show that a delivery is delayed; a policy document might explain when a refund or replacement is available.
A knowledge base prepares those documents for semantic search. During ingestion, the application extracts text, splits it into useful passages, generates embeddings, and stores the resulting vectors with metadata. That metadata should include attributes needed for retrieval and governance, such as document type, language, business domain, version, and access classification. At query time, a retrieval tool searches for relevant passages and applies the appropriate filters before returning context to the agent. Amazon S3 Vectors provides vector buckets and indexes for this storage and search layer.
Effective retrieval depends on more than finding similar text. Documents need an owner, a review process, and a way to remove or supersede outdated guidance. Returned passages should carry enough source information for the application to show where an answer came from. Access filters should be applied by the retrieval service using trusted user context, rather than accepted as unverified parameters supplied by the agent.
Together, these sources provide complementary capabilities: Iceberg tables provide governed business facts, and the vector index helps find relevant written guidance. The agent can combine both in one response, such as reporting the current shipment status and explaining the policy that applies to that delay.
Vector infrastructure costs include storage, ingestion, and queries. A knowledge base with millions of document passages may contain a large number of vectors, even if users search it only occasionally. In that situation, keeping an always-on search deployment sized for peak traffic can be expensive.
AWS positions S3 Vectors as a cost-focused option for large-scale vector storage and search, and advertises up to 90% lower costs for uploading, storing, and querying vectors in applicable comparisons. That figure is a potential saving, not a forecast for every workload. Actual cost depends on vector dimensions, metadata size, ingestion volume, query frequency, and the surrounding retrieval architecture.
S3 Vectors is especially worth evaluating when the knowledge base is large and query traffic is moderate or uneven. Applications with demanding latency targets, very high query rates, or more complex search requirements may be better served by a dedicated search engine such as Amazon OpenSearch Service. A deployment decision should compare representative queries for relevance, latency, throughput, and total cost before choosing the retrieval layer.
An agent works with tools: named operations it can discover and call while completing a task. AgentCore Gateway provides a central entry point for exposing those operations, including Model Context Protocol (MCP) tools. Rather than giving the agent direct credentials for every data service, the application can publish a small set of approved capabilities.
For a customer support agent, those capabilities might include get_order_status, get_delivery_events, search_return_policy, and create_case_summary. Each tool has a defined purpose and input contract. Its implementation handles the service calls, checks the caller’s permissions, and shapes the result for the agent.
This design also makes the agent easier to operate. Teams can monitor which tools are called, identify costly or unsuccessful requests, and update one tool without changing every prompt. Most importantly, the agent’s available actions become explicit. When it needs information, it asks through an approved operation whose behavior can be tested and audited.
Gateway interceptors add checks around tool traffic. A request interceptor runs before the gateway calls a target. It can inspect the requested operation and apply custom authorization logic, such as checking the user’s role, tenant, or permitted tool set. A response interceptor can inspect or transform eligible results before they reach the agent.
For example, a request to get_order_status could be rejected if the caller lacks the support role. The tool itself would then verify that the order belongs to a customer the caller is authorized to assist. On the return path, response handling could remove fields the agent does not need and record the authorization decision for audit.
These checks should use trusted identity information and deny access when that information is missing. They also need to account for how the gateway passes identity and request headers to an interceptor; header forwarding is configurable and requires care because headers can contain credentials. Interceptors are one layer of enforcement, with tool permissions and data-service permissions providing further controls.
Allowing an agent to generate SQL creates useful flexibility, but it also increases the work required to control execution.
A question that sounds simple can produce an expensive full-table scan. A query may refer to a field the user should not see, join data across domains incorrectly, or return far more records than the answer requires.
A governed query tool should first establish the caller’s identity and allowed data scope. It can expose only approved catalogs, databases, tables, and columns; accept read-only operations; validate SQL with a parser (using software that understands SQL syntax to inspect an agent’s query before running it); and reject queries that exceed defined limits.
The execution role should have only the permissions the tool needs. Lake Formation permissions can then enforce data access with more granularity than table-wide permissions, while an Athena workgroup can provide operational controls over query execution and spending.while an Athena workgroup can provide operational controls over query execution and spending.
The same principle applies to retrieved documents. A section of a document containing instructions such as “ignore previously defined rules” is still source content, not a new authority over the agent. The application should treat retrieved text as data, keep tool permissions outside the prompt, and evaluate outputs for sensitive information or other policy violations where appropriate. Logs should connect the user request, tool calls, authorization decisions, query identifiers, and returned sources so operators can investigate an answer later.
These controls support useful autonomy. An agent can choose the next approved step in a workflow, while the underlying services determine which actions and data are permitted.
Moving from a prototype to a production agent requires decisions across data engineering, cloud architecture, security, and operations. CloudZone can help customers turn the use case into a deployable design: identify which questions the agent should answer, map those questions to authoritative data sources, and define the permissions each user group needs.
For the data layer, that work may include designing Iceberg tables in S3 Tables, establishing the data catalog and Lake Formation permissions, preparing document ingestion for S3 Vectors, and defining how records and documents are refreshed. For the agent layer, it may include designing tool contracts, configuring AgentCore Gateway, implementing interceptors, and building query and retrieval services that enforce access at execution time.
Deployment also needs evidence that the system works under real conditions. CloudZone can help customers test representative questions, check whether answers use the correct sources, measure query and retrieval latency, review denied-access cases, and estimate operational costs. Infrastructure as code, environment separation, monitoring, and CI/CD pipelines then make the solution easier to maintain after launch.
CloudZone’s role is to connect these technical decisions to the customer’s needs and working methodology. The best architecture is one that data owners can manage, security teams can review, and application teams can improve as the agent’s responsibilities grow.
Agentic AI becomes more useful when it can work with current business records and relevant organizational knowledge. An agent is ready for production when every route to that information has clear ownership, permissions, and operational limits.
Apache Iceberg gives structured data a dependable table format on S3. S3 Tables reduces the effort of maintaining those tables, while S3 Vectors supports search across documents. Lake Formation, Athena, AgentCore Gateway, and the tool implementations govern how an agent reaches each source. With those layers in place, organizations can give agents room to complete meaningful tasks while keeping data access measurable and controlled.
Apache Iceberg is an open table format for analytical data. It tracks table files through metadata and snapshots, allowing consistent reads as data changes. It also supports schema evolution, partition evolution, and access to earlier table snapshots. On AWS, S3 Tables provides a managed way to store and maintain Iceberg tables.
A standard S3 bucket can hold analytical files, but the team must design and operate more of the table management around them. S3 Tables is built for Iceberg tables and includes managed maintenance features such as compaction and snapshot management. It is useful when applications need a reliable tabular dataset that changes over time. Amazon S3 Tables
No. S3 Tables hold structured records that applications can query as tables. S3 Vectors stores embeddings that support similarity search, commonly used to find relevant passages in documents. An agent may need both: the table for a current business fact and the vector index for the policy or explanation related to it. Amazon S3 Tables Amazon S3 Vectors
No single option is cheapest for every application. S3 Vectors is designed as a cost-effective choice for vector storage and search, particularly when a large index receives moderate or uneven query traffic. Teams should compare it with other search options using their expected index size, query volume, latency requirements, and total operating cost. Amazon S3 Vectors
AgentCore Gateway gives agents a central way to discover and invoke approved tools. Authentication, gateway policies, and interceptors can control access to those tools. The tools and underlying data services must still enforce their own permissions, including which records and fields a caller can read. AgentCore Gateway core concepts Fine-grained access control
An AI agent can answer a customer question only as well as the information it is allowed to use. Consider a service agent asked, “Why has this order not shipped, and what can the customer do next?”
AI coding agents need better context. Selecting, compressing, and retrieving the right information can reduce waste across the entire agent workflow.
Picture a meeting room. Laptops open, screens flickering, everyone with that particular gleam in their eye. The first word in the air isn't "hello," it's "AI." And then comes the moment that always arrives: someone says, with total confidence, "We want ChatGPT. But ours. Now."
.png)
