How Can AI Agents Connect to Data and Execute Business Processes Safely? The Amazon Bedrock AgentCore Architecture

AI agents are opening a new approach to automating business operations: instead of only answering questions or generating content on request, an agent can proactively search for information, analyze data, choose tools and carry out multiple processing steps to complete a task. But for an agent to operate in an enterprise environment, a major challenge arises: how can the agent access the right data, use the right tools, and act within its permitted scope? In a post in the group Machine Learning cơ bản, author David Nguyen presents the Agentic AI architecture introduced by AWS — Amazon Bedrock AgentCore — with components supporting the building, connecting, securing and operating of AI agents, where MCP connectivity, identity management, control over tool usage, and activity monitoring are key factors.

Quick answers

• Connectivity via MCP and AgentCore Gateway: data and business functions sit scattered across databases, CRMs, ERPs, data warehouses and internal applications; Amazon Bedrock AgentCore Gateway is the intermediary layer that connects APIs, AWS Lambda functions and MCP servers into tools an agent can discover and use. MCP (Model Context Protocol) provides the standard protocol for an agent to communicate with external tools and data sources — discovering tools, learning their functions and parameters, sending execution requests and receiving results.
• Context Engineering helps agents understand data and business correctly: Amazon Bedrock Knowledge Bases supports RAG so agents can retrieve information as context for the model; the Semantic Layer provides semantic information about data — schemas, relationships between tables and business metric definitions — so agents identify the right data to mine instead of relying on table names alone.
• Tool calling moves agents from answering questions to performing tasks: in the Data Mesh architecture on AWS, MCP tools such as get_user_tables (tables the user may access), get_schema (table structure), run_query (read-only SQL via Amazon Athena) and kb_search (semantic search on Knowledge Bases) let an agent run a chain of operations: discover data, learn its structure, choose sources, query and use results to answer.
• Security and access control at the system level, not just model self-control: AgentCore Identity manages identity and authentication, forwarding user identity context via the On-Behalf-Of (OBO) token exchange mechanism; AgentCore Policy sets policies controlling which tools an agent may use; Amazon Bedrock Guardrails controls input/output content and detects risks such as prompt injection; Gateway Interceptors inspect, transform or block requests and responses between the agent, the Gateway and backend tools.
• Runtime and Observability for operating like any other technology application: AgentCore Runtime provides the deployment and operating environment for agents, supporting session isolation; AgentCore Observability tracks execution and tool-calling steps, helping businesses evaluate performance and detect problems during operation.

Why is safe connectivity the biggest challenge in bringing AI agents into the enterprise?

AI agents differ from chatbots in that they act: searching for information, analyzing data, choosing tools and carrying out multiple processing steps to complete a task. That very ability to act raises the question the post puts at the center: how can the agent access the right data, use the right tools, and act within its permitted scope?

In an enterprise, data and business functions usually live on many different systems — databases, CRMs, ERPs, data warehouses and internal applications. Each system has its own access method, data definitions and authorization mechanisms. If an agent connects to these systems without a standardizing intermediary layer, without business context and without system-level permission control, the business faces two risks at once: the agent cannot do its job because it does not understand the data, or the agent oversteps because nothing limits it. The architecture AWS introduced through Amazon Bedrock AgentCore, as presented in the post, addresses both sides with five groups of components.

1. Connecting AI agents to enterprise systems through MCP

The first component is the connectivity layer. AWS introduced Amazon Bedrock AgentCore Gateway — the intermediary layer that connects APIs, AWS Lambda functions and MCP servers into tools an agent can discover and use.

A key component in this architecture is the Model Context Protocol (MCP) — the standard protocol for AI agents to communicate with external tools and data sources. Through MCP, an agent can:

• Discover the tools available.
• Receive information about a tool's functions and parameters.
• Send execution requests.
• Receive results to continue processing the task.

The practical benefit the post stresses: instead of building a separate integration mechanism for each tool, businesses can use a unified communication layer to expand an AI agent's connectivity. When a new system arrives, the business adds the connection through the Gateway and MCP instead of rewriting integrations for each agent.

2. Context Engineering: helping AI agents understand data and business correctly

One challenge in deploying AI agents is understanding the meaning of data in the business context. The post gives an example: when a user asks for revenue analysis, the agent must identify the right data source, understand the definition of the revenue metric and the relationships between related tables. Knowing table names and column structures is not enough — "revenue" in one system may be defined differently than in another.

AWS points to two components supporting this process:

• Amazon Bedrock Knowledge Bases — supports the Retrieval-Augmented Generation (RAG) mechanism, letting agents retrieve information from knowledge sources and use search results as context for the model.
• Semantic Layer — provides semantic information about data, including schemas, relationships between tables and business metric definitions.

In the Autonomous Business Insights architecture from AWS cited in the post, an agent can explore the Semantic Layer before choosing an MCP connector to retrieve data from systems such as Amazon Redshift, Amazon Aurora and S3 Tables. As a result, the agent has more information to identify the data to mine instead of relying only on table names or raw data structures. That is the meaning of Context Engineering: preparing context so the model understands correctly, instead of letting the model guess.

3. Tool calling: from answering questions to performing tasks

Tool calling is what lets an AI agent interact with external systems and carry out concrete processing steps — the point that distinguishes an agent from a system that only generates responses from available information.

In the Data Mesh architecture on AWS, the post names four MCP tools supporting agents in discovering and querying data:

Tool	Function
get_user_tables	Lists the data tables the user is permitted to access, via AWS Glue Data Catalog and Lake Formation
get_schema	Retrieves table structure, including column names, data types and descriptions
run_query	Executes read-only SQL queries via Amazon Athena on Iceberg tables, combined with data access control
kb_search	Semantic search on Amazon Bedrock Knowledge Bases with metadata filters

Through these tools, an agent can run a chain of operations: discover data, learn its structure, choose information sources, query and use the results to answer the request. Notably, run_query executes only read-only SQL — a deliberate limit: the agent may read and analyze data but not alter it through this tool. That is how tool design contributes to safety, alongside the control layers in the next section.

4. Security & access control: keeping AI agents within their authority

When an AI agent can access data and execute tools, security becomes inseparable from the architecture. The post lists four mechanisms AWS provides to control agent activity:

• Amazon Bedrock AgentCore Identity — supports identity management, authentication and credentials for agents accessing AWS resources or external services. The On-Behalf-Of (OBO) token exchange mechanism also supports forwarding the user's identity context to backend systems — meaning the backend knows the request is made on behalf of a specific user, rather than seeing only a shared agent identity.
• Amazon Bedrock AgentCore Policy — allows policies controlling which tools an agent may use, based on defined conditions and permissions.
• Amazon Bedrock Guardrails — supports controlling input and output content, detecting risks such as prompt injection, inappropriate content and sensitive information.
• Gateway Interceptors — allow inspecting, transforming or blocking requests and responses during interactions between the agent, the Gateway and backend tools.

The important point in AWS's approach, as the post stresses, is not relying solely on the AI model's ability to control itself. Access rights and execution must be controlled by security mechanisms at the system level. A model can be instructed to "only do this, don't do that", but a language instruction is not access control — real control lies in identity, policy, the gateway and blocking layers in the infrastructure.

5. Agent Runtime & Observability: operating and monitoring AI agents

An AI agent in an enterprise environment needs to be deployed and monitored like other technology applications — it cannot be a "black box" running somewhere that nobody can track.

• Amazon Bedrock AgentCore Runtime provides the environment for deploying and operating agents, supporting session isolation and handling agent interactions.
• AgentCore Observability supports tracking agent activity, including the execution process and tool-calling steps.

These capabilities help businesses track activity, evaluate performance and detect problems arising during operation: which tools the agent called, in what order, with what parameters, and with what results — all need traces for review when incidents occur or improvements are needed.

Combining Runtime, Gateway, Identity, Policy and Observability, businesses can build an environment where AI agents interact with external systems within a managed scope — the post's conclusion, and the answer to its opening question: agent safety comes not from a single component, but from a multi-layer architecture working together.

Frequently asked questions

What role does MCP play in connecting AI agents to enterprise systems?

MCP (Model Context Protocol) is the standard protocol for AI agents to communicate with external tools and data sources. Through MCP, an agent discovers available tools, learns their functions and parameters, sends execution requests and receives results. Combined with Amazon Bedrock AgentCore Gateway — the intermediary layer connecting APIs, AWS Lambda functions and MCP servers into tools — businesses get a unified communication layer instead of building separate integrations for each tool.

How does Context Engineering differ from simply giving an agent database access?

Database access only shows an agent table names and column structures; Context Engineering gives it the meaning of data in the business context. Per the post, Amazon Bedrock Knowledge Bases supports RAG so agents retrieve knowledge as context, while the Semantic Layer provides schemas, relationships between tables and business metric definitions — for example, how "revenue" is defined. As a result, the agent identifies the right data to mine instead of guessing from table names.

What do the four MCP tools in the Data Mesh architecture on AWS do?

get_user_tables lists tables the user is permitted to access (via AWS Glue Data Catalog and Lake Formation); get_schema retrieves table structure including column names, data types and descriptions; run_query executes read-only SQL via Amazon Athena on Iceberg tables with access control; kb_search performs semantic search on Amazon Bedrock Knowledge Bases with metadata filters. Together they let an agent discover, understand structure, choose sources, query and answer.

How can AI agents be kept from exceeding their authority when executing tools?

Per the post, AWS controls at the system level rather than relying only on model self-control: AgentCore Identity manages identity and forwards user context via the OBO token exchange mechanism; AgentCore Policy sets policies on which tools an agent may use; Amazon Bedrock Guardrails controls content and detects prompt injection; Gateway Interceptors inspect, transform or block requests/responses between the agent, the Gateway and backend tools. Tool design also contributes — for example, run_query permits read-only SQL only.

What needs monitoring when operating AI agents in an enterprise?

Per the post, AgentCore Runtime provides the deployment and operating environment with session isolation, while AgentCore Observability tracks the execution process and tool-calling steps. Businesses can thereby track activity, evaluate performance and detect problems — which tools the agent called, in what order, with what results — just as they monitor other technology applications.

Conclusion

David Nguyen's post shows a complete architectural picture for AI agents in the enterprise: Gateway and MCP handle connectivity, Knowledge Bases and the Semantic Layer handle context, tool calling handles execution, Identity/Policy/Guardrails/Interceptors handle permission control, and Runtime and Observability handle operations. The core message is: AI agent safety does not come from instructing the model, but from a multi-layer architecture — each layer with one responsibility, and the layers working together so the agent accesses only the right data, uses only the right tools, within the right scope of authority. That is the condition for AI agents to move from impressive demos to a real part of business operations.

Source: a post by David Nguyen in the Facebook group Machine Learning cơ bản (11 November 2026), presenting the Agentic AI architecture and Amazon Bedrock AgentCore as introduced by AWS. Edited and structured by Wotech Electronics. Illustrations: architecture diagrams attached to the original post.