Contents

• Introduction

• Why I Created My API Governance Toolkit

• De-risking MCP: Preparing for Enterprise MCP Governance

• An Open-Source Automated Governance Solution for MCP Servers

• OpenAPI & MCP: MCP Server Generation via OpenAPI SDKs

• Using API Gateways for Authentication and Authorisation for MCP Servers

• Interesting Content for this Week

• Upcoming API Conferences

• Feedback & Share

I. Introduction

I first presented some components of my governance toolkit at apidays London 2024. In this issue, I’ll start a series introducing my governance toolkit and how I use it to improve enterprise API governance. Also, the model context protocol (MCP) is a current topic, and I discuss security concerns and governance of MCP servers. Lastly, to underscore the growing importance of AI governance and inter-relationship between API and AI governance, I’ll be splitting the ‘Interesting Content for this Week’ section into ‘On AI Governance and Delivery’ and ‘On API Governance and Delivery’. Enjoy!

👉 PS: If you find my newsletter useful, please share it with a friend.

II. Why I Created My API Governance Toolkit

The explosion of API usage continues. Reliance on APIs for internal applications saw significant growth, reaching an estimated 64% in organisations by 2023, up from 42% in 2021. The integration of Artificial Intelligence further accelerates this trend; usage of AI-related APIs surged by 96% in 2023 alone. However, such rapid expansion underscores the critical need for effective governance. Yet, organisations often lack a comprehensive plan for API governance. A 2024 survey found that  78% of enterprise decision-makers did not know precisely how many APIs their organisation has.

Crucially, governance cannot be discussed in isolation from delivery - the design, development, and deployment of APIs. A fundamental tension exists between effective governance and efficient delivery, demanding a carefully struck balance. Consequently, technology decision-makers responsible for APIs often lack a clear operating model—encompassing people, capabilities, value delivery chain, technology, and scorecards—required to effectively govern and deliver APIs at scale.

The Resulting Problem:

The lack of an effective API delivery operating model leads to the following challenges in enterprise API governance:

Unclear API governance strategy: In a large enterprise, executives in charge of APIs may be unclear on the root causes of API governance issues, and so cannot articulate a clear strategy for API governance.

Poor API standard compliance: There are few or no API design standards. And where there are, they are not followed. APIs are not following the organisations API security standards. 

Long API delivery lead time: It takes a long time to review APIs, and developers must jump through hoops to get their work done. 

API sprawl: The organisation does not know how many APIs it has or where they are at. Shadow APIs (APIs in use, but unsecured and unmanaged) and Zombie APIs (outdated and deprecated, but still in use) are rife. 

API drift: The divergence between an API description and its implementation over time.

Based on my experience tackling these issues, I created a conceptual toolkit improving API governance in the enterprise.

My Solution - IGT-API

The Ikenna® Governance Toolkit for APIs (IGT-API), is a set of thinking tools for creating and improving the API delivery operating model for large-scale API programs. An API delivery operating model (ADOM) visualises the people, capabilities, value delivery chain, technology, and scorecards required to operationalise and govern the implementation of an enterprise API strategy.

The IGT-API helps API producers think end-to-end about all the components they need to put in place for effective API governance. The IGT-API is based on my experience in the field, and comprises of the following tools

1. Ikenna® Delivery Assessment 

2. Ikenna® Delivery Canvas for APIs (IDC-API) & Transformation Plan 

3. Ikenna® Governance Team Model 

4. Ikenna® Improvement Cycles 

5. Ikenna® Delivery Automation Guidance

Figure 1 below, is a high-level view of what the second component, IDC-API, looks like.

Who Is IGT-API for and What Does It Do for Them?

Here are the pain points

To be Continued

I’ll stop here for now. In future issues of my newsletter, I’ll discuss the values and principles my toolkit is based on, and I’ll also discuss each of the toolkit components in detail.

III. De-risking MCP: Preparing for Enterprise MCP Governance

While MCP continues to capture a lot of attention, security and governance teams need to carefully access the risks they introduce. Xinyi Hou et al’s recently published paper “Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions“ describe nine security risks at the creation, operation and update phases of MCP servers. These include installer spoofing, sandbox escape and code injection backdoors. InvariantLabs has demonstrated how an untrusted MCP server can attack and exfiltrate data from a WhatsApp MCP instance. Elena Cross points out that MCP is not secure by default, and plugging in agents into random MCP servers is just asking for trouble - from code injection to tool poisoning attacks.

So how should enterprises respond to the need to govern MCP servers? For starters, enterprises should be in the assess rather than adopt mode with MCP servers, due to its adoption challenges including:

• Lack of centralised platform for security 

• Lack of a unified package management system

• No standardised framework for authn and authz across different clients and servers

• Poor debugging and monitoring mechanisms. 

In the IGT-API, my governance model for APIs (which I’ll discuss in detail in a future issue) is based on four pillars which can also be applied to MCP usage: policies, training, manual controls & audit and automated controls.

1. Policies: The goal of your policy should be to enable secure and compliant usage of MCP servers and associated tools, and manage the risks associated with AI models interacting with external systems via MCP. Here are some examples of what it can include:

   1. Server registration: the registration of internal MCP servers in a central inventory/catalogue.

   2. Tool onboarding: Defining the process for approving tools/APIs to be exposed via MCP servers.

   3. Versioning and updates: Provide guidance on versioning MCP servers and tools. Providing guidance on secure update procedures and rollback plans.

   4. Decommissioning: Establish procedures for retiring MCP servers and tools.

   5. Authn & authz: Provide guidance on auth mechanisms (OAuth 2.1, mTLS) for AI agents (clients) connecting to MCP servers.

2. Training: Provide training to developers building tools exposed via MCP and developers consuming those tools (for example, configuring AI agents or applications to call MCP servers). It should include content on secure development and consumption of tools, and data handling.

3. Manual controls & audits: There are manual tasks you expect developers to do, when there are no automated controls in place yet. For example, you can require developers not connect to random MCP servers, because untrusted sources can lead to data leaks and remote code execution. Governance teams can also run regularly audits and vet third-party tools integrated with MCP.

4. Automated controls: Security testing (SAST, DAST, pen testing) in the CI/CD pipeline of tools (like APIs) exposed via MCP, running tools in sandboxed environments and the automated validation of input/output received from AI agents are countermeasures to consider. Tooling in this area is rapidly evolving, and in the next section, I discuss one open-source option.

In conclusion, enterprise technology governance teams should hold MCP server usage in the assess phase. And that assessment should include exploring the policies, training, manual controls and automated controls they need to govern MCP effectively.

IV. An Open-Source Automated Governance Solution for MCP Servers

Giving all the security risks and adoption challenges I mentioned earlier, how can enterprises automate basic governance of MCP usage, and cover things like authn & authz, credential management, auditing & compliance, and consistency? One company trying to solve this problem is Ithena. Ithena provides an open-source SDK that wraps a standard MCP server, and orchestrates the governance pipeline (the sequence of steps for each MP request or notification). Check Ithena out on GitHub.

V. OpenAPI & MCP: MCP Server Generation via OpenAPI SDKs

SDK generator vendors, who sell tooling to generate SDKs from OpenAPI descriptions, are taking the creation of MCP servers seriously. Speakeasy, Stainless and Mintlify have provided enhancements to their SDK generators to make them generate MCP servers for APIs as well.

Mintlify’s Han Wang declares that “[MCP] enables LLMs to use external tools & services, with MCP servers exposing your data to AI and MCP clients allowing access to that data… We believe the most effective approach is to dynamically generate MCP servers based on existing data structures, like your OpenAPI spec.“ Han identifies two use cases for this

• Making docs AI-accessible to get contextual answers quickly

• Querying APIs directly.

Speakeasy also describes how they do automatically generate MCP servers from OpenAPI descriptions here and Stainless does so here.

But generating MCP servers from OpenAPI only works well when the OpenAPI description accurately describes the API. When there is drift between the OpenAPI document and server behaviour, you have a problem. See my talk on Tackling OpenAPI Drift. And do reach out if you have this issue - providing help on resolving API drift is a service I provide to my clients.

VI. Using API Gateways for Authentication and Authorisation for MCP Servers

The 2025-03-26 version of MCP, treats the MCP server as both an OAuth resource AND authorisation server. This has caused a lot of debate. Solo.io’s Christian Posta argues for using API gateways to handle the OAuth challenge, token verification and traffic routing between MCP clients and remote MCP servers is a more practical approach. And Microsoft have provided an example of doing this with Azure API Management here.

VII. Interesting Content for this Week

On AI Governance and Delivery

Why MCP Development Won’t Scale Without API Simulation: WireMock’s Uri Maoz highlights the importance of API simulation when developing MCP servers.

PII Sanitization Needed for LLMs and Agentic AI is Now Easier to Build: One big worry enterprise IT governance face, is how to avoid personally identifiable information (PII) being leaked into LLMs. Kong’s Alex Drag discusses why PII sanitisation is critical for LLM and agentic AI use cases, and introduces Kong’s AI Sanitizer plugin.

Kong releases AI Gateway 3.10: 🎉 A new AI gateway release! Kong AI Gateway 3.10 introduces the AI RAG Injector plugin to automate Retrieval-Augmented Generation (RAG), aiming to mitigate Large Language Model (LLM) hallucinations and enhance response accuracy.

Benefits of using MCP over traditional integration method: Drishti Shah of Portkey discusses the advantages of MCP as a solution to the challenges of connecting AI to external data.

On API Governance and Delivery

How Healthy is Your API Program: James Higginbotham outlines the stages of API program maturity and presents a framework for assessing and enhancing it across an organisation, focusing on key measurable improvement metrics.

APIs: Unlock the Business Value of Modern Platform Ecosystems: Manoj Mhapankar discusses the business value proposition of APIs, and the benefits of decoupling APIs, gateways and the runtime environment - and why an API catalogue is central to this decoupling.

Enforcing API consistency with a large team: Phil Sturgeon and Alexander Karan discuss four techniques for maintaining API consistency in the enterprise - API style guides, API linting rules, API gateways and API design reviews.

Emmanuel Praskakis on using GenAI for API docs: In this LinkedIn post, Emmanuel argues that when producing technical API documentation, there is a fine line with AI augmentation and slop.

9 Signs You’re Doing API Security Wrong: Nordic APIs’ Kristopher Sandoval outlines nine prevalent API security anti-patterns and ways to avoid them.

ALPS and the Topographic Mindset: "It's a shift in mindset: from navigating roads to reading terrain" - Mike Amundsen, in this article he shares how Application- Level profile semantics is designed to elevate your experience in building systems meant to last.

Documenting API Governance: Documenting API definitions and governance is straightforward; however, detailing stakeholder interactions is often a challenge, Bruno Pedro proposes an alternative he has proven effective in other domains.

Tools

OpenAPI Down Convert: David Biesack’s OpenAPI Down Convert is a utility designed to downgrade OpenAPI 3.1 specification to the older OpenAPI 3.0 version.

VIII. Upcoming API Conferences

IX. API Governance Consulting

Is poor API governance slowing down your delivery? Do you experience API sprawl, API drift and poor API developer satisfaction? I'll provide expert guidance and a tailored roadmap to transform your API practices.

• Ikenna® Delivery Assessment → Identify your biggest API delivery pain points.

• Ikenna® Delivery Canvas (IDC) & API Transformation Plan → Get a unified, data-driven view of your API delivery and governance process.

• Ikenna® Improvement Cycles → Instil a culture of scientific, measurable progress towards API governance.

• Ikenna® Governance Team Model → Set up and improve your governance team to sustain progress.

• Ikenna® Delivery Automation Guidance → Reduce lead time and improve API quality through automation.

Schedule your consultation here.

X. Feedback & Share

I appreciate your feedback. Please help me improve this newsletter by filling out this 1 minute survey. If you find my newsletter useful, please forward and share it with a friend.

Changelog 

14 April 25 : Minor edit and rephrasing.