TL;DR: Gartner’s view that 50% of software providers will need to expose their context layer externally by 2029 frames context as a governable asset, not just data, according to Kong’s summary of the research. The real governance challenge is that AI connectivity expands access paths, monetisation pressure, and policy complexity faster than most IAM and API controls were built to handle.
At a glance
What this is: This is Kong’s interpretation of Gartner’s context-economy thesis, which says the strategic asset is shifting from data to context as AI systems need governed access to domain-specific context layers.
Why it matters: It matters because IAM, API governance, and AI control teams now have to decide how context is discovered, exposed, authorised, and metered across humans, workloads, and agents.
Context
The core governance problem is that context is now being treated as a distributable asset, not just an internal data by-product. Once APIs, events, and MCP servers become delivery channels for context, traditional access control models have to deal with who can consume it, under what policy, and for what commercial or operational purpose.
Kong’s article frames this as an AI connectivity problem, but the deeper issue is identity governance across increasingly nested access paths. The control surface now spans API consumers, external orchestrators, AI agents, and partner integrations, which means entitlement decisions, auditability, and usage accountability have to work across multiple protocol layers.
The article’s thesis sits squarely in the emerging enterprise pattern where context becomes both a security object and a monetisable service. That makes the article relevant to IAM, NHI governance, API security, and AI agent oversight at the same time.
Key questions
Q: How should teams govern access to context exposed through MCP servers?
A: Treat MCP exposure as a governed entitlement problem, not a simple integration task. Teams should define who can discover context, who can consume it, and under what policy conditions, then enforce those rules consistently across gateways, registries, and downstream orchestration layers.
Q: Why does the context economy increase identity governance risk?
A: Because it adds more subjects, more delivery paths, and more policy decisions around the same business content. When context can be requested by humans, workloads, and AI agents, the access model must handle delegation, discovery, and consumption accountability at the same time.
Q: What breaks when context is monetised without usage governance?
A: Billing, audit, and access control drift apart. If organisations cannot tie consumption records back to the identity and policy that authorised the request, they lose confidence in revenue attribution, compliance evidence, and whether external parties used the right context for the right purpose.
Q: What is the difference between API governance and context governance?
A: API governance controls how services are exposed and consumed. Context governance goes further by controlling the meaning-bearing data, event, and AI-layer packages that agents and orchestrators use to make decisions, which means entitlement and accountability have to follow the content itself.
Technical breakdown
MCP servers turn context into a governed access surface
Model Context Protocol servers are designed to expose structured context to AI systems, but that exposure changes the control problem from data access to context authorisation. The issue is not simply whether a requester is authenticated. It is whether the requester is entitled to receive enriched, semantically staged context, and whether that entitlement is valid across the full request path from gateway to registry to downstream orchestration. In practice, this pushes governance into the layer where context is published, discovered, and consumed, rather than leaving it at the application boundary.
Practical implication: treat MCP exposure as an access-control design problem, not just an integration pattern.
Unified AI connectivity spans APIs, events, and agent traffic
Kong’s argument is that context no longer lives in one system or one protocol. It is assembled across APIs, event streams, and AI-native traffic such as MCP, which means the governance model has to account for synchronous calls, asynchronous updates, and orchestration paths together. That matters because permissions, logging, and policy enforcement are often implemented differently across those channels, creating uneven visibility and inconsistent control. If the same business context can flow through multiple transport patterns, identity governance has to follow the context, not the protocol silo.
Practical implication: align authorisation, logging, and review processes across API, event, and AI traffic paths.
Context monetisation introduces new entitlement and metering risks
Once context is billable, governance extends beyond access control into usage accounting. Metering, chargeback, and partner revenue sharing all depend on measuring who consumed which context, how much of it was delivered, and under what commercial terms. That creates a new control boundary where entitlement, billing, and audit evidence must stay consistent. If organisations cannot prove consumption accurately, they risk revenue leakage, compliance gaps, and disputes over whether access was authorised for internal, partner, or customer use.
Practical implication: pair entitlement policy with metering evidence so context consumption can be audited and billed consistently.
NHI Mgmt Group analysis
Context is becoming an identity-governed asset, not just an API payload. Once enterprises sell, expose, or broker context, the access question changes from who can call an endpoint to who is entitled to consume a business-ready representation of operational reality. That shifts governance from transport control to context control, where policy must follow meaning as well as data. The practitioner conclusion is that API governance alone no longer covers the full access decision.
The context economy creates entitlement sprawl across humans, workloads, and AI agents. AI connectivity does not replace existing identity models, but it multiplies the number of subjects that can request, relay, transform, or monetise context. That means entitlement design now has to account for non-human consumers, delegated access, and external orchestration paths in the same governance model. Practitioners should expect their access catalogue to expand faster than their current review process can clean it up.
Context monetisation raises the cost of weak governance. When context becomes a billable product, every ambiguity in access scope, rate policy, and consumption attribution becomes a financial control issue as well as a security issue. This is where the named concept of context access governance matters: the organisation must govern who can discover, consume, and resell context, not just whether the system is reachable. The practitioner conclusion is that monetisation strengthens the case for tighter identity and policy controls, because revenue and risk now share the same enforcement point.
Context-layer disintermediation is the new platform risk. The article correctly identifies that enterprises can lose strategic position if richer context is orchestrated elsewhere, but the governance lesson is broader: the organisation that cannot govern context distribution will not control context economics. That changes the identity programme’s scope because authorisation, metering, and partner trust now influence competitive positioning. The practitioner conclusion is to treat context distribution as a governed enterprise capability, not a free-form integration feature.
From our research library:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Context-layer governance will increasingly sit between API management and AI governance. Enterprises that expose context to third-party orchestrators will need to define one policy model for discovery, another for consumption, and a third for metering. That is a broader control problem than classic API security, because the same asset can be requested by humans, workloads, and AI agents through different protocol paths.
Context access governance: the organisation will need a control model for who can discover, consume, and commercialise context across APIs, events, and MCP. That model should be explicit about entitlement scope, external orchestration, and lifecycle offboarding, or it will fail as soon as context becomes revenue-producing.
Practitioners should expect identity review, partner access governance, and billing reconciliation to converge around the same access event. The teams that separate those functions too far will struggle to prove who received which context, under what authority, and for what commercial purpose.
For practitioners
- Map context consumers by identity type Inventory which humans, service accounts, APIs, and AI agents consume exposed context, then classify each by the policy conditions under which that consumption is allowed.
- Separate context discovery from context delivery Require distinct policy decisions for discovering context, subscribing to it, and consuming it through MCP, API, or event paths so each stage has its own control boundary.
- Align metering with entitlement evidence Tie usage records to the identity and policy that authorised the context request so billing, audit, and security teams can reconcile the same transaction.
- Review external orchestrator access paths Assess which third-party orchestrators can reach context layers today, then validate whether those paths are covered by approval, logging, and offboarding processes.
- Classify context as a governed product Define ownership, access rules, and lifecycle controls for each context package before exposing it externally, especially when revenue or partner access depends on it.
Key takeaways
- Context is no longer just something applications use internally. It is becoming a governed enterprise asset that can be exposed, brokered, and sold.
- The biggest control gap is not transport security alone. It is whether organisations can authorise, attribute, and account for context consumption across multiple identity types and channels.
- Security, IAM, and platform teams will need a shared operating model for context discovery, delivery, and metering if they want to avoid governance drift.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article centres on exposing and governing context across API-driven delivery paths and registries. |
| Recommendation — Inventory all context-exposing APIs and registries before allowing external discovery or consumption. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents and external orchestrators consume governed context, creating privilege-scope concerns. |
| Recommendation — Constrain agent and orchestrator privileges to the minimum context scope required for each task. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Context access depends on clear entitlement decisions across humans, workloads, and agents. |
| Recommendation — Define and enforce entitlements for context access across every delivery path and identity type. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The access paths discussed rely on managed credentials, tokens, and lifecycle controls. |
| Recommendation — Manage context-consuming credentials with issuance, rotation, and revocation controls. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article’s central problem is governing who can access and consume exposed context in cloud services. |
| Recommendation — Apply cloud IAM controls to context layers, not just to underlying services and APIs. | ||
Key terms
- Context Economy: A market model in which organisations expose context, not just data, as a service to internal or external consumers. In security terms, it turns meaning-bearing information into a governed asset that needs authorisation, observability, and lifecycle controls across multiple delivery channels.
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Context Mesh: A context mesh is an architecture for distributing enterprise context across APIs, events, and AI-native protocols without creating separate, unmanaged silos. It matters because the same context may be reused by multiple consumers, which makes identity governance, audit, and policy consistency essential.
- Container Access Governance: Container access governance is the set of controls that decides who can deploy, change, and administer container infrastructure. It combines authentication, authorization, and permission management so development and operations teams can work at scale without turning container administration into a collection of isolated, inconsistent accounts.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org