Kong announced an expansion of its AI management platform on 4 November, adding capabilities for tracking costs, observing agent sessions and controlling access to company resources. The Kong AI Management update, integrated into Kong Konnect, brings these capabilities together with its AI capability registry, identity services, Token Vault and version 2.3 of AI Gateway.
The announcement concerns the infrastructure through which applications and agents use models, tools and data, rather than the launch of a new artificial intelligence model. According to Kong, the expansion addresses a shift from isolated model requests to processes in which a single task involves multiple services, APIs, MCP servers and other agents. The platform places control of those interactions within a common configuration and management framework.
Resource access without distributing downstream credentials to every agent
One component presented is Token Vault, available as part of Kong Identity. It brokers the credentials needed to access downstream services at runtime. The agent authenticates to Kong infrastructure, and access to the requested resource is associated with an identity and its applicable rules. A service key or token used further downstream does not have to be embedded in every agent's implementation.
The separation concerns two distinct layers: the identity requesting an operation and the authentication needed by the system performing it. The agent continues to have its own identity. Token Vault manages credentials for authorised resource access, instead of each integration independently retaining copies. The workflow can support access on behalf of a user as well as communication between applications.
Resource access through Token Vault
- Agent identityThe agent authenticates to the infrastructure.
- Access policyPermission to use the resource is checked.
- Token VaultBrokers the required downstream credential.
- Authorised resourceThe service receives the authenticated request.
Kong describes support for OAuth connections, API keys and other credential types, depending on the integrated service. The providers presented include software development, collaboration and data platforms. Under this architecture, authorising an operation and supplying its required credential can be managed centrally, while activity can be traced from the requesting identity to the resource used.
The policies apply to interactions managed through that infrastructure. Withdrawing an agent's access to a resource is a separate decision from changing a key previously distributed to other systems. The component aims to reduce credential proliferation across AI applications while maintaining a common control point over their use, according to the company's technical description.
A registry for approved models and tools
AI Registry adds an inventory of the capabilities an organisation makes available to applications and agents. The registry can contain models, agents, MCP servers, tools, resources and reusable skills. MCP is the protocol through which AI applications can discover and use connected tools or data sources; the registry organises those capabilities alongside their management information.
In Kong's presentation, a record can include ownership, version, approval status, risk context and authentication or access requirements. Publishing a capability for a particular audience is separate from that capability merely existing within the company's infrastructure. The technical inventory and the list of resources an agent can discover are therefore managed explicitly.
The Identity service associates requests with people, applications or agents, allowing the same identity to be used even when authentication methods differ. Metadata about teams, environments or business units can inform policy decisions. This layer of access control for applications and APIs concerns the permissions integrations actually receive, including operations an agent performs on a user's behalf.
Monitoring follows the agent's complete session
The expanded observability capabilities follow the sequence of interactions within an AI session. Rather than looking exclusively at a single model request, a technical team can trace the relationship between calls to models, tools, MCP servers and agents, together with the policies applied. The information includes inputs and outputs, attributes, latency, failures and token consumption.
This tracing concerns the application's operational flow: which services were called, in what order and with what technical outcome. It does not provide access to an internal model reasoning mechanism. Kong describes request, trace and log views, alongside tools for identifying the components where delays or failures occur.
The platform can keep the analysis within the Konnect interface or send telemetry to other systems through OpenTelemetry. Consumption and behaviour can be tracked by model, agent, team and application. This organisation connects API service monitoring with observation of the AI processes using those services, rather than treating each interaction as an event without context.
Costs can be assigned to a team, application or activity
Consumption is measured at the AI gateway, the point through which managed traffic passes. The records can be traced down to an individual request and its token usage. The same allocation structure can cover several model providers while retaining each provider's specific prices in the calculation. Changing providers and identifying the team responsible for consumption are therefore separate dimensions of the records.
The new cost management component turns usage data into records that can be allocated across organisational dimensions. Kong lists teams, users, applications, agents, projects, customers and business activities. Such allocation associates consumption with the unit responsible for it, including situations where several applications use the same model provider.
The calculation takes account of configured pricing structures: input and output tokens, cache use, pricing tiers, regions or negotiated rates. The product includes tracking for budgets, actual consumption and forecasts, alongside limits and notifications. The company also describes traffic optimisation mechanisms such as request routing and caching, without the announcement establishing a savings percentage applicable to every implementation.
The announced expansion therefore combines new cost and observability capabilities with inventory, identity and traffic management components. The objects being tracked remain specific: who performs an operation, which resource they can use, where credentials are managed, what technical path the session follows and which activity receives the consumption allocation.
