Kong launches Token Vault to control enterprise AI agent access

By Sophie Lindqvist

Kong has made Token Vault for Kong Identity generally available, adding runtime credential brokering for enterprise AI agents. The product gives agents access to approved downstream resources without placing the underlying credentials in the agents’ hands.

Kong says the release comes as companies give AI agents broader roles across internal systems, applications and data stores. Security teams consequently face a growing set of credentials tied to those agents.

The security stakes are direct: a compromised, misconfigured or unexpectedly behaving agent could use persistent credentials to act across multiple systems faster than a human operator. Token Vault is Kong’s answer to that combination of broad access and direct credential possession.

What happens when an agent calls a downstream system?

Under Kong’s model, identification, authorisation and credential delivery are separate steps. The company describes the flow in three parts:

• The agent authenticates using its own identity.
• Kong Identity determines what the agent may access.
• Token Vault supplies the relevant downstream credential when the agent sends an authorised request.

Kong says the agent never holds that downstream credential directly. An authorised request can proceed while the credential remains under centralised control.

Token Vault therefore does not decide access by itself. Kong Identity makes that decision first, and Token Vault handles the credential step needed for the request.

The core mechanism is simple: approve the action first, then supply the relevant credential at runtime. In plain terms, the agent gets access without holding the secret.

Why does giving agents credentials create risk?

Kong says agents often need broad access to work across APIs, applications, services and data sources. Static credentials leave the organisation with a difficult set of secrets to manage and protect, especially as each additional system adds another authentication requirement.

That system can create credential sprawl. It also increases the potential fallout if a credential is exposed. Kong identifies compromise, misconfiguration and unexpected agent behaviour as the scenarios in which persistent access could become dangerous.

In that scenario, a persistent credential could let an agent act across several systems faster than a human operator. The problem comes from combining broad operational access with direct possession of the secrets needed to exercise it.

Kong says centralising the brokering process is intended to make credential management and revocation easier. It also reduces credential exposure and avoids the need to build separate credential logic for each new integration.

The practical benefit is control without distribution. Organisations can widen an agent’s permitted reach without issuing every downstream secret to that agent.

Which resources can agents reach?

Kong says Token Vault can broker access to APIs, MCP servers, models, data and other authorised resources. Those are the resource types named in the release, covering both software interfaces and enterprise data.

The agent still operates within the access decision made by Kong Identity. Token Vault supplies a credential only after that decision has approved the request, according to the company’s described sequence.

The resource list shows how broad the brokered relationship can become. APIs, MCP servers, models and data each represent a different downstream destination, while other authorised resources leave the category open. Kong says the same separation applies throughout: Identity sets the permitted scope, and Token Vault supplies the relevant credential for an authorised request. The announcement does not say those destinations share one credential; Token Vault supplies the relevant credential for each authorised downstream request.

That separation is the product’s core claim. It changes where credentials live, not whether an agent needs access.

How does Token Vault fit with Kong Identity?

Token Vault expands Kong Identity beyond agent identification and authentication. The product now covers identification, authorisation and credential brokering within the identity service, according to Kong.

Token Vault can also work alongside Kong’s gateways and policy enforcement tools. Kong says organisations can manage agent identification, access decisions, credential brokering, policy enforcement and audit activity within one architecture.

The company is presenting that consolidation for security and identity teams dealing with agents in production environments. Its argument is that useful agents need broad reach, while static credentials make that reach harder to contain.

The resulting architecture links who an agent is, what it may do and which credential authorises the downstream action. In plain terms, it connects identity, permission and credentials.

What does Kong say about separating access from possession?

Reza Shafii, Senior Vice President, Product, Kong, said: "Enterprises need a way to expand what agents can access without expanding the credentials those agents hold."

He expanded: "Token Vault separates access from credential possession, allowing organisations to give agents the connectivity they need while keeping downstream credentials under centralised control. As agents take on more work across the enterprise, that distinction becomes critical to securing how they interact with the systems and data they rely on."

Shafii’s framing treats credential possession as a separate risk from operational access, rather than treating both as one permission decision.

That matters because an agent can have a legitimate reason to call many enterprise systems. Giving it direct credentials would also give it the means to reuse those credentials wherever they work.

Kong’s argument is that agent connectivity and downstream credential custody should scale independently. The practical takeaway is straightforward: an agent can receive more access without receiving more secrets.

Does Token Vault remove the risk from a bad agent?

Kong does not present Token Vault as a way to make compromised or misconfigured agents harmless. The product addresses credential exposure by keeping downstream secrets out of the agent’s direct possession.

Under the described flow, the agent’s permitted scope still comes from Kong Identity. A faulty request can still matter, but the agent does not automatically receive the persistent secrets that could let it reach several systems on its own.

The mechanism limits one failure path. It does not replace authorisation, policy enforcement or the need to manage access as an agent’s responsibilities grow.

Kong’s claimed protection follows from the credential split. The described sequence calls for Token Vault to supply a credential only when the request is authorised.

The claimed protection is narrower than safety: it limits secret exposure, not the consequences of a bad request. The agent can still misuse authorised access.

What does the launch leave unanswered?

The release announcement provides no calendar launch date, pricing, named customer deployments or performance benchmarks. It also leaves unspecified credential formats, storage design and protocol-level implementation.

Those omissions do not change the stated access model. They do leave security teams without evidence about cost, scale or results in live deployments, at least in the material Kong provided.

The control model is clear. Its performance at enterprise scale is not established in the release.

What happens next?

Kong is positioning Token Vault for agents taking on broader roles across internal systems, applications and data stores. The product is designed to centralise credentials rather than issue a new persistent secret for every connection.

The test is whether central control can remain easier to manage than the sprawl it replaces. Kong says centralised brokering should make management and revocation easier as the number of integrations grows.

Shafii said the separation becomes critical as agents take on more work. The practical measure of success will be whether enterprises can broaden agent access without broadening the set of credentials those agents hold.