**Kong Identity can now securely broker downstream credentials for AI agents, giving them access to the systems they need without putting those credentials in the agents themselves.**
AI agents are getting access to more of the enterprise.
An engineering agent might need GitHub and Jira. A support agent might need Salesforce, Slack, and an internal customer API. An analytics agent might need Snowflake and Databricks. And increasingly, those resources are exposed through a mix of APIs, MCP servers, models, and event infrastructure.
Every one of those systems has its own identity and authentication requirements.
The obvious solution is to give the agent credentials for each system it needs to access.
It’s also a dangerous one.
The more capable the agent becomes, the more credentials it accumulates. Those credentials end up in exactly the place you don’t want them: inside applications designed to reason and act autonomously.
We’re introducing **Token Vault for Kong Identity**, giving organizations a different approach.
**Agents access everything. Hold nothing.**
Traditional applications generally have well-defined boundaries. They interact with a known set of services using credentials provisioned specifically for those connections.
Agents are different.
Their value comes from their ability to work across systems. An agent may need intelligence from a model, tools exposed through APIs and MCP servers, and context from enterprise data and event streams.
As agents become more capable, their access surface expands.
Without an identity layer sitting between the agent and those resources, that can quickly become:
**Agent → GitHub credential**
**Agent → Jira credential**
**Agent → Slack credential**
**Agent → Snowflake credential**
**Agent → Internal API credential**
**Agent → …**
Now consider what happens when that agent is compromised, manipulated, or simply behaves in a way you didn’t anticipate.
The problem is no longer just what the agent can do.
It’s **what credentials the agent possesses.**
Token Vault changes the architecture.
Instead of giving an agent every downstream credential it might need, the agent authenticates to Kong.
Kong Identity establishes who the agent is. Kong’s policies determine what that identity is allowed to access. Token Vault manages the relationship between that principal and the credentials required by downstream systems.
When the agent accesses an authorized resource, Kong can apply the appropriate downstream credential as part of the request flow.
**Agent → Kong Identity → Policy → Token Vault → Resource**
The agent doesn’t need to understand how every downstream system authenticates. And downstream credentials don’t need to be exposed directly to the agent.
The result is a clean separation between **who the agent is** and **how it authenticates to everything it needs.**
There isn’t one universal authentication scheme waiting on the other side of an agent request.
One resource might use OAuth on behalf of an individual user. Another might require a shared machine-to-machine identity. An internal API might use an administrator-managed key. Another system might have its own OAuth provider.
Token Vault is designed for this heterogeneous environment.
Credential providers can represent different downstream systems and credential models, including per-user and shared credentials. Those providers can then be associated with the resources that use them and the principals authorized to access them.
That means an agent can operate across systems such as GitHub, Slack, Atlassian, Snowflake, Google, Databricks, internal APIs, and other enterprise resources without every authentication mechanism becoming part of the agent itself.
**One agent identity. Many downstream identities. One enforcement layer.**
This architecture has an important security consequence.
If downstream credentials are distributed across agents, compromising an agent can also expose the credentials it possesses. Security teams then have to determine which secrets were exposed, revoke them at their respective providers, provision replacements, and update affected applications.
Brokered access changes that equation.
Access remains tied to the agent’s identity and centrally enforced policy. Security teams can change or revoke what an identity is allowed to access without relying on credentials scattered throughout agent implementations.
And because access flows through Kong, organizations gain a centralized record of which identity accessed which resources.
Agents ultimately need three things to do useful work:
In a real enterprise, those resources are scattered across providers, clouds, SaaS platforms, data systems, and internal infrastructure.
Kong Identity provides a common identity and access layer across that heterogeneous environment, while Token Vault helps bridge the different credential systems agents encounter as they move through it.
Agents don’t need an identity strategy for every new system they access.
They need **one identity layer that can span all of them.**
Token Vault expands the role of Kong Identity.
Kong’s centralized Principals directory already provides a common source of truth for human and machine identities across APIs, AI, and events, with support for multiple authentication mechanisms, metadata-driven policy, credential lifecycle management, analytics, and audit logging.
Token Vault extends that model downstream.
Kong can now help organizations establish the agent’s identity, govern what it is allowed to reach, and broker the credentials required to authenticate to those resources.
Because giving agents access to the enterprise shouldn’t mean giving them the keys to the enterprise.
The future of agent security isn’t creating and distributing more credentials every time an agent gains another capability.
It’s separating **access from possession**.
Give agents the identity they need to operate. Give security teams centralized control over what those identities can access. Let Kong handle the credentials required to make those connections work.
**Kong Token Vault is available as part of Kong Identity.**
[Learn More](https://konghq.com/products/governance-and-identity)Learn More
Modern enterprise APIs don't live in one place. They're spread across multiple gateways, deployed across regions and clouds, and accessed by a growing mix of consumers, internal developers, external partners, machine-to-machine services, and increas
As API ecosystems grow more complex, maintaining visibility and security shouldn't be a hurdle. Kong Gateway 3.13 simplifies these challenges with expanded OpenTelemetry support and more flexible orchestration. These new capabilities not only make y
API management solved a similar problem for developers. Instead of asking a platform team every time they needed an API, developers could go to a Developer Portal, discover what was available to them, and start building — within the governance bound
Today we're excited to announce Kong Gateway 3.9! Since unveiling Kong Gateway 3.8 at API Summit 2024 just a few months ago, we’ve been busy making important updates and improvements to Kong Gateway. This release introduces new functionality arou
APIs facilitate effortless communication and data exchange between applications and services. However, their inherent design, which codifies service capabilities within the API definition, makes them easily exploitable by malicious actors. API attac
Your developer portal was built for a developer scanning docs in a browser: reading a page, copying a curl command, moving on. Increasingly, the thing reading those docs isn't a person. It's an agent, working through an API integration on someone's
