Infisical’s October 27, 2026 funding announcement puts fresh attention on Agent Vault. The company says it raised a $40 million Series B and plans to increase its focus on the product. For an evaluation, the first useful question is which Agent Vault implementation and documentation you are using. The funding announcement is not a new launch notice for every feature described under that name.
Infisical’s October 27 Series B announcement
Separate the current product from the earlier implementation
The current platform page labels Agent Vault a preview. Its FAQ distinguishes the commercial version from the earlier open-source credential broker: a standalone MIT-licensed binary with its own credential store. The FAQ says that earlier project is not actively maintained. Treat this as the vendor’s current support description, rather than inferring support status from a repository’s latest activity alone.
The older April 22 launch post now carries an update explaining that it covers the research preview and directs readers to the product documentation. Its historical setup instructions should therefore not be silently combined with current commercial-product instructions.
Earlier research-preview post and its update
Record the access boundary you intend to test
For the current product, Infisical describes access bundles containing permitted services, rules narrowed by HTTP method or path, time-bound sessions and request logging. A forward proxy applies credentials to outgoing requests. The page says running agents lose access within 60 seconds of a session ending. These are vendor descriptions, not results independently measured for this article.
Current Agent Vault platform page and FAQ
A useful evaluation record has six fields: product or build, documentation date, allowed destination, permitted operation, session lifetime and observed result. Record the proxy deployment separately. This makes it possible to explain exactly which configuration produced a success or denial, rather than treating a product name as the entire security boundary.
Use a disposable service for an access exercise
For a hypothetical trial, use an organization-owned test API with fabricated records and a credential limited to that environment. Define the intended task as reading a status endpoint. Write down the expected result for that read, a write request outside the intended scope and a request after session expiry. Use harmless requests against the test environment only.
First confirm that the allowed read succeeds through the configured route. Then check whether the disallowed operation is refused and whether its denial appears in the relevant logs. A successful authenticated read tests a different requirement from a correctly denied write. Keep both observations instead of recording only that the integration works.
For the expiry exercise, record the configured end time and timestamps of subsequent test requests. Compare the observation with the behavior documented for the implementation you selected. If a request succeeds unexpectedly, preserve the route, session and timing evidence before drawing a conclusion. This article has not run that trial or verified a particular revocation latency.
Make the pilot decision from the recorded result
Include every request path the intended agent can use in the evaluation plan. If some clients use another route, record that as an untested part of the workflow. An isolated proxy trial cannot establish the behavior of a separate integration or the wider network configuration.
Before expanding a pilot, resolve unexpected successes, missing denials and undocumented assumptions with the responsible team. Keep the tested configuration and its limits with the result. USA and India teams can share this worksheet while checking their own deployment and access requirements; this guide does not establish country-specific availability or compliance.