Generated SDKs, CLIs, MCP servers, and API connectors make agents more capable. They also multiply the paths where an allowed workflow can become an unsafe action — because connectivity makes the agent capable, but runtime trust decides whether the next action path is safe to take.

Contents

Generated MCP server security is the work of validating the MCP servers, generated SDKs, command-line tools, API connectors, schemas, callbacks, package endpoints, credentials, and outbound actions that let AI agents reach external systems. The distinction that matters: connectivity makes the agent capable; runtime trust decides whether the next action path is safe enough to take. A generated connector can be correctly installed, correctly scoped, and still unsafe for the current action. Sunglasses ships detection patterns for exactly this layer: GLS-MCP-006 (tool metadata prompt injection — malicious tool metadata trying to become higher-priority control text for the agent), GLS-MCP-013 (tool manifest capability claim injection — false capability or safety claims in tool manifests, handoff packets, or status payloads that get trusted as control-plane truth), and GLS-TOP-237 (tool output poisoning — trusted output override — attacker-controlled content from a tool, API, or retrieval source claiming authoritative status to override the agent's prior instructions). These cover the three places where a generated connector can pass setup review and still fail at action time.

Quick answer: connectivity is not trust

The important distinction is simple. Connectivity makes the agent capable; runtime trust decides whether the next action path is safe enough to take. The risk is not only whether the agent has permission to call a tool. It is whether this specific tool output, handoff, callback, package endpoint, or destination should be trusted right now, after the live context has changed.

A generated connector can be correctly installed, correctly scoped, and still unsafe for the current action. Strong AI agent security has to answer both questions: can the agent reach this system, and should it act through it now?

Why generated MCP servers matter now

Anthropic's May 2026 platform cadence made the category sentence louder: agents become useful because they can reach more systems. The May 18, 2026 Stainless acquisition was especially direct. Anthropic described Stainless as a leader in SDKs and MCP server tooling, and noted that Stainless generates the SDKs, CLIs, and MCP servers — the libraries, command-line tools, and connectors — that let developers and agents use an API. The next day, Anthropic and KPMG announced a global alliance and the launch of KPMG Digital Gateway Powered by Claude, embedding Claude into KPMG's client delivery platform with an initial focus on tax, legal, and other enterprise workflows.

That is good category education. It also sharpens the security question. If large platforms normalize generated SDKs, CLIs, MCP servers, connectors, and enterprise workflow integrations, buyers will ask a more operational version of MCP security: how do we decide which generated connector is safe to use, which handoff changed, which callback is untrusted, and which outbound action should be blocked?

This page is not a generic MCP 101. It is a narrower response to the new buyer path: generated API reach creates generated trust decisions. For the broader connector hardening picture, the MCP tool poisoning detection guide covers the server-side controls that sit underneath this layer.

Plain-language explanation: reach vs trust

Think of an MCP server as a bridge between an agent and something useful: a repository, database, browser, SaaS app, ticket queue, build system, internal API, or payment workflow. A generated MCP server or generated SDK can create that bridge faster. It can also create security assumptions faster than the team can review them.

Traditional access control asks whether the agent is allowed to use the bridge. That question matters. Teams should scope credentials, approve tools, pin packages, review generated code, and isolate execution. But agent incidents often happen one step later. The workflow is allowed, then a tool output changes the next step. A callback redirects to a different service. A package endpoint swaps under a familiar name. A schema accepts prompt-bearing fields. A generated connector exposes more authority than the developer intended.

That is the gap between reach and trust:

Generated MCP server security checklist

Use this checklist before treating a generated MCP server, SDK, CLI, connector, or API handoff as safe for production agents. It pairs well with the AI Agent Hardening Manual.

1. Pin the generated artifact

Record the generator, template version, package version, source commit, build digest, and review owner. A generated connector should not be a floating blob that quietly changes underneath agent workflows.

2. Verify MCP server provenance

Know who produced the server, where it is hosted, which account owns it, and which dependency chain it pulls from. Provenance is the first defense against lookalike connectors and quietly replaced endpoints — and against manifests that simply claim a safety status they were never granted.

3. Default-deny dynamic discovery

Agents should not automatically trust every newly discovered server, tool, schema, or resource. Discovery can make setup pleasant, but production trust should require an explicit allowlist and a reason. Dynamic tool-list changes after trust is granted are exactly the capability-drift and rug-pull behavior that GLS-MCP-002 (MCP capability drift) is built to flag.

4. Validate schemas and prompt-bearing fields

Generated schemas can hide dangerous authority in normal-looking fields: URLs, file paths, callback names, shell fragments, package names, environment labels, user-controlled descriptions, and tool output that later becomes instruction context. When tool metadata tries to become higher-priority control text for the agent, that is GLS-MCP-006 (tool metadata prompt injection).

5. Isolate credentials by action class

A connector that reads data should not automatically inherit the ability to write, delete, approve, deploy, transfer, or message. Scope credentials around action classes, not just around the app name.

6. Review callbacks and outbound destinations

MCP workflows often become risky when the next hop changes. Review callback URLs, webhook targets, package registries, redirect destinations, browser handoffs, repo remotes, and cloud API endpoints before action.

7. Log handoffs in human language

Security logs should say what the agent was about to trust: connector, source, destination, credential scope, action class, and reason. A raw tool-call trace is not enough for incident response.

8. Gate risky actions at runtime

Even after static review, the live decision needs a gate. If the connector, payload, destination, callback, package endpoint, or tool output changes the trust boundary, the workflow should pause, downgrade, or block.

Three concrete failure examples

1) Generated SDK points the agent at a lookalike package endpoint

A team generates an SDK and MCP server for an internal package workflow. The agent is allowed to fetch packages during build triage. A dependency hint in a ticket points to a lookalike endpoint with a familiar package name. Access control says the agent can fetch packages. Runtime trust asks whether this endpoint, package, and redirect chain match the expected source before the agent runs or recommends it — the place where provenance and outbound-destination review (checklist steps 2 and 6) do the real work.

2) MCP server schema accepts prompt-bearing support text (GLS-MCP-006)

An MCP server exposes customer support records to an agent. A generated schema includes a free-text field that later enters the model context. An attacker places instructions in the record asking the agent to export account data through a permitted tool. The connector is real. The tool is allowed. The runtime-trust decision is whether the prompt-bearing field should influence the next tool call — a textbook instance of GLS-MCP-006 (tool metadata prompt injection): malicious tool metadata trying to become higher-priority control text for the agent.

3) Enterprise workflow callback changes authority mid-task (GLS-MCP-013, GLS-TOP-237)

An agent inside a finance or advisory workflow prepares a document, receives a callback, and then posts to a different destination than the one the operator reviewed. The workflow surface may have human-in-the-loop approval. The generated connector may be signed. The action-time question is whether the callback changed destination, credential scope, or business context enough to require a new trust decision. This is where GLS-MCP-013 (tool manifest capability claim injection — false capability or safety claims in tool manifests, handoff packets, or status payloads trusted as control-plane truth) and GLS-TOP-237 (tool output poisoning — trusted output override) apply: a handoff or tool result claiming authoritative status to justify the next action.

How Sunglasses catches it

Sunglasses is built for the moment after connectivity is granted and before the workflow acts. It does not need to pretend that platform vendors are wrong about generated SDKs, CLIs, MCP servers, connectors, or human review. Those are real controls. Sunglasses adds the missing runtime-trust layer around the live action path.

In practice, that means Sunglasses looks for risky patterns around prompt-bearing tool output, MCP handoff drift, callback-chain authority changes, package endpoint trust, outbound destination changes, tool metadata confusion, and action requests that cross the expected boundary. The product question is not only "is this connector installed?" It is "should this connector, with this payload and destination, be trusted for this action now?"

The patterns that apply most directly:

For teams that want the smallest practical starting point:

For related background, start with the MCP Attack Atlas, the how Sunglasses works overview, and the prompt injection protection guide. For the credibility evidence behind these patterns, the Continuous Verification Program publishes how Sunglasses performs against real adversarial inputs. This page sits beside those surfaces as the generated-connector security layer.

Related reading