--- title: "Bedrock Managed Knowledge Bases as a Native Gateway Tool" description: "AgentCore Gateway now ships a native bedrock-knowledge-bases connector that replaces the Lambda wrapper entirely. Attach the KB to the Gateway and it auto-exposes Retrieve and AgenticRetrieveStream over MCP. The constraint: it only works with Managed Knowledge Bases, not customer-managed ones." canonical_url: "https://artificialcuriositylabs.ai/posts/managed-kb-gateway-connector/" md_url: "https://artificialcuriositylabs.ai/posts/managed-kb-gateway-connector.md" published_at: "2026-07-15T07:00:00.000Z" tags: - "agents" - "agentcore" - "bedrock" - "gateway" --- ## The Lambda you no longer have to write Earlier in this series, giving an agent access to a knowledge base meant writing a Lambda that wraps `bedrock:Retrieve`, registering that Lambda as an AgentCore Gateway target, and letting the agent call it as an MCP tool. It worked. The Lambda was pure glue — it existed only to translate an MCP tool call into a Bedrock retrieval API call and translate the response back. You owned its code, its IAM role, its deployment, its cold starts, and its bugs, for a function that did nothing but forward a query. AgentCore now has a [native `bedrock-knowledge-bases` connector](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-managed-kb.html). You attach a Bedrock Knowledge Base directly to a Gateway as a managed-connector target, and the Gateway exposes the retrieval tools over MCP with no Lambda in the path. I replaced the wrapper with the connector, probed it over MCP, and found the one constraint that decides whether you can use it at all. ## What the connector exposes I attached a Knowledge Base to an existing Gateway as a `bedrock-knowledge-bases` connector target, then ran a SigV4-signed MCP `tools/list` against the Gateway. Two tools came back, auto-discovered, with no schema I had to write: - **`Retrieve`** — "Search the managed knowledge base for relevant source passages." A single hybrid search returning the most relevant passages (1–100, defaulting to 10). This is the direct analogue of what my old Lambda wrapped. - **`AgenticRetrieveStream`** — the interesting one. Per [AWS's docs it "plans a retrieval strategy, runs multiple retrieval steps across your managed knowledge bases, optionally expands to full documents, and streams back both the supporting results and a synthesized, citation-backed answer."](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-gateway-target.html) It takes a conversation (query + history), not just a string, and does multi-step retrieval with planning rather than a single lookup. That second tool is a real capability jump. The Lambda wrapper only ever did single-shot retrieval, because writing a planning-and-multi-step-retrieval loop into a glue Lambda would have been a project. Here it arrives as a discovered tool the agent can call. The Gateway handles schema management, endpoint resolution, and service authentication itself — the docs are explicit that [the knowledge base tools are auto-discovered through `tools/list` and available to the agent without additional configuration.](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-managed-kb.html) My probe confirmed it: both tools present, correct input schemas, no wrapper code anywhere. ## The finding: the Lambda actually goes away The point wasn't "a KB tool works" — the wrapper already proved that. It was whether the managed connector genuinely *removes* the custom infrastructure or just hides it. Comparing the two targets on the same Gateway directly: | | Old path | New path | |---|---|---| | Target kind | `lambda` | `managed_connector` | | Backend | a Lambda function | `connectorId: bedrock-knowledge-bases` | | Custom code | a retrieval Lambda you own | none | | Tools | one (whatever you coded) | `Retrieve` + `AgenticRetrieveStream` | The old target pointed at a Lambda ARN. The new target points at a connector ID. Lambda removed from new path: verified true. That is the whole value proposition: the retrieval integration moves from *code you operate* to *configuration the platform operates*, and you gain the agentic tool you wouldn't have built yourself. Same Gateway, same MCP surface, same auth model — one fewer thing to own. ## The caveat that decides everything: Managed only Here is the constraint that isn't obvious until it stops you. The connector is supported **only for Amazon Bedrock [Managed Knowledge Bases](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html)** — not customer-managed ones. Bedrock has two kinds of KB. A **customer-managed** KB is the classic one: you set up and operate the vector store (OpenSearch Serverless, Aurora, Neptune) and control ingestion, parsing, and indexing. A **managed** KB hands all of that to Bedrock — no vector store to provision, no retrieval infrastructure to run. The connector only talks to the managed kind. So before I could attach anything, I had to **create a managed KB** and ingest the corpus into it — I couldn't point the connector at a pre-existing customer-managed KB. That's a real migration cost the feature grid doesn't foreground: "native Gateway integration" quietly assumes you're already on (or willing to move to) managed KBs. If your organization standardized on customer-managed KBs for control over the vector store, adopting this connector isn't a config change — it's a re-platforming of the knowledge base itself. That's the honest trade. You delete a Lambda, but the price of entry is a Managed KB. ## Governance stays where you'd want it The reason this fits the "governed hub" pattern rather than being a pure convenience feature: the governance surface doesn't degrade when the Lambda disappears. - **Least-privilege IAM survives.** The Gateway service role needs only `bedrock:Retrieve` (and the agentic action) on the specific KB ARN — the same narrow grant the Lambda's role needed. The `knowledgeBaseId` is bound in the target's parameter values, **not exposed to the model**, so the agent can't redirect the query at a different KB by talking its way there. - **Observability survives.** I enabled Gateway vended-log delivery for the connector and captured lifecycle events for managed-KB calls in CloudWatch, plus Gateway metrics — the same audit trail the rest of the Gateway tools get. A retrieval tool with no audit trail is a liability; this one keeps the trail. - **The MCP auth boundary is unchanged.** Callers still reach the tool through the Gateway's existing auth (SigV4, `aws_service="bedrock-agentcore"`), so whatever inbound authorization and Cedar policy you've layered on the Gateway still applies. The connector didn't punch a hole around your controls; it slotted into them. That's the right shape: less infrastructure to own, no loss of the controls that make a retrieval tool safe to expose to an agent. ## So what The `bedrock-knowledge-bases` connector is a clean win with a clear boundary. If you're on Managed Knowledge Bases, it deletes the retrieval Lambda outright, hands you an agentic multi-step retrieval tool you wouldn't have built, and keeps IAM, observability, and MCP auth exactly where they were. If you're on customer-managed KBs, the connector isn't for you yet — adopting it means migrating the knowledge base, not just re-pointing a target. The broader pattern is the one this series keeps hitting: AgentCore is steadily replacing *glue you operate* with *connectors the platform operates* — first for APIs (the Gateway itself), then web search, now retrieval. Each one removes a Lambda and keeps the governance. The catch is always in the fine print of what the managed version requires — here, that your KB is the managed kind. What I haven't tested yet is per-user access control at the document level within the KB. The managed connector works with IAM scoping (the Gateway role can only retrieve from this KB), but per-user authorization inside the KB — whether Cedar at the Gateway is enough, or whether you need managed KB document-level controls — remains an open question.