API Governance — A Starter Deck — Kin Lane, API Evangelist

API Governance at the Agent Consumption Layer: Governing 405 Operations Across 36 APIs Without Changing Team Behavior

APIDays Munich

Kin Lane
API Evangelist
[email protected]

01 / 11

My API Governance Journey

Technology, business, and politics of APIs @ API Evangelist since 2010 → API producer mindset → API standardization → API discovery → Chief Evangelist @ Postman and Host of Breaking Changes Podcast → API consumer mindset → OpenAPI, AsyncAPI, JSON Schema → A focus on product-led API governance → API Governance Lead @ Bloomberg → API Evangelist → AI integration

02 / 11

What is API Governance, Really?

Design Guides → OpenAPI → AsyncAPI → JSON Schema → Spectral or Vacuum rules → Linting → CLI → Editors → IDE → Git → CI/CD pipelines → Gateways → Platforms → Portals → Catalogs → Teams → Domains → Lines of Business → Products → Sales → Support → Customers → Feedback Loops

03 / 11

36 APIs · 405 Operations · One Governed Interface — Tyk OAS

{
  "openapi": "3.0.3",
  "info": { "title": "security-ops" },
  "paths": {
    "/address-objects": {
      "get": { "operationId": "addressObjects" }
    }
  },
  "x-tyk-api-gateway": {
    "upstream": { "url": "https://fw.corp" },
    "server": {
      "listenPath": { "value": "/", "strip": true }
    },
    "middleware": { "operations": {
      "addressObjects": {
        "urlRewrite": {
          "enabled": true,
          "pattern": "/address-objects",
          "rewriteTo":
            "/restapi/v10.2/Objects/Addresses"
        }
      }
    }}
  }
}

"middleware": {
  "operations": {
    "alerts": {
      "rateLimit": {
        "enabled": true,
        "rate": 100, "per": 60
      },
      "urlRewrite": {
        "enabled": true,
        "pattern": "/alerts",
        "rewriteTo":
          "https://api.prismacloud.io/iam/v1/alerts"
      },
      "transformRequestHeaders": {
        "enabled": true,
        "add": [{
          "name": "Authorization",
          "value": "Bearer $secret.PRISMA_TOKEN"
        }]
      }
    }
  }
}

Tyk OAS → Operations → Upstreams → URL Rewrite → Auth Enforcement → Rate Limiting → Request Transformation → Observability → Compliance

04 / 11

Multiple Providers · Two Tyk OAS APIs (one upstream each) · Live

# open-meteo-weather-oas.yml    (Tyk OAS)
openapi: 3.0.3
info: { title: Open-Meteo Weather Forecast }
servers:
  - url: http://localhost:8080/weather
paths:
  /forecast:
    get:
      operationId: getWeatherForecast
      # native params: latitude, longitude,
      #   current, forecast_days, timezone
x-tyk-api-gateway:
  upstream:
    url: https://api.open-meteo.com/v1
  server:
    listenPath: { value: /weather/, strip: true }
    authentication: { enabled: false }
  middleware:
    operations:
      getWeatherForecast:
        validateRequest: { enabled: true }
        rateLimit: { enabled: true, rate: 60,
                     per: "60s" }

# spectral.tyk.yml
rules:
  op-rate-limit:
    given: "$..operations.*"
    severity: error
    then:
      field: rateLimit
      function: defined

  op-validate-request:
    given: "$..operations.*"
    severity: error
    then:
      field: validateRequest
      function: defined

build time · run time

# open-meteo-air-quality-oas.yml (Tyk OAS)
openapi: 3.0.3
info: { title: Open-Meteo Air Quality }
servers:
  - url: http://localhost:8080/air
paths:
  /air-quality:
    get: { operationId: getAirQuality }
x-tyk-api-gateway:
  upstream:
    url: https://air-quality-api.open-meteo.com/v1
  server:
    listenPath: { value: /air/, strip: true }
    authentication: { enabled: false }
  middleware:
    operations:
      getAirQuality:
        validateRequest: { enabled: true }
        rateLimit: { enabled: true, rate: 60,
                     per: "60s" }

# one upstream per API  ->  two APIs
# live: weather-tyk.apievangelist.com
# repo: github.com/api-evangelist/open-meteo-tyk-demo

Tyk OAS → one upstream per API → two APIs (weather + air quality), native params → validateRequest + rateLimit + CORS → file-based (Classic + OAS pair) → MCP server → weather-tyk.apievangelist.com

05 / 11

KrakenD · Tyk · agentgateway · AWS OpenAPI-MCP — OpenAPI, Aggregation & MCP

Capability	KrakenD	Tyk	agentgateway	AWS Labs OpenAPI-MCP
What it is	REST gateway, aggregation-first	API mgmt, OpenAPI-native	AI-native MCP / A2A proxy	standalone OpenAPI→MCP server
Reach / transport	network (HTTP)	network (HTTP)	network (HTTP + stdio)	local stdio only (no URL)
Declarative config	✓✓ krakend.json, no-code	✓ Tyk OAS + Operator	✓ YAML + Gateway API	✓ env / CLI · spec is config
OpenAPI → gateway	✓ Enterprise	✓✓ native, config is OAS	✓ to mint MCP tools	— agent-local
REST aggregate / merge	✓✓ declarative, core	✗ code (virtual endpoint)	— MCP only	— MCP only
Req / resp transform	✓ declarative	✓ declarative	✓ CEL, tool-level	✓ tag filter · prompts
API → MCP tools	✓ Enterprise	✓ OSS	✓✓ core purpose	✓✓ core (dynamic)
MCP federation (N → 1)	partial (EE)	✓ proxy remote MCP	✓✓ multiplex, merge tools	✓ multi-spec (per-spec auth)
Chain calls → 1 tool	✓ declarative	code (JS)	✓✓ CEL + code mode	✗ one tool per op
License	OSS core; MCP / OAS = EE	OSS + paid Dashboard	fully OSS	fully OSS (AWS Labs)

The consumer decides the gateway → REST client → KrakenD (declarative merge) or Tyk · networked agent → agentgateway (MCP federation) · agent-local → AWS Labs OpenAPI-MCP (stdio sidecar, the OpenAPI spec is the whole contract)

06 / 11

Same Two APIs · Three Gateways · Running Live

# KrakenD  ·  REST client
# GET :8080/conditions?lat&lon
{
  "weather": {
    "current": {
      "temperature_2m": 27.3,
      "weather_code": 0 } },
  "air_quality": {
    "current": {
      "european_aqi": 39,
      "us_aqi": 56 } }
}
# one request -> two hosts
#            -> merged (no code)

# Tyk OAS  ·  REST + MCP
# GET :8080/weather/forecast
#        ?..&forecast_days=3
# GET :8080/air/air-quality?..
x-tyk-api-gateway:   # one API / upstream
  server:
    listenPath: { value: /weather/ }
  middleware:
    operations:
      getWeatherForecast:
        validateRequest: { enabled: true }
        rateLimit: { rate: 60, per: "60s" }
# two APIs · native params · no rewrite
# live: weather-tyk.apievangelist.com

# agentgateway  ·  AI agent (MCP)
# POST :3000/mcp
tools/list  ->
  [ "weather_getWeatherForecast",
    "airquality_getAirQuality" ]

tools/call weather_getWeatherForecast
{ "current": {
    "temperature_2m": 27.3,
    "weather_code": 0 } }
# two OpenAPI targets, federated
#            into one MCP tool list

Identical upstreams (Open-Meteo weather + air quality) → KrakenD merges for a REST client → Tyk routes & exposes MCP → agentgateway federates as MCP tools for an agent → one contract per consumer, all three live on AWS

07 / 11

GraphQL — Typed Schema at the Consumption Layer

{
  "__schema": {
    "queryType": { "name": "Query" },
    "types": [
      {
        "name": "Query",
        "fields": [
          { "name": "addressObjects",
            "type": { "name": "AddressObject" } },
          { "name": "alerts",
            "type": { "name": "Alert" } },
          { "name": "users",
            "type": { "name": "User" } }
        ]
      },
      {
        "name": "AddressObject",
        "fields": [
          { "name": "name", "type": { "name": "String" } },
          { "name": "ip",   "type": { "name": "String" } },
          { "name": "type", "type": { "name": "String" } }
        ]
      }
    ]
  }
}

{
  "data": {
    "addressObjects": [
      {
        "name": "corp-subnet",
        "ip": "10.0.0.0/8",
        "type": "ip-netmask"
      }
    ],
    "alerts": [
      {
        "id": "ALT-001",
        "severity": "high",
        "status": "open"
      }
    ],
    "users": [
      {
        "id": "U-123",
        "email": "[email protected]",
        "role": "admin"
      }
    ]
  }
}

GraphQL → Typed Schema → Single Endpoint → Query Shape → Field-Level Governance → Introspection → Consumer-Defined Queries → Aggregated Response

08 / 11

MCP — Model Context Protocol for AI Agents

{
  "tools": [
    {
      "name": "list_address_objects",
      "description":
        "List firewall address objects",
      "inputSchema": {
        "type": "object",
        "properties": {
          "type": {
            "type": "string",
            "enum": [
              "ip-netmask",
              "ip-range"
            ]
          }
        }
      }
    },
    {
      "name": "list_alerts",
      "description":
        "List Prisma Cloud security alerts",
      "inputSchema": {
        "type": "object",
        "properties": {
          "severity": {
            "type": "string",
            "enum": ["high","medium","low"]
          }
        }
      }
    }
  ]
}

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "list_alerts",
    "arguments": {
      "severity": "high"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "[{\"id\":\"ALT-001\",
  \"severity\":\"high\",
  \"status\":\"open\",
  \"resource\":\"fw.corp\"}]"
      }
    ]
  }
}

MCP → JSON-RPC 2.0 → Tool Definitions → Input Schema → Agent-Callable Operations → Governed Interface for AI → Structured Responses

09 / 11

Agent Skills — Governed, Reusable Capabilities

---
name: security-triage
description: >
  Correlate high-severity alerts
  with users and network objects
tools:
  - list_alerts
  - list_users
  - list_address_objects
governance:
  auth: required
  rate_limit: 10/min
  audit_log: true
  allowed_roles:
    - security-analyst
    - soc-operator
---
Given high-severity alerts, cross-
reference affected users and network
objects, then summarize findings.

{
  "skill": "security-triage",
  "invoke": {
    "context": "incident-2026",
    "scope": "prod"
  }
}

// → calls list_alerts(high)
// → calls list_users(active)
// → calls list_address_objects()

{
  "skill": "security-triage",
  "result": {
    "alerts": 3,
    "affected_users": 2,
    "network": ["10.0.0.0/8"],
    "summary": "2 accounts accessed
  flagged network ranges during
  3 open high-severity alerts"
  }
}

Agent Skills → Named Capability → Governed Tool Composition → Auth + Rate Limit + Audit → Reusable Across Agents → Policy Enforced at Invocation

10 / 11

Are We Governing People or Are We Governing Engine(s)

Supply Chains → SaaS →People → Teams → Tribes → Products → Budgets → Lifecycle → Versions → Protocols → Patterns → Standards → Pipelines → Gateways → Centralization → Federation → Documentation → Portal → Sales → Support → Customers → Distribution → Regions → Regulation → Global

11 / 11

Consumer-Defined Governance

Consumers → Desktop → Web → Mobile → Copilots → Agents → Automation → Orchestration → Compliance → Observability → Standardization → Context → Transparency → Configuration → Policies → Ephemeral → Secure → Sovereign → Regional → Open-Source → On-Premise → Cloud → Local

Govern the Consumer Layer.
Let Producers Ship What They Ship.

apievangelist.com • github.com/kinlane

Kin Lane • [email protected]