Kong’s context economy thesis raises new AI governance pressure

At a glance

What this is: Kong argues that AI value is shifting from data ownership to governed access to context delivered through APIs and MCP tools.

Why it matters: IAM, NHI, and AI governance teams need to rethink who and what can consume context in real time, because access, routing, and auditability now shape business value and exposure.

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.
• Today, that number is less than 2%.

👉 Read Kong's analysis of the context economy and AI connectivity

Context

The context economy is the idea that AI systems derive competitive advantage from the semantic context wrapped around data, not just from access to the data itself. For identity and access teams, that turns context delivery into a governed control surface across APIs, event streams, MCP tools, and the identities that request them.

Kong frames the problem as an architecture gap: most enterprises still built their access models for humans consuming services in fixed workflows, not for AI agents pulling context at runtime across multiple systems. That mismatch creates pressure on NHI governance, API security, and auditability at the same time.

The practical question is no longer whether context exists inside the business. It is whether the organisation can expose it, meter it, and control who or what can use it without creating leakage, compliance exposure, or value loss.

Key questions

Q: How should teams govern AI agent access to enterprise context?

A: Teams should treat context access as a governed entitlement, not a generic integration. Define which agents, workloads, and partner systems can request which data or tools, then enforce approval, logging, and revocation at the protocol layer. That approach keeps AI connectivity auditable and prevents context from becoming an uncontrolled shadow privilege.

Q: Why do AI agents complicate traditional IAM and API controls?

A: AI agents complicate traditional IAM because they can consume context dynamically across many systems, often without a stable human session behind the request. Existing controls were designed for predictable users and bounded transactions, so teams need stronger policy, tracing, and scoped access to keep agent-driven requests inside intended boundaries.

Q: What signals show that context exposure is becoming a governance problem?

A: Warning signs include uncatalogued APIs, unclear ownership for MCP tools, missing audit trails for agent requests, and no linkage between access policy and business value. If security, platform, and finance teams cannot explain who used context and why, the organisation has a governance gap, not just an integration gap.

Q: How can organisations avoid overexposing context to partners and AI systems?

A: Use least privilege, explicit approval paths, and metering on every context delivery point. Separate discovery from entitlement, limit tool scopes, and review externalised context against legal, compliance, and commercial requirements before broad rollout. That prevents value leakage while keeping the system usable for agents and partners.

Technical breakdown

Context delivery through APIs and MCP tools

In Kong’s framing, context is not a static data object. It is a deliverable assembled from APIs, event streams, transactional systems, and semantic enrichment, then consumed by AI agents at the moment of need. MCP matters because it standardises how agents reach tools and data sources, but it also expands the number of access paths that need governance. The technical challenge is not only authentication. It is orchestration, policy enforcement, and traceability across heterogeneous protocols and consumers.

Practical implication: model context access as a governed identity workflow, not just an integration problem.

Why human-era access models break under agentic traffic

Traditional enterprise access patterns assume a human operator, a bounded session, and a clearly observable intent. AI agents break that assumption by requesting context across business units, in real time, and often without a one-to-one relationship between a user and the downstream request. That creates a control problem for least privilege, logging, and approval flows because the consumer is not a person with stable intent. The architecture has to account for machine consumers that discover, compose, and consume context dynamically.

Practical implication: review whether your current IAM and API controls can distinguish human intent from agent-driven requests.

Monetisation and governance belong in the same control plane

Kong argues that enterprises will need a platform that spans the full context lifecycle, from discovery to governance to monetisation. That is more than a commercial claim. It reflects a technical reality: once context becomes an externalised asset, you need consistent policy, metering, and entitlement controls across every surface where it flows. Without that, organisations may expose valuable context without being able to prove who used it, how often, or under what terms.

Practical implication: align entitlement, metering, and audit logging before you expose context to partner or agent ecosystems.

NHI Mgmt Group analysis

Context has become an identity governed asset, not just a data asset. Once APIs and MCP tools are the delivery path for AI systems, access control, auditability, and policy enforcement sit directly on the value layer. That means identity teams are no longer supporting the business context layer from the side. They are the control point that determines whether context can be safely consumed, priced, and traced.

Human-centric access models do not scale cleanly to agentic consumption. The enterprise assumption that a requester is a stable human operator with a bounded session and observable intent no longer holds in AI-native workflows. That is why NHI governance and API security now converge around the same question: who or what is entitled to act on context, and how is that entitlement governed over time?

Context economy pressure will widen the gap between exposed capability and governed capability. Organisations can surface data quickly, but they often cannot explain the lineage, policy, and usage terms that make context safe to externalise. The result is a growing control gap between what AI agents can technically reach and what the enterprise can defensibly allow.

Policy, metering, and entitlement are converging into one operational problem. The market is moving toward platforms that can both deliver context and account for its use. That makes identity governance, API policy, and commercial control inseparable in practice. Practitioners should treat context exposure as a lifecycle problem with security, legal, and finance stakeholders at the same table.

OWASP NHI Top 10 thinking is increasingly relevant to AI connectivity. As context flows through machine identities, the same failure patterns reappear in a more dynamic form: over-permissioned access, weak provenance, and incomplete audit trails. The difference is scale and speed. Teams that still treat AI connectivity as a pure integration project will miss the governance layer that decides whether context becomes an asset or an exposure.

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.
• 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.
• For a broader control lens, see OWASP Agentic AI Top 10 for the runtime abuse patterns that make context governance harder.

What this signals

Context economy planning will force identity teams to decide where governed access ends and commercial exposure begins. If context is becoming the scarce resource in AI delivery, then the control plane has to prove who can reach it, how it is traced, and when it is revoked. That is a policy design issue as much as a platform issue.

With 48% of companies unable to track and audit the data their AI agents access, the gap is already operational, not theoretical. Teams that cannot observe context use cannot defend it, meter it, or investigate it when a downstream incident occurs.

Governed AI connectivity will increasingly depend on machine identity discipline. Once AI agents consume APIs and MCP tools at scale, the organisation needs a lifecycle view of those consumers, not just application routing. The practical next step is to align AI access policy with identity inventory, audit evidence, and revocation processes.

For practitioners

• Define a context entitlement model Map which APIs, event streams, and MCP tools may expose context to AI agents, partner systems, and internal workloads. Tie each exposure path to a named business owner, a policy decision, and an audit requirement so entitlement is explicit before integration work begins.
• Instrument context usage end to end Require logging for who requested context, which agent or workload consumed it, which tools were invoked, and whether the request was metered or blocked. Use those signals to validate policy decisions and to support chargeback, compliance, and incident review.
• Separate discovery from access approval Allow agents and developers to find available context without granting standing access to the underlying data or tools. Use staged approval, scoped tokens, and time-bounded access so discovery does not become an indirect entitlement path.
• Treat MCP tools as governed identities Register each tool as a controlled identity with clear ownership, scope limits, and revocation processes. This makes tool sprawl visible and gives security teams a concrete place to apply policy rather than relying on application teams alone.

Key takeaways

• The core issue is not whether enterprises have data, but whether they can govern context as a consumable identity asset.
• The evidence points to a widening control gap: AI agents are already acting outside intended scope in most organisations, while visibility remains incomplete.
• Practitioners should align entitlement, auditability, and metering before context is exposed to agents or external orchestrators.

Key terms

• Context layer: The context layer is the semantic and operational information wrapped around raw data so AI systems can act on it. It usually includes metadata, routing signals, business rules, and enrichment needed to make the data useful at runtime.
• MCP tool: An MCP tool is a callable capability exposed through the Model Context Protocol for use by an AI agent or other software consumer. In practice, it becomes an identity and access control surface because the tool determines what context can be reached and what actions can follow.
• Context entitlement: Context entitlement is the approved right for a person, workload, or agent to receive a specific slice of context. It combines access scope, policy, and auditability, and it should be treated as a governed privilege rather than a generic integration setting.
• AI connectivity: AI connectivity is the architecture that lets AI systems discover, request, and use enterprise context through APIs, tools, and event streams. It becomes an identity problem when the organisation must control who or what can traverse those paths, under what conditions, and with what evidence.

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 operational governance, it is worth exploring.

This post draws on content published by Kong: In the Context Economy, Context is King. Read the original.