Kong Token Vault lets agents avoid API secrets – what risks remain?
Kong has released Token Vault for Kong Identity as generally available. The idea is to broker authorized downstream credentials at runtime rather than embedding them in the agent. The security question shifts from where the token is stored to who is allowed to perform which action.
Kong says agents can access authorized MCP tools without possessing downstream secrets. Credential brokering is GA, not proof that every delegated action is safe.
1. The actual November launch
On 4 November 2026 Kong announced the general availability of Token Vault for Kong Identity. Agents authenticate to Kong under their own identity. Kong Identity assesses what they may access, and Token Vault brokers the appropriate downstream credential for an authorized request at runtime.
The stated benefit is narrower credential exposure inside long-running agent environments. As integrations grow across APIs, MCP servers and enterprise databases, removing durable secrets from the agent's own context can reduce a specific class of compromise. It does not amount to an independent security evaluation or an assurance that all delegated tasks are correct.
2. Following an action across five identities and systems
A practical request traverses employee → AI agent → gateway authorization → Token Vault → downstream API. Kong describes the gateway as evaluating access policies before loading the required credential. This creates a central enforcement point for the request.
Yet the distinction between a valid connection and an authorized business action remains critical. A support agent might be entitled to read a customer record but not change an order status. An enterprise needs to verify both the delegated user and the specific tool action, not merely the fact that OAuth succeeded.
3. AgentenCode access and revocation matrix
| Boundary | Vendor approach | Evidence to collect |
|---|---|---|
| Employee identity | Corporate IdP and delegated user context | One user's grants do not cross to another |
| Agent identity | Agent authenticates with Kong Identity | Agent-specific policy and logs |
| Gateway | Enforcement before credentials are loaded | Forbidden tool calls actually fail |
| Vault | Broker downstream secrets at runtime | No secret leakage to agent traces |
| Target API | Executes authorized operation | Read/write and revocation behavior tested |
4. Threats the vault does not eliminate
A vault does not automatically stop malicious instructions, a bad authorization policy, an over-scoped token or a harmful action that happens to be technically permitted. The central investigation question is whether user principal, agent identity, policy decision and downstream action can be reconstructed together.
Kong emphasizes simpler credential revocation. Enterprises should still test whether revoking access interrupts newly requested and already running tasks, and what the downstream system does with previously accepted work. A potential gap to test is not an alleged product vulnerability.
5. What is GA and what remains on the roadmap?
Kong explicitly labels Token Vault generally available. Its product overview also presents AI Cost Management and baseline observability with the Gateway on Konnect, but says advanced session- and turn-level tracing is coming in late November or early December. Do not present future tracing as proof of detailed auditability for a tenant today.
The vendor states that several capabilities are included with Kong AI Gateway on Konnect without a separate SKU. This does not establish a zero-cost deployment, a particular customer's entitlements or a universal pricing model.
6. A reproducible MCP pilot
Begin with one non-production GitHub or Salesforce integration and one read-only MCP operation. Capture the employee identity, the agent principal, the gateway policy, the target credential scope and the outcome. Deliberately test a denied operation, an expired grant and a revoked connection.
Only then trial a write operation with an explicit human approval point. The result should be a permission ledger and a short incident-response playbook: who can revoke, how quickly denial takes effect and what telemetry is retained. These are recommended tests, not completed AgentenCode product tests.
7. Our assessment and practical answers
AgentenCode assessment: Credential brokering can make persistent enterprise agents easier to govern by separating possession of a secret from the right to request a tool operation. It is useful architectural progress, but does not replace least-privilege scopes, action approvals and auditable business outcomes.
For an example of persistent agents that warrant explicit tool-scope review, see the Perplexity Teammates agent dossier. This is a general governance comparison, not a claim of a Kong integration.
Is Token Vault generally available? Kong says yes, as of 4 November. Does the agent need any identity? Yes: the agent authenticates to Kong even though downstream credentials are brokered. Can we assume full session traces today? No; advanced observability is scheduled for a later date.
8. Original sources and evidence limits
Primary sources: Kong launch announcement, 4 November 2026, technical Token Vault article and Kong AI Management roadmap clarification. Reviewed 9 November 2026.
The decision matrix is AgentenCode's original analysis. There was no hands-on OAuth test, no independent security audit, no observed customer outcome and no verified enterprise contract.