Kong’s context-economy thesis raises new AI connectivity governance risks

At a glance

What this is: This is Kong’s interpretation of Gartner’s context-economy thesis, arguing that enterprises now need governed AI connectivity rather than raw API exposure.

Why it matters: It matters because IAM, NHI, and platform teams must control who or what can consume context, under what conditions, and how that access is audited across APIs, events, and AI-native protocols.

By the numbers:

• By 2029, 50% of software application providers will be forced to share their context layer externally for third-party orchestrators to stay relevant, versus less than 2% today.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Kong’s analysis of Gartner’s context-economy thesis and AI connectivity platform

Context

Context is the governed, enriched information that AI agents, APIs, and external orchestrators consume to make decisions and take action. Kong’s framing reflects a shift away from treating APIs as isolated interfaces and toward treating context as an access-controlled asset with business value and security implications.

For identity teams, that means the control problem is no longer just authentication at the edge. It is lifecycle governance for context consumers, policy enforcement across machine and agent identities, and auditability across API, event, and MCP traffic.

The article is a vendor interpretation of Gartner’s context-economy thesis, but the underlying operating model change is real: once context becomes externally consumable, access governance becomes a platform requirement rather than a point control.

Key questions

Q: How should security teams govern AI agents that consume enterprise context?

A: Security teams should treat each AI agent as a distinct consumer identity with explicit entitlements, approved context classes, and lifecycle ownership. The key is to govern what context the agent can discover, request, and reuse, not just whether it can authenticate. Access should be logged, reviewed, and revoked like any other privileged machine identity.

Q: Why do MCP servers create new IAM and NHI governance risk?

A: MCP servers create risk because they expose structured context to non-human consumers through a standard protocol, which can outpace existing identity controls. If authorisation, audit, and lifecycle governance are not tied to the consuming identity, organisations can lose visibility into who accessed what context and why. That is a governance failure, not just an integration issue.

Q: What breaks when context access is managed like ordinary API traffic?

A: What breaks is the assumption that endpoint control is enough. Context can be consumed, copied, combined, and reused by downstream agents or orchestrators in ways that ordinary API policies do not capture. Teams need context-aware entitlement models, not only network routing or token validation.

Q: How can organisations monetise context without weakening governance?

A: Organisations should only monetise context when access control, metering, and audit records are aligned. If billing says one thing and security logs say another, the business cannot prove who consumed what, when, or under which entitlement. That creates compliance risk and revenue leakage at the same time.

Technical breakdown

MCP servers and context distribution

Model Context Protocol servers expose tools, prompts, and structured context to AI systems over a standard interface. In this model, the security problem is not simply access to an API, but which agent can discover, request, and consume a particular context object, and under what policy. That changes authorisation from static endpoint control to governed context distribution across internal and external consumers. When the same data can be surfaced through multiple AI-native paths, identity, policy, and telemetry have to follow the context rather than the application boundary.

Practical implication: map MCP access to identity, policy, and audit controls before exposing context to agents or external orchestrators.

AI gateways as policy enforcement points

AI gateways sit between agents and downstream systems to apply routing, approval, rate limits, logging, and usage controls. In practice, they become the enforcement layer for AI connectivity because they can distinguish between raw traffic and approved context flows. The architectural issue is that gateways only help if they are paired with identity-aware policies and lifecycle governance for the actors consuming the context. Without that, a gateway becomes a traffic shaper, not a governance boundary.

Practical implication: require identity-bound policy decisions at the gateway, not only network or token-level controls.

Context monetisation needs governance

Once context is monetised, it must be metered, attributed, and governed like any other production asset. That introduces entitlement questions, chargeback questions, partner access questions, and abuse-detection questions all at once. The technical challenge is that usage-based models create a second control plane for policy and billing, and both must stay consistent. If access, metering, and billing drift apart, organisations can leak value even when the API layer is technically secure.

Practical implication: align access policy, metering, and billing records so context consumption stays attributable and enforceable.

Threat narrative

Attacker objective: The objective is to consume valuable enterprise context beyond intended bounds, either for data extraction, workflow abuse, or unauthorised orchestration.

1. entry: a consumer, often an AI agent or external orchestrator, reaches context through exposed APIs, events, or an MCP server rather than a traditional user workflow.
2. escalation: the consumer is granted broader context than intended because discovery, authorisation, and usage policy are not tightly coupled to identity and purpose.
3. impact: sensitive context can be over-consumed, copied into downstream systems, or monetised without adequate governance, creating compliance and revenue leakage.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Context access is becoming an identity problem, not just an integration problem. Once context is distributed through MCP servers, AI gateways, and event streams, the question is no longer whether systems can connect. The question is which identities can consume which context, and how that access is governed over time. That shifts ownership from integration teams alone to IAM, NHI, and platform security together. Practitioners should treat context exposure as an entitlement surface.

The context economy creates a new class of privilege: context privilege. Enterprises have long governed data access and API access separately, but AI-native systems collapse those layers into a single consumable path. That means a consumer can have technically valid access while still violating intended business scope. The practical conclusion is that access reviews must account for purpose, context class, and downstream reuse, not just successful authentication.

Context monetisation amplifies governance debt if lifecycle controls are weak. Metering and billing only work when the identity lifecycle behind each consumer is clear. If partner accounts, service identities, or agents are not retired cleanly, the organisation can continue exposing billable context to actors that no longer should exist. The implication is that offboarding, recertification, and entitlement governance now protect revenue as much as they protect security.

AI connectivity platforms are converging on control-plane logic because point controls are insufficient. The article reflects a market direction where gateways, registries, portals, and billing systems are being pulled into one governance layer. That validates the idea that AI traffic cannot be secured as ordinary API traffic. Practitioners should expect procurement and architecture reviews to shift toward platform-level identity governance for agents and context consumers.

Named concept: context privilege. This is the entitlement to consume enriched, domain-specific context through AI-native paths such as MCP, APIs, and event streams. It matters because the value and the risk both sit above raw data access. The practitioner conclusion is that context access should be governed as a distinct privilege class with lifecycle, policy, and audit requirements.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• From our research: 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• For the governance model behind this trend, see OWASP Agentic AI Top 10 for the control patterns that matter when agents consume context at runtime.

What this signals

Context privilege is likely to become the next governance class that identity teams have to inventory. As AI systems consume more enriched business context, the line between API access, data access, and delegated action will keep blurring. Teams should prepare to model context as a reviewable entitlement, not a byproduct of integration.

Agent and service-account governance will need to converge around consumption, not just provisioning. That means lifecycle processes must follow the context consumer, whether the consumer is a workload, a partner integration, or an AI agent. The practical test is whether you can prove who had access to which context at any point in time.

The broader signal is that platform-level AI governance is becoming inseparable from identity governance. If your organisation cannot tie context access to an accountable identity and a reviewable purpose, the architecture is already ahead of the controls.

For practitioners

• Define context privilege as a governed entitlement Classify which APIs, events, prompts, and MCP resources count as high-value context, then assign explicit owners, approvers, and review cadence for each access path.
• Bind AI gateway policy to identity lifecycle Require service accounts, agent identities, and partner consumers to be provisioned, reviewed, and offboarded through the same lifecycle process that governs other privileged access.
• Separate discoverability from authorisation Allow context to be searchable in a portal only when entitlement, purpose, and usage conditions are enforced at the point of consumption, not merely at registration.
• Align metering with security audit logs Reconcile billing records, access logs, and context delivery logs so that every consumer of monetised context can be attributed, reviewed, and investigated.

Key takeaways

• AI connectivity turns context into a governed entitlement, which means identity teams now have to manage who can consume enriched business context, not just who can call an API.
• The evidence across agent research is consistent: most organisations still lack reliable visibility into what AI systems access and do, so governance gaps are already operational, not theoretical.
• Enterprises that want to monetise context safely will need lifecycle, policy, and audit controls that keep access, metering, and accountability aligned.

Key terms

• Context Privilege: The right for an identity, human or non-human, to consume enriched business context through APIs, events, prompts, or AI-native interfaces. It is narrower than general data access because it includes purpose, provenance, and downstream reuse. Governance must track lifecycle, approval, and auditability.
• MCP Server: A Model Context Protocol server is a service that exposes tools, resources, and prompts to AI applications through a standard interface. In governance terms, it becomes a controlled distribution point for context, so authorisation and logging need to follow the consumer identity, not just the endpoint.
• AI Gateway: An AI gateway is a policy enforcement layer that sits between AI consumers and downstream systems. It can route requests, apply approval or rate limits, and capture logs, but it only provides governance value when connected to identity, entitlement, and lifecycle controls.
• 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: Gartner Just Described the Platform Enterprises Need to Compete in the Context Economy, Kong Already Built It. Read the original.