What AWS published
On 6 November three Amazon data engineers described a Model Context Protocol (MCP) server on Amazon ECS with AWS Fargate that gives AI agents access to an enterprise data lake (vendor, AWS). Users sign in through Amazon Cognito at a client layer. The client layer calls the MCP server through an internal load balancer in private subnets. The server exposes three kinds of tool: SQL query tools for Athena and Redshift, search over table metadata and documentation, and search over operational policies (vendor, AWS).
The interesting part is onboarding. Each table gets one JSON metadata file: database, table, a business description, and column descriptions with sample values. A pipeline embeds the files and indexes them into Bedrock Knowledge Bases, and AWS says a new table becomes discoverable on the next sync without a server restart (vendor, AWS). Reported end-to-end latency in testing is 15 to 20 seconds (vendor, AWS).
What it gets right
- The catalogue is the product. Agents find tables through written business descriptions, not through whoever remembers the schema. That is the work most teams skip.
- Read-only by construction. AWS says the Athena tools accept SELECT only and reject writes before they reach the lake (vendor, AWS).
- Not on the internet. The MCP server sits in private subnets behind an internal load balancer (vendor, AWS).
- Every call logged. Tool invocations go to CloudWatch as structured JSON (vendor, AWS).
The gap: authentication is not authorisation
Cognito answers who the user is. Nothing in the post answers what that user may read. It does not describe passing the user's identity to Athena or Redshift, Lake Formation permissions, row or column filters, result-size limits, or query cost limits. Column-level restriction per permission group is listed as a next step (vendor, AWS).
So, as published, every query runs with whatever data credentials the MCP server holds, and every signed-in user inherits them through the agent. For a team where everyone already shares the same access, that is acceptable. For a lake that holds salaries, customer records, or regulated data, it is the whole risk.
Hosting the server is AWS's pattern. Deciding who sees which column is yours.
Decision: whose permissions does a query run with?
| Option | How it works | Fits when | Cost |
|---|---|---|---|
| One server identity, curated tables | The server reads with one role; only tables every user may see are onboarded | Internal analytics on shared, non-sensitive data | Lowest; sensitive tables stay out of the catalogue entirely |
| One identity per permission group | The server picks a data role by the user's group before it runs SQL | A few well-defined audiences, such as finance, operations, and sales | Role sprawl; group mapping must stay in step with your identity provider |
| The user's own identity at the engine | The user's identity reaches the query engine, so the engine's existing grants apply | Regulated data, or row and column rules already defined in the lake | Most integration work; check your engines and identity provider support it before you design for it |
Whichever row you pick, filter the catalogue as well as the data. An agent that can see a table's description and sample values has already read some of it.
Six steps before production
Prerequisites: a list of the tables you intend to onboard, who owns each, and its data classification.
- Step 1. Classify every table before it gets a metadata file. Owner: data governance lead.
- Step 2. Choose the row in the matrix above, in writing. Owner: data platform lead with the CISO.
- Step 3. Strip sample values from sensitive columns. The metadata files carry sample values by design (vendor, AWS), and they are indexed for search. Owner: data engineering.
- Step 4. Cap what one question can cost. Set result-row and scanned-data limits on the query engine, since the post states none. Owner: data platform.
- Step 5. Authenticate agents to the MCP server, not only users to the client. The post says a new agent needs only the server endpoint (vendor, AWS). Decide what proves an agent may call it. Owner: platform security.
- Step 6. Log the user with the query. A CloudWatch record of a tool call is not an audit trail unless it names the person who asked. Owner: security engineering.
Trade-offs
- Ship it as published. Fastest. Right only for data every signed-in user may already read.
- Add group roles. More roles to maintain, and good enough for most internal audiences.
- Carry the user's identity to the engine. The strongest answer and the slowest. Worth it where row and column rules already exist and must not be rebuilt inside the agent.
Missing
- A sample repository or tool schemas. AWS publishes prose and a diagram, so we read the design, not the code.
- How agents authenticate to the MCP server, and what credentials the server uses for data.
- Cost figures for Fargate, Athena, Bedrock, and the knowledge bases.
- Whether this runs in production at Amazon. The authors are Amazon engineers; the post does not say.
- A test by Prestanda. We have not deployed this pattern.
Frequently asked questions
Is the AWS pattern insecure?
No. It signs users in, keeps the server off the internet, allows SELECT only, and logs every call. It does not describe per-user data permissions, so you have to add them for sensitive data.
Do we need column-level control on day one?
Only if a table holds columns some users must not see. If it does, keep that table out of the catalogue until the control exists.
Is MCP the right interface for a data lake?
It is a reasonable one when several agents need the same governed access. The interface is not the risk; the credentials behind it are.
Living page. Last updated 8 Nov 2026. We update this note if AWS publishes sample code or adds per-user permissions to the pattern.