API Products & Sprawl

Designing and governing APIs as products for both human and agent consumers — while agent protocols multiply the sprawl and governance surface.

Also known as: API product, API-as-a-product, API sprawl, API sprawl squared, multi-protocol, federated API management layer

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (12)

• Presentation: APIs for Agents: Rethinking API Programs in the MCP Era Jim Gough, Andreea Niculcea · 2026-09-23 Reader 🖥️
  As agent protocols (MCP, then A2A, then whatever comes next) reshape how consumers reach enterprise systems, Morgan Stanley argues platforms should keep APIs as the stable, governed foundation and use Architecture-as-Code (CALM) to encode, version, and automatically enforce security/governance controls and deployment gates across every protocol adapter built on top — so the organization can adopt new interaction protocols quickly, and evolve already-deployed services at scale, without sacrificing safety or consistency.
• MCP Is Not Just Another API Standard Balaji Venkatasubramaniyar · 2026-09-23 Reader 🖥️
  MCP is not a plumbing/API-standard convenience but a structural shift in who composes integration logic — from developers pre-agreeing a contract to an agent assembling one at runtime out of natural-language tool descriptions — which makes tool descriptions the real interface, unplanned tool composition a structural risk no test suite catches, and enforced governance a precondition for production use rather than later hardening.
• Why Developer Portals Must Evolve in the AI Agent Age Kristopher Sandoval · 2026-09-22 source ↗ Reader 🖥️
  The developer portal is not obsolete but must evolve from a human-facing documentation site into a governed capability registry that serves both human developers and AI agents as first-class consumers, because MCP provides a discovery/invocation layer but not the governance, analytics, and lifecycle infrastructure a portal supplies.
• Coherence, Connections, and… Spacetime Crystals Art Anthony · 2026-09-09 source ↗ Reader 🖥️
  A technically well-performing API is close to worthless if it isn't coherent with the organization's goals, ownership, and structure — and because organizations and their APIs change constantly, that coherence has to be continuously mapped and re-established rather than achieved once and assumed to hold.
• What Is a Token? A Developer's Guide to Every Type Janet Wagner · 2026-07-30 source ↗ Reader 🖥️
  The word 'token' names unrelated technical artifacts across four domains -- identity/authorization state, numerical text representation for LLMs, blockchain asset ownership, and single-purpose application security -- so developers must learn each domain's specific token vocabulary and the engineering tradeoff each token type encodes (statelessness vs. revocability, cost vs. capability, security scope) rather than treating 'token' as one concept.
• What Happens After Every Company Becomes a Data Company? Art Anthony · 2026-07-28 source ↗ Reader 🖥️
  As every company becomes a data company and AI agents begin consuming that data autonomously, organizations must abandon convenience-first identity patterns — broad SSO, single super-profiles, session-long OAuth grants — in favor of a Zero-Trust posture of least-privilege, just-in-time, minimally-scoped, continuously-evaluated access for humans and agents alike, treating themselves as active data stewards rather than passive collectors.
• Presentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI Jörg Schad · 2026-07-24 source ↗ Reader 🖥️
  To make enterprise data safely and scalably consumable by autonomous AI agents, organizations must re-architect their data as domain-owned, containerized "autonomous data products" — self-contained units with a standardized lifecycle, multi-modal output ports, and centrally-enforced but independently-authored policies — rather than continuing to bolt point solutions onto today's fragmented, storage-centric "data hairball."
• 5 Signs That Authenticated API Traffic Is Actually Malicious J Simpson · 2026-07-21 source ↗ Reader 🖥️
  Because most API attacks now come through fully authenticated sessions rather than broken authentication, and valid credentials make an attacker's requests indistinguishable from legitimate traffic at the authentication layer, API security must shift from gating access at login to continuously profiling authenticated users' behavior and flagging deviations — unusual resource requests, access patterns, request volume, bulk actions, and error rates — since these behavioral signals, not credentials, are where malicious authenticated traffic actually reveals itself.
• Google and Industry Partners Announce Agentic Resource Discovery Specification for AI Agents Leela Kumili · 2026-07-14 source ↗ Reader 🖥️
  Google and a broad coalition of industry partners have introduced the Agentic Resource Discovery (ARD) specification, an open, trust-and-verification-based discovery layer built on catalogs and registries that sits beneath execution protocols like MCP and OpenAPI, letting AI agents find and validate tools and services across organizational boundaries without claiming to replace authentication, authorization, or governance.
• Kin Lane on AI and the Future of APIs Art Anthony · 2026-07-08 source ↗ Reader 🖥️
  Kin Lane argues that AI does not remove or replace the underlying API design, access-control, and data-ownership problems enterprises already had — it accelerates them, concentrating control of data and infrastructure into hyperscaler-owned walled gardens, which means durable API strategy (not chasing AI hype) is what will determine who controls value as the AI cycle inevitably cools.
• Building API Products in the AI Era Janet Wagner · 2026-05-09 source ↗ Reader 🖥️
  APIs must now serve both human developers and AI agent consumers, which requires rethinking API product design across multiple dimensions — granularity, protocol diversity, monetization models, and developer experience — to remain competitive in an AI-driven market.
• MCP Is Making API Sprawl Worse Art Anthony · 2025-01-01 source ↗ Reader 🖥️
  MCP introduces a new abstraction layer over APIs that amplifies existing API sprawl and governance challenges rather than solving them, because each MCP server becomes an additional unmanaged surface; but the same agentic AI driving the problem could also power the automated discovery, cataloging, and governance needed to finally bring sprawl under control.

Propositions touching this concept (4)

By publication month, oldest first (extraction month when no publication date is known).

2025-01

• explicitThe pattern of managed, third-party, and unmanaged MCP servers will mirror today's API sprawl categories — but with higher stakes because MCP exposes actions.
  MCP Is Making API Sprawl Worse · p7
• explicitThe trends shaping 2026 (agentic AI, event-driven chaining, MCP proliferation) threaten to make the outcomes of failing to address API sprawl far more catastrophic than in earlier eras.
  MCP Is Making API Sprawl Worse · p9

2026-05

• explicitdevelopedAPIs must now serve both human developers and AI agents as primary consumers, requiring a fundamental rethink of API product design.
  Building API Products in the AI Era · p1
• implicitAPI product companies that do not adapt to AI consumers risk losing market share to those that do.
  Building API Products in the AI Era · p11

Open gaps (22)

• incompleteThe article never addresses the cold-start problem: none of the five signs work without an established behavioral baseline, and it says nothing about how long a baseline takes to become reliable, what happens during that window for new employees, new customers, or newly provisioned service/agent accounts, or how organizations should treat authenticated traffic from identities with no meaningful history yet.
  5 Signs That Authenticated API Traffic Is Actually Malicious — read next: Literature on user/entity behavior analytics (UEBA) cold-start handling, and on non-human/workload identity onboarding (service accounts, AI agent credentials) for how baseline-dependent anomaly detection copes with brand-new identities.
• incompleteThe piece treats each of the five signs largely in isolation and never discusses false-positive cost, alert fatigue, or who triages the resulting flags — for instance, a legitimate quarter-end bulk payroll export, a sales team doing a real end-of-quarter customer-list pull, or an employee traveling and logging in from an unusual country would all trip these detectors, and the article offers no discussion of tuning, escalation policy, or the operational burden this creates for a security team.
  5 Signs That Authenticated API Traffic Is Actually Malicious — read next: SOC/SIEM alert-fatigue research, and case studies on tuning UEBA/anomaly systems to acceptable false-positive rates in production.
• incompleteThe single supporting statistic (95% of API attacks come from authenticated sources) is sourced from a single vendor's (Salt Security) self-published report, and the article does not interrogate the report's methodology, sample, or definition of 'API attack' — nor cross-check it against any independent source.
  5 Signs That Authenticated API Traffic Is Actually Malicious — read next: Read extract-mcp-api-sprawl (which the corpus already flags as a model of independently-sourced adoption/security statistics in the adjacent MCP-governance space) as a comparison point, and look for non-vendor-sourced API attack telemetry (e.g. OWASP, academic breach studies) to corroborate or complicate the 95% figure.
• incompleteThe claim that lineage 'comes for free' once every data asset is a data product elides that lineage across data products built on heterogeneous underlying engines (Spark, Databricks SQL, an Iceberg lakehouse) still requires each engine's own job/run metadata to be captured and correctly correlated across products — the talk asserts this correlation is trivial rather than demonstrating it, and no failure case or edge case (e.g. a data product whose transform spans two engines) is discussed.
  Presentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI — read next: Dedicated data-lineage literature (e.g. OpenLineage) for what cross-engine lineage correlation actually requires.
• incompleteAll evidence for the architecture is either analogy (Kubernetes/Docker/LLVM), an internally-consistent lifecycle description, or one small live demo of the speaker's own vendor product (Nextdata) — no production adoption numbers, latency/overhead measurements of the four-stage lifecycle versus a raw pipeline, or independent case studies are presented, and the speaker's commercial stake as the vendor's VP Engineering is never disclosed as a limitation on the evidence (though he does gesture that 'this is one implementation' of a supposedly vendor-neutral pattern).
  Presentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI — read next: extract-mcp-api-sprawl for hard adoption/security statistics in the adjacent MCP-governance space, as a model of what evidence-backed claims in this domain look like.
• incompleteThe monetization discussion identifies the problem (per-call pricing is inadequate for AI) but the proposed alternatives — outcome-based pricing, dynamic pricing, agent payment protocols — are all nascent. No practical implementation guidance is offered.
  Building API Products in the AI Era — read next: Track AP2 and ACP protocol development; look for early adopter reports on outcome-based API pricing implementations.
• unacknowledgedThe panel's advice is entirely provider-centric. The consumer perspective — what developers and AI agent builders actually want from API products — is not represented with data or research.
  Building API Products in the AI Era — read next: Look for developer surveys or agent-builder interviews about API product preferences and pain points.
• incompleteThe piece asserts that adding machine-readable layers to portals matters increasingly but gives no case study of an organization that has actually done this (successfully or not) — no concrete before/after example of a portal's agent adoption improving after redesign.
  Why Developer Portals Must Evolve in the AI Agent Age — read next: Case studies or postmortems of specific companies redesigning developer portals for agentic consumption; vendor engineering blogs (Stripe, Twilio, Cloudflare) describing what they actually shipped rather than press/analyst framing.
• incompleteNo discussion of cost or organizational tradeoffs — building and maintaining a 'governed capability registry' with structured semantic descriptions, workflow documentation, and runtime discovery is significant engineering investment, but the piece doesn't address who bears that cost or how to prioritize it against other platform work.
  Why Developer Portals Must Evolve in the AI Agent Age — read next: Platform-engineering / API-governance material on prioritization frameworks for infrastructure investment, or the corpus's existing platform-engineering-under-AI material (e.g. the InfoQ platform-engineering roundtable already in the corpus).
• incompleteThe build-vs-buy argument for specialist agents is framed purely as a maintenance-tax tradeoff, with no discussion of vendor lock-in, SLA/accountability questions, or what happens when an officially maintained specialist agent's behavior silently drifts between versions — concerns that other corpus documents on production agent platforms (e.g., API governance under MCP sprawl, enterprise architecture-as-data platforms) treat as central, not peripheral.
  Agent Tools & Interoperability — read next: Read alongside enterprise platform-governance accounts (e.g. the Morgan Stanley CALM/MCP piece) for how organizations actually assign ownership and SLAs across protocol boundaries.
• incompleteMarsman's own framing — 'many discovery services, each defined by what it indexes, whom it serves, and how it ranks' — implicitly reproduces, one level up, the exact fragmentation problem tool registries were meant to solve: now an agent must first discover which discovery service to query. The article surfaces this framing without examining it.
  Google and Industry Partners Announce Agentic Resource Discovery Specification for AI Agents — read next: Watch whether ARD's mentioned but undetailed 'federation model' actually resolves discovery-of-discovery fragmentation, or whether a registry-of-registries layer emerges.
• incompleteThe piece is built entirely from a press release, partner blog posts, and two lightly-sourced Reddit comments — no adoption data, no independent technical assessment of the spec, and no timeline for when the 'reference implementations' mature into production-grade infrastructure.
  Google and Industry Partners Announce Agentic Resource Discovery Specification for AI Agents — read next: Track actual adoption over the following months (number of published ai-catalog.json files, registries running on ARD, independent security review of the trust model) rather than relying on launch-week coverage.
• incompleteLane repeatedly asserts that AI/agent problems 'boil down to API design problems' but never specifies what concrete design practices make an API 'agent-ready' (e.g., machine-readable documentation, deterministic workflow standards). The article links to a prior Nordic APIs piece on Arazzo (deterministic API workflows) but Lane himself doesn't engage with it in this interview.
  Kin Lane on AI and the Future of APIs — read next: The linked Nordic APIs article on deterministic API workflows/Arazzo, and broader API-first / machine-readable-documentation literature for agentic consumption — to turn Lane's diagnosis into actionable design guidance.
• incompleteThe security-risk section raises Broken Object-Level Authentication and cites the Optus breach as a cautionary example, but never connects this to concrete mitigation practices for agent-facing APIs (e.g., OWASP API Security Top 10, authorization models for autonomous/non-human clients) — leaving the reader with anxiety but no path to action. Directly relevant to a telco application-security context.
  Kin Lane on AI and the Future of APIs — read next: OWASP API Security Top 10 and current literature on authorizing and rate-limiting agentic (non-human) API clients.
• illogicalThe claim that 'AI is just going to be [cloud costs] on steroids' rests on a single historical analogy (AWS EC2) and doesn't engage with counter-evidence that per-token/per-query LLM inference costs have been falling even as total usage (and thus total spend) rises — conflating a cost-per-unit trend with a total-spend trend.
  Kin Lane on AI and the Future of APIs — read next: Current data and trend analysis on LLM inference cost-per-token over time, to test whether the EC2/cloud-bill analogy actually holds for AI economics.
• incompleteThe claim that 'business people' are taking back power from engineering/developers is a significant organizational-leadership claim, but the interview never explores the mechanism — how this shift plays out inside engineering orgs, what it implies for platform/API teams' autonomy and decision rights, or what leaders should do in response.
  Kin Lane on AI and the Future of APIs — read next: Organizational-design and platform-team-autonomy literature (e.g., Team Topologies, John Cutler's writing on product operating models) to unpack what this 'business takeback' means for how engineering leadership should structure teams and decision rights under AI-driven budget shifts.
• tensionThe article concludes optimistically that the pressure of MCP-amplified sprawl 'may be just the pressure that teams need to finally bring API sprawl under control.' But the entire preceding argument establishes that organizations have failed to solve sprawl for over a decade despite growing consequences. No mechanism is identified that would make this time different beyond 'the stakes are higher now.'
  MCP Is Making API Sprawl Worse — read next: Research on organizational behavior under existential vs. incremental risk; whether catastrophic failure scenarios actually drive governance adoption or just insurance purchases.
• incompleteThe proposed measurement method (product tree: map an API's goals/jobs/work-items, then map organizational goals above it) is described only in the abstract as 'a first pass' — no worked example, metric, or threshold is given, and Faull's own open-source coherence-measurement framework is explicitly not yet released.
  Coherence, Connections, and… Spacetime Crystals — read next: Track the eventual release of Faull's open-source framework and his Nordic APIs Summit 2026 talk for the operationalized version of this method.
• incompleteThe article never analyzes the tradeoff it implicitly creates: domain separation, token minimization, and decentralized identity reduce the very convenience, personalization, and cross-sell value that make unified super-profiles commercially attractive in the first place. No cost/benefit accounting or case study of an organization that made this shift is offered.
  What Happens After Every Company Becomes a Data Company? — read next: Read alongside CRM/marketing-attribution literature on the revenue value of unified customer profiles, to weigh against the security/compliance benefits this article argues for.
• incompleteThe article's own central provocative question — 'how much data is too much data' — is posed rhetorically and never answered; no threshold, framework, or decision procedure is offered for organizations trying to operationalize 'minimization' in practice.
  What Happens After Every Company Becomes a Data Company? — read next: Data-minimization-by-design frameworks (e.g. NIST privacy engineering, GDPR Art. 5 guidance) that attempt to convert the principle into an auditable practice.
• incompleteThe article places authentication 'tokens' and LLM 'tokens' side by side under one umbrella term without ever flagging that they are entirely unrelated concepts sharing only a name -- a real source of confusion for developers moving into AI-augmented applications who may conflate 'token limit' (LLM context) with 'token expiry' (auth) or assume LLM tokens carry any security property at all.
  What Is a Token? A Developer's Guide to Every Type — read next: Any introductory LLM tokenization explainer paired with an OAuth/JWT primer, read side by side to make the non-relationship explicit.
• incompleteJWT alternatives designed to avoid well-known JWT signature/algorithm pitfalls (e.g., the 'alg: none' vulnerability, RS256/HS256 confusion) such as PASETO are not mentioned, even though the article recommends JWT as the default bearer-token implementation.
  What Is a Token? A Developer's Guide to Every Type — read next: PASETO specification and comparative JWT-vulnerability writeups.