Building Evidence-Driven AI Agents with Amazon Bedrock and MCP: An Enterprise Architecture Guide

Learn how Amazon Bedrock and the Model Context Protocol (MCP) can work together to build secure, auditable AI agents. Explore reference architecture, security controls, and a practical SOC investigation use case.

Santhosh K Ramurthy

System Integrator

Published Oct 16, 2026

Last modified Oct 16, 2026

Enterprise AI is moving beyond conversational interfaces toward agents that can retrieve information, invoke tools, analyze data, and support multi-step workflows.

However, connecting a large language model to enterprise systems introduces important engineering challenges. How do we control what an agent can access? How do we validate its findings? How can organizations distinguish verified evidence from model-generated interpretations?

Amazon Bedrock and the Model Context Protocol (MCP) provide complementary capabilities for addressing these challenges.

Amazon Bedrock provides managed access to foundation models and related generative AI capabilities. MCP defines a standardized protocol through which AI applications can discover and interact with tools and contextual resources.

Together, they can form part of an enterprise agent architecture in which model reasoning is separated from data access, business logic, and authorization.

The objective is not simply to make an AI agent more capable. It is to make its operations controlled, observable, and accountable.

1. Understanding the architecture

A practical enterprise implementation can be organized into six layers.

Layer 1: User and application interface

The user interacts with an application through a web interface, internal portal, analytics dashboard, or security operations platform.

The application establishes the user's identity, captures the request, and determines the permitted scope of the operation.

Layer 2: Agent orchestration

The orchestration layer manages the workflow.

Responsibilities include:

Interpreting the request and identifying the required steps.
Maintaining workflow state.
Selecting approved tools.
Enforcing application-level policies.
Handling errors, retries, and timeouts.
Returning results in a structured format.

The orchestration layer should remain responsible for enforcing critical business rules rather than relying exclusively on the model's instructions.

Layer 3: Foundation model

Amazon Bedrock provides access to supported foundation models for tasks such as language understanding, summarization, structured output generation, and tool selection.

The model can help determine which information is needed and how to interpret retrieved results. However, model-generated conclusions should not be treated as authoritative merely because they are confidently expressed.

Layer 4: MCP integration

MCP provides a standardized interface for exposing approved tools and contextual resources to compatible AI applications.

For example, an organization might expose tools for:

Retrieving authorized SIEM events.
Looking up incident records.
Querying approved analytics datasets.
Searching internal documentation.
Retrieving change-management history.

Each tool should have a clearly defined purpose, input schema, output format, and permission boundary.

MCP standardizes interaction; it does not independently guarantee authentication, authorization, data integrity, or safe execution.

Layer 5: Enterprise data and services

The agent may interact with databases, object storage, knowledge repositories, identity platforms, monitoring systems, and enterprise APIs.

AWS services can support different responsibilities:

Amazon S3: Document and dataset storage.
AWS Lambda: Serverless integration and business logic.
Amazon Aurora and DynamoDB: Relational and NoSQL application data.
Amazon Bedrock Knowledge Bases: Retrieval-augmented generation over configured knowledge sources.
AWS IAM: Identity and permissions for supported AWS operations.
AWS CloudTrail: Recording supported AWS API activity.

These services are architectural options, not mandatory components of every implementation.

Layer 6: Observability and governance

The final layer makes agent behavior inspectable.

Organizations should capture appropriate records of tool invocations, access decisions, data sources, errors, model versions, and workflow outcomes.

Sensitive information should be minimized or redacted where appropriate. Audit logs themselves must be access-controlled and protected against unauthorized modification.

The goal is to reconstruct what the agent did, which information it used, and why a particular operation was permitted.

2. Reference workflow

Consider an employee asking an AI agent to investigate a suspicious authentication event.

A controlled workflow could follow this sequence:

Authenticate: Establish the user's identity and permissions.
Scope: Identify the alert and the authorized investigation boundary.
Retrieve: Query approved security tools through defined integrations.
Validate: Check event timestamps, identifiers, source systems, and data completeness.
Correlate: Compare authentication events with relevant endpoint, identity, and network records.
Analyze: Use the model to organize observations and identify possible explanations.
Report: Produce a timeline with source references, limitations, and recommended next steps.
Review: Require human approval for consequential actions.

The workflow separates data retrieval and validation from model-assisted interpretation.

This distinction is essential. An agent can summarize evidence, but it should not invent missing events, silently change source records, or convert an unverified hypothesis into a confirmed incident.

3. SOC investigation: From alert to evidence

Imagine a SIEM reports ten failed login attempts followed by one successful authentication.

The initial alert is a signal, not a complete incident determination.

An investigation agent could retrieve the associated authentication records, examine timestamps, compare source IP addresses, check account context, and search for relevant endpoint activity.

The resulting report might contain the following sections.

Observed facts

Ten failed authentication events were recorded.
A successful authentication event followed.
The events fall within the queried time window.

Questions requiring investigation

Did the successful authentication originate from an expected device or network?
Was multifactor authentication completed?
Were there subsequent privilege changes or unusual processes?
Are relevant logs missing or incomplete?

Conclusion

The event sequence warrants investigation, but the available facts alone do not establish account compromise.

Recommended next steps

Retrieve additional identity and endpoint evidence, document the timeline, and escalate according to the organization's incident response procedures.

This approach supports a fundamental SOC principle:

Evidence first. Assumptions last.

4. Security controls for MCP-connected agents

An enterprise agent must be designed around least privilege and explicit trust boundaries.

Identity and authorization

Use authenticated connections and enforce authorization on the server side. Verify the user's permissions for each operation rather than assuming that access to the AI application grants access to every connected system.

Least privilege

Expose only the tools and data required for a specific task. Separate read-only operations from operations that change data or system state.

Input and output validation

Validate tool arguments against defined schemas. Check returned data for expected structure and handle malformed or unexpected responses safely.

Prompt injection defenses

Treat retrieved documents, logs, web pages, and tool outputs as potentially untrusted input. Instructions embedded in retrieved content must not override system policies, access controls, or approved workflows.

Human approval

Require appropriate approval before destructive, disruptive, or sensitive actions, such as disabling accounts, quarantining endpoints, changing permissions, or sending external communications.

Auditability

Maintain records of relevant requests, tool calls, authorization decisions, source references, approvals, and outcomes. Make it possible to investigate failed and unauthorized operations as well as successful ones.

Failure handling

Define what happens when a tool is unavailable, data is incomplete, authorization fails, or the model produces invalid output. The agent should report uncertainty rather than silently filling gaps with assumptions.

Security is not a feature that MCP or a foundation model automatically supplies. It is a property of the complete system and its operating procedures.

5. Extending the architecture with Amazon Bedrock AgentCore

For organizations building production agents, Amazon Bedrock AgentCore is another AWS capability worth evaluating.

Depending on the selected components and current service support, AgentCore can provide building blocks for agent runtime, tool connectivity, identity, memory, and observability.

The appropriate design depends on the deployment requirements. Some teams may use a managed agent runtime and gateway, while others may prefer their own orchestration layer and integration services.

Before selecting a design, evaluate:

Supported model and framework integrations.
Authentication and authorization requirements.
Network isolation and private connectivity needs.
Logging and monitoring requirements.
Data residency and retention obligations.
Latency, throughput, and operating costs.
Recovery, testing, and incident response procedures.

Avoid introducing additional components until there is a clear operational or security reason for them.

6. Applying the pattern to analytics platforms

The same architecture can support business intelligence and data science workflows.

For example, an analytics agent could query campaign performance metrics, explain a calculation, compare two reporting periods, and generate a source-linked summary.

A reliable implementation should distinguish deterministic calculations from model-generated explanations.

If an open rate is calculated as unique opens divided by delivered messages, the calculation should be executed by validated application code using an explicitly defined denominator. The model can explain the result, but should not invent a value when source data is unavailable.

For a platform such as Santoram, an initial implementation could expose read-only tools for:

Campaign performance summaries.
Dataset metadata and data-quality checks.
Saved analysis retrieval.
Approved knowledge search.
Report generation using validated metrics.

Tenant isolation and role-based access controls must apply to every underlying data request. A model prompt is not an acceptable substitute for database-level or server-side authorization.

7. A practical implementation roadmap

Phase 1: Define a narrow use case

Choose one task with a measurable outcome, such as explaining campaign metrics or producing a security event timeline.

Define the permitted data, expected output, success criteria, and prohibited actions.

Phase 2: Build a read-only integration

Implement a small set of authenticated tools with explicit schemas. Return structured results and source identifiers.

Avoid broad database access and unrestricted tool execution.

Phase 3: Add validation and governance

Implement authorization checks, input validation, audit logging, error handling, and protection against cross-tenant data access.

Test prompt injection, malformed responses, missing records, and unauthorized requests.

Phase 4: Evaluate accuracy and usefulness

Create representative test cases and compare agent outputs with verified reference results.

Measure factual accuracy, source attribution, unsupported claims, task completion, latency, and cost.

Phase 5: Introduce controlled actions

Only after read-only workflows are reliable should the organization consider write operations. Use narrowly scoped permissions, explicit approvals, idempotency where appropriate, and rollback procedures.

This phased approach reduces risk while producing evidence that the architecture is useful.

Conclusion

Amazon Bedrock and MCP can contribute complementary capabilities to enterprise AI agent systems: foundation model access and a standardized way to connect AI applications with tools and contextual resources.

The engineering challenge is to connect these capabilities without allowing model reasoning to bypass enterprise controls.

A robust architecture combines controlled orchestration, least-privilege access, validated tools, deterministic processing where appropriate, auditable execution, and human oversight for consequential decisions.

For security operations, analytics, and enterprise automation, the objective should not be unrestricted autonomy.

It should be useful intelligence within explicit boundaries, with every important conclusion grounded in evidence and every consequential action governed by policy.

Builder Center