Kong Token Vault: Test the Authority Behind Brokered Agent Credentials

Sources checked: 10 November 2026. FailSafe Research.

Removing a credential from an agent's context can reduce exposure. The next assurance question is which actions the broker will authorize on the agent's behalf. A compromised agent may no longer read a raw secret while still being able to request an operation that exceeds the user's intent.

What Token Vault changes

Kong's November 4 Token Vault announcement describes generally available credential brokering through Kong Identity. Agents authenticate using their own identity while the broker presents downstream credentials for authorized access to APIs, MCP servers and other resources. These are vendor-described capabilities. This article does not claim a FailSafe certification or a completed evaluation of Kong's implementation.

Start with identity binding

Document the relationship among the human requester, agent identity, broker policy and downstream role. In a synthetic case, ask which subject the final service evaluates and whether the subject is appropriate for the requested resource. A valid credential can still represent an overbroad role. The assessment should establish the intended boundary before judging the observed result.

FailSafe's AI, API and identity assessments examine how delegated authority becomes a tool action. For a credential-broker deployment, we scope the customer-owned identity relationships, expected permissions, observable policy decisions and approved downstream effects. The broker remains a component under assessment rather than a product category FailSafe claims to replace.

Check composition and revocation

Use two fictional agents with different duties and a small synthetic data set. Confirm that a permitted operation works for the right identity and is denied to the other. Then evaluate a controlled sequence across the approved tools. A read capability and an export capability may require a combined policy even if each operation looks ordinary on its own.

Revocation needs its own result. Record when access is withdrawn and which subsequent requests are denied. Include refresh behavior and already queued work where they exist. Changing a policy in a dashboard does not establish that cached or previously issued authority stopped working. The report should state the observed delay and leave unobservable routes unresolved.

Ask whether alternate routes share the policy

A gateway may enforce an intended restriction while another customer-owned integration reaches the same service through a different path. Map which routes are in scope and which require further permissions. A useful finding identifies the enforcing component, expected decision and actual result; it does not equate every alternate connector with a bypass without a demonstrated boundary failure.

The finance assurance matrix includes delegation and revocation rows that can be adapted to brokered access. Read the AI assessment scope and MCP assessment guide to establish which identities and tools an engagement can exercise. Agree a retest after policy, role or connector changes so the record remains tied to the deployed configuration.