AI Credit Analytics Across Amazon S3 and Snowflake with Amazon Bedrock AgentCore

A credit analyst at a bank receives a loan application for $50,000. The decision requires checking the institution’s credit policy manual (stored as PDFs in Amazon S3), pulling the applicant’s account history and transaction patterns (stored in Snowflake), and synthesizing both into a recommendation, all within the same conversation. Today, this workflow usually involves toggling between three or four systems, copy-pasting data, and can take 20-40 minutes per application on manual lookups alone.

In this post, we present a deployable reference architecture that addresses both challenges simultaneously. We show how Amazon Bedrock AgentCore orchestrates a single AI agent that reasons across unstructured documents in Amazon S3 and structured data in Snowflake. The architecture includes per-user identity, full audit trails, and PII protection from day one. The pattern uses the Model Context Protocol (MCP) as its extensible tool interface, meaning you can connect any MCP-compatible data source, such as Snowflake today, Amazon Redshift or Amazon Relational Database Service (Amazon RDS) tomorrow, without re-engineering. The reference deployment completes a full credit eligibility assessment in approximately 70 seconds (an unoptimized baseline with clear optimization paths we detail later), completing in seconds what typically takes analysts 20-40 minutes of manual cross-referencing across systems.

The credit decisioning challenge in financial services

Credit decisions are inherently multi-source. Policy documents (underwriting guidelines, regulatory thresholds, product term sheets) live in document stores. Customer data (account balances, transaction histories, credit scores, employment records) lives in data platforms. These two worlds rarely share a common query interface.

If you are building AI-powered analytics for credit decisioning, loan origination, or Know Your Customer (KYC), you face three compounding constraints:

Auditability: Regulators expect every data access to be traceable to a specific human operator. When an AI agent queries customer data, the query must appear in Snowflake’s QUERY_HISTORY (or equivalent) under the real analyst’s identity, not a generic service account. Without this, audit trail traceability is lost.

Access control: Different analysts have different data entitlements. A retail credit analyst should not see commercial loan portfolios. These role-based access control (RBAC) boundaries must be enforced at the data platform layer, not in application code that can be bypassed.

Data sensitivity: Customer personally identifiable information (PII), including Social Security numbers, account numbers, and dates of birth, must never appear in AI-generated responses, even if the underlying data source returns them. Redaction must be automatic and policy-driven.

Existing approaches typically involve building custom API layers, managing OAuth token exchanges manually, and writing per-connector integration code. Each new data source means a new integration project. The result is brittle, expensive to maintain, and difficult to audit.

Solution overview: Amazon Bedrock AgentCore and MCP

Our reference architecture uses Bedrock AgentCore as the orchestration layer for a single AI agent with three tools. Each tool is backed by a different data source, all unified under the MCP standard:

knowledge_base_search: Retrieval-Augmented Generation (RAG) over credit policy PDFs stored in Amazon S3, powered by Amazon Bedrock Knowledge Bases with Amazon OpenSearch Serverless as the vector store.
cortex_search: Semantic search across customer credit profiles in Snowflake, using Snowflake Cortex Search through the Snowflake Managed MCP Server.
cortex_analyst: Natural-language-to-SQL execution against structured banking data (accounts, transactions, balances) in Snowflake, using Snowflake Cortex Analyst through the same MCP Server.

The KB path uses the agent’s IAM execution role rather than per-user credentials because credit policy documents are institutional knowledge, not customer-specific data requiring per-user access control. Customer data, which is sensitive and subject to RBAC, correctly flows through the AgentCore Gateway with per-user Okta tokens. This is a deliberate architectural boundary: governance enforcement (Cedar, per-user identity) applies to the path where it matters most: customer data access.

AgentCore Gateway acts as the MCP-protocol-aware bridge between the agent and the Snowflake Managed MCP Server. It handles outbound authentication, enforces per-tool access policies using Cedar, a purpose-built authorization policy language, and manages the three-legged OAuth (3LO) consent flow, all transparently to the agent code.

Figure 1: Credit Risk Assessment Agent: logical flow from analyst through AgentCore to data sources, with per-user identity through Okta 3LO.

How the agent answers a loan eligibility question

To illustrate the end-to-end flow, consider a common credit workflow: “Is customer C-1042 eligible for a $50,000 personal loan?” The agent orchestrates the following in a single turn:

Step 1: Calls knowledge_base_search to retrieve the bank’s debt-to-income (DTI) ratio limits, minimum credit score thresholds, and product terms for personal loans from policy PDFs in Amazon S3.

Step 2: Calls cortex_search to pull the customer’s credit profile (risk indicators, employment status, credit history) from Snowflake through semantic search.

Step 3: Calls cortex_analyst to query the customer’s current account balances, monthly income, and existing debt obligations from structured tables in Snowflake.

Step 4: Synthesizes all three results: computes the debt-to-income ratio from actual data, compares it against policy thresholds, checks the credit score against minimums, and produces a structured eligibility recommendation with supporting evidence.

The entire multi-tool orchestration (from question to synthesized recommendation) completes in approximately 70 seconds in our reference deployment. Without the agent, the same analysis requires 20-40 minutes of manual cross-referencing across systems. For a bank processing 200 loan applications per day, that translates to significant analyst capacity recovered weekly. Your credit team can redirect this time toward complex edge cases, relationship management, and portfolio-level risk analysis.

Enterprise identity: per-user auditability for regulated environments

A critical architectural decision in this pattern is how identity flows from the human analyst through the AI agent to the data platform. In many AI agent implementations, the agent authenticates to downstream systems using a shared service account. This approach does not meet regulatory expectations in financial services for a straightforward reason: if every query appears as “service-agent-prod” in the audit log, regulators cannot determine which analyst accessed which customer’s data.

Figure 2: Enterprise identity and governance layers: each layer is independently auditable.

Three-legged OAuth with Okta

This architecture implements per-user identity using three-legged OAuth (3LO) with Okta as the enterprise identity provider, the same Okta that most financial institutions already use for corporate single sign-on. Here is how the identity flows:

The analyst authenticates by using Okta Single Sign-On (SSO) (with Multi-Factor Authentication (MFA) enforced by your corporate policy).
Amazon AgentCore Identity stores the analyst’s Okta-issued OAuth tokens in its managed token vault: one token set per user, never shared. Tokens are automatically refreshed using stored refresh tokens when the access token expires.
When the agent calls a Snowflake tool, AgentCore Gateway retrieves that specific analyst’s token and forwards it to Snowflake.
Snowflake validates the Okta JSON Web Token (JWT) against Okta’s JSON Web Key Set (JWKS) endpoint, maps the token claims to the analyst’s Snowflake LOGIN_NAME, and executes the query under the analyst’s role (for example, ANALYST_ROLE).

The result: every query in Snowflake’s QUERY_HISTORY is attributed to the real human analyst: their name, their role, their entitlements. If Analyst A can see retail accounts but not commercial portfolios, Snowflake’s native RBAC enforces that boundary even when the AI agent issues the SQL. No application-level access control code is required.

For your compliance team, this means the audit trail is indistinguishable from a human directly querying Snowflake, because at the data platform layer, it is the human. The AI agent is a tool in the analyst’s hands, not an independent actor with its own credentials.

Note on token lifecycle and failure modes: When an Okta access token expires during a session, AgentCore Identity automatically uses the stored refresh token to obtain a fresh token. No user interaction is required. If the refresh token itself has expired, the agent receives an authorization request (a new consent URL) rather than a hard error. In the more disruptive case, where a token has been administratively revoked at Okta, AgentCore cannot detect this server-side, and the downstream MCP tool call will receive an authentication error. Applications must handle this by calling with forceAuthentication: true to initiate a clean re-authentication flow. No conversation context is lost in any of these scenarios.

Cedar policies for per-tool authorization

AgentCore Gateway uses Cedar to control which tools each user can invoke. The Gateway enforces a default-deny model: every tool call is blocked unless an explicit permit policy grants access. The Cedar schema is auto-generated from your Gateway’s tool definitions, and you author authorization rules declaratively against that schema.

For example, a policy granting analysts access to the cortex_analyst tool:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"SnowflakeMCP___cortex_analyst",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:<region>:<account-id>:gateway/<gateway-id>"
)
when {
  principal.hasTag("role") && principal.getTag("role") == "ANALYST"
};

Note: The exact action names and principal tags are auto-generated from your Gateway configuration. Refer to your deployed Gateway’s Cedar schema for the precise syntax.

The user’s identity (from their OAuth token claims) determines what they can access. Tool identity is encoded in the action, and the resource is the Gateway itself.

This means your authorization decisions are auditable, deterministic, and separate from application code. Adding a new tool or granting access to a new role is a policy change, not a code deployment.

PII protection with Amazon Bedrock Guardrails

Even when the agent retrieves legitimate customer data, sensitive fields must not surface in the AI-generated response. We configured Amazon Bedrock Guardrails with PII entity detection, setting the anonymization action for US Social Security numbers and credit/debit card numbers on both input and output. If an analyst accidentally includes a sensitive identifier in a prompt, or if the agent’s response would otherwise contain a card number, the guardrail intercepts and redacts it before the response reaches the user. This is a configured policy, not automatic inference. It gives your security team explicit control over which entity types are protected and what action (block or anonymize) applies to each.

Extensibility: MCP as the universal data connector

A common concern with agent architectures is lock-in: if you build around one data platform, adding a second requires significant re-engineering. MCP eliminates this problem by providing a standard protocol for tool invocation that is data-source agnostic.

In this reference architecture, Snowflake is one MCP target behind AgentCore Gateway. Adding Amazon Redshift as a second data source requires only four steps:

Deploy a Redshift MCP Server (a lightweight wrapper that exposes Redshift queries as MCP tools).
Register it as a new target on the same AgentCore Gateway instance.
Add a Cedar policy granting the appropriate users access to the new tools.
Add the new tool definition to the agent’s tool list.

No changes to the agent’s reasoning logic, no new OAuth flows, no infrastructure re-architecture. The same pattern applies for Amazon RDS, Amazon DynamoDB, or any third-party system that exposes an MCP interface. In our testing, adding a new MCP target took under 30 minutes from start to a working tool call.

For a bank that today queries Snowflake for credit analytics but tomorrow wants to add Amazon Redshift for market risk data and an internal REST API for fraud signals, the expansion is configuration, not a new project. This is the extensibility promise of MCP realized in practice: your architecture scales with the business, not against it.

Performance and operational results

We measured the reference implementation across five representative credit analytics scenarios. The following table shows average latency from three consecutive test runs:

Scenario	Tools Invoked	Avg. Latency	Manual Equivalent	Improvement
Credit policy lookup (DTI limits)	KB only	~7s	3-5 min	~26-43x
Account summary	Cortex Analyst + SQL exec	~19s	5-8 min	~16-25x
Customer profile search	Cortex Search	~15s	4-6 min	~16-24x
Full loan eligibility assessment	KB + Search + Analyst	~71s	20-40 min	~17-34x
PII redaction test	Guardrail intercept	~10s	N/A	N/A

Table 1: Measured performance (average of three runs) from the reference deployment.

Deployment conditions and tuning opportunities

The measurements above were taken under the following reference deployment conditions:

Snowflake SMALL warehouse with 300-second auto-suspend (cold-start latency applies after idle periods)
Public internet endpoints throughout (Amazon CloudFront, Application Load Balancer, Amazon ECS Fargate, AgentCore Gateway, Snowflake MCP Server)
Single ECS Fargate task (1 vCPU, 3 GB memory) in default Amazon Virtual Private Cloud (Amazon VPC), us-east-1
Sequential multi-tool orchestration by the LLM (the agent calls tools one at a time rather than in parallel)

Production deployments can reduce these latencies through several optimizations:

Larger Snowflake warehouse: A Medium or Large warehouse eliminates cold-start delays and reduces query execution time.
VPC endpoints and AWS PrivateLink: Replacing public internet hops with VPC endpoints to AgentCore and PrivateLink connectivity to Snowflake reduces network round-trip time.
Parallel tool invocation: Tuning the agent’s system prompt to invoke independent tools in parallel (rather than sequentially) can reduce the full eligibility assessment latency (the most complex scenario, invoking all three tools) by 2-3x, as KB lookup and Snowflake queries have no dependencies on each other.
Warm warehouse scheduling: Configuring longer auto-suspend intervals or using Snowflake’s warehouse scheduling eliminates cold-start overhead during business hours.

The key metric for FSI decision-makers is not raw latency but the operational improvement ratio: even at ~71 seconds for the most complex scenario, the architecture delivers a 17-34x improvement over manual cross-system analysis. Single-source queries achieve a 16-43x improvement. For a credit team processing 200 applications daily, this translates to substantial analyst capacity freed for judgment-intensive work.

Evaluating agent quality for production readiness

Enterprise FSI deployments require documented evidence of agent quality before production release. AgentCore Evaluations provides managed evaluation across the full agent interaction flow. It measures four key dimensions: Both on-demand evaluation (for CI/CD quality gates) and online evaluation (continuous sampling of live traffic) are supported. For a credit risk agent where wrong decisions carry regulatory consequences, we recommend starting with these four metrics as your pre-production validation suite.

Tool Selection Accuracy: Did the agent route to the correct tool?
Tool Parameter Accuracy: Were the right customer IDs and financial parameters passed?
Correctness and Faithfulness: Is the credit determination factually grounded in retrieved data?
Goal Success Rate: Did the agent deliver a complete eligibility recommendation?

Lessons learned

Building and testing this architecture with financial services requirements surfaced two insights that are broadly applicable to FSI institutions deploying AI agents:

Corporate SSO-to-data-platform identity mapping requires upfront validation

The mapping between your identity provider’s token claims and the data platform’s user identifier must be validated before any queries succeed. Even a small mismatch, such as a case-sensitivity difference, results in silent authentication failures. We recommend you run a pre-deployment validation script that confirms the mapping for each user in your target population.

Adding new data sources is configuration, not engineering

Once the AgentCore Gateway + MCP pattern is established, adding a new data source follows a repeatable checklist: deploy the MCP server, register the target, write the Cedar policy, add the tool. In our testing, this took under 30 minutes from start to a working tool call.

Prerequisites and estimated cost

To deploy the reference implementation, you need: an AWS account with Bedrock model access enabled (Claude Sonnet), a Snowflake account with Cortex Search and Cortex Analyst enabled, an Okta tenant with a Custom Authorization Server and an OpenID Connect (OIDC) Web App configured, and the AWS CDK CLI. The full deployment takes approximately 15-20 minutes. Estimated running cost for the reference deployment is approximately $15-25/day, driven primarily by OpenSearch Serverless (2 OpenSearch Compute Units (OCUs) minimum), ECS Fargate (1 task), and Amazon Bedrock model invocations. Snowflake costs (warehouse compute) are billed separately per your Snowflake contract. We recommend deploying in a sandbox account for evaluation.

Conclusion and next steps

In this post, we demonstrated how AgentCore, combined with MCP and enterprise identity through Okta 3LO, provides a deployable pattern for AI-powered credit analytics in financial services. The architecture addresses the core tension in FSI AI adoption: the need for intelligent automation alongside the regulatory requirement for per-user auditability and access control.

The complete reference implementation is available on GitHub. It includes one-click deployment by using AWS CDK, synthetic banking data, policy documents, and the agent code.

We encourage you to deploy this reference architecture in a sandbox environment, test it with your own policy documents and data schemas, and evaluate how the pattern maps to your credit decisioning, KYC, fraud detection, or portfolio analysis workflows. To get started, clone the repository and run ./deploy.sh. The entire environment deploys in approximately 15-20 minutes.

AWS for Industries