Notifications
Clear all
Topic starter
11/07/2026 8:24 pm
TL;DR: MCP can make AI agents usable for operational tasks, but the article argues that naïvely generated tool surfaces become too broad, too verbose, and too brittle for models to reason through, according to Stytch. The governance problem is not access alone, but whether agent-facing APIs are intentionally scoped, simplified, and authenticated for safe tool use.
NHIMG editorial — based on content published by Stytch: Agent ready episode 2 with Stainless, auto-generating an MCP server and client auth and identity
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern MCP servers used by AI agents?
A: Security teams should govern MCP servers as delegated access paths, not as generic developer tooling.
Q: Why do MCP servers create new NHI security risks?
A: MCP servers create NHI risk because they let non-human actors reach production systems through a new, model-facing tool layer.
Q: What do teams get wrong about OAuth for remote MCP?
A: Teams often treat OAuth as a login wrapper when it is actually the policy boundary for agent access.
Practitioner guidance
- Inventory agent-facing tools by business action Classify every MCP-exposed action by sensitivity, side effect, and required privilege.
- Design OAuth scopes around task boundaries Map scopes to concrete workflows such as read-only lookup, approval support, or single-resource modification.
- Collapse brittle API chains into one controlled tool If a production task normally requires multiple calls, package it into a single MCP action with explicit validation and logging.
What's in the full article
Stytch's full article covers the operational detail this post intentionally leaves for the source:
- How the MCP server generator approaches OAuth and agent authentication in practice.
- Examples of tool selection, filtering, and chunking decisions that affect real deployments.
- The transcript details specific workflow moments where orchestration breaks down or succeeds.
- The video discussion shows how the team thinks about exposing dashboard functions through agent-accessible tools.
👉 Read Stytch's discussion of MCP server design and agent authentication →
MCP server tool design: are your agent controls keeping up?
Explore further
11/07/2026 8:53 pm
MCP tool sprawl is becoming an identity problem, not just an API design problem: When every endpoint is surfaced to an agent, authorization no longer protects a small set of high-value actions. It has to govern a much larger runtime surface where the actor may choose tools dynamically and repeatedly. That means the security question is really about tool entitlement, task scope, and blast-radius control. Practitioners should treat MCP catalog design as part of identity governance, not only developer experience.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: How can organisations reduce risk when exposing APIs to AI agents?
A: Organisations should expose fewer tools, not more, and make each tool narrower, more legible, and easier to audit. Multi-step workflows should be collapsed into one bounded action where possible, while response filtering should remove anything the agent does not need to finish the task. That reduces drift, repetition, and unnecessary authority.
👉 Read our full editorial: MCP server security depends on purpose-built tool design
