TL;DR — Infisical secrets management and beyond: Infisical announced a $40M Series B at a $600M valuation on October 27, 2026. Its platform covers application secrets, agent credential brokering, certificates, encryption keys and privileged access. The key distinction is who receives a real credential and who receives limited authority to use one through another component. This guide explains the offerings and trade-offs from documentation; it does not report a live security evaluation.
The $40M funding news, in context
On October 27, 2026, Infisical announced a $40 million Series B at a $600 million valuation, led by Elad Gil. Y Combinator, Gradient Ventures and other investors also participated.
The company says it will invest further in secrets management, certificates, privileged access and Agent Vault. Its announcement also reports more than 1,300 organizations using Infisical and a core project exceeding 30,000 GitHub stars. Those are company-reported figures, not independently audited findings for this article.
The funding is a useful reason to look at the product. It is not evidence that a particular integration is secure, that every feature is included in one subscription or that your applications will recover correctly after a credential change.
The more useful question is: what does Infisical control, who still receives a credential, and what remains your responsibility? This guide follows those boundaries rather than treating the investment as a product recommendation.
What Infisical actually does
Infisical is a security infrastructure platform for developers, applications, machines and AI agents. A secret is a sensitive value used to access another system, such as an API key, database password or token. A machine identity represents software authenticating to a service rather than a person signing in.
Its offerings address several related jobs:
| Capability | The job it addresses |
|---|---|
| Secrets Management | Store, organize and deliver application credentials |
| Agent Vault | Broker authenticated agent requests without handing over the upstream credential |
| Certificate Management | Discover, issue, renew and revoke certificates |
| Key Management Service | Manage cryptographic keys and perform operations with them |
| Privileged Access Management | Govern time-bound access to sensitive infrastructure |
These are different kinds of authority. An application reading a database password, an agent asking a proxy to authenticate a request, and an operator opening an approved administrative session should not be treated as the same event.
The products can be useful together, but a small deployment does not need to adopt every one. Start with a concrete access problem and the people or workloads involved.
Secrets Management: store, scope and deliver credentials
Secrets Management is the part closest to replacing scattered environment files and manually copied credentials. Infisical documents projects, environments and paths for organization, with delivery through its CLI, SDKs, agents, Kubernetes and CI/CD integrations.
For a reader starting from zero, the important sequence is: a workload authenticates, its permissions determine which values it can read, and a delivery mechanism makes those values available where the application expects them. Authentication to the secrets manager is itself part of the design.
Storage, rotation and short-lived credentials
The documentation distinguishes scheduled rotation, which replaces a credential, from dynamic secrets, which are created on demand and revoked when a lease ends. Feature availability depends on the plan and integration; the pricing page places dynamic secrets in Advanced.
That distinction matters when planning recovery. A stored replacement, an issuer accepting that replacement and a running worker actually using it are separate observations.
For an ordinary application that needs a real secret, delivery necessarily gives some component access to the value. Moving it out of Git does not make the process consuming it immune to compromise.
Ask where the credential can appear after delivery: memory, files, environment, deployment settings or logs. The answer depends on your chosen integration and application behavior; this article did not exercise those paths.
Agent Vault: access without handing over upstream credentials
Agent Vault changes the delivery model. The agent gets a time-bound session and sends requests through a credential proxy; the proxy attaches the real upstream credential.
Infisical's current documentation describes four concepts: services identify destinations and their authentication, access bundles group services, sessions grant temporary access to a bundle, and proxies authorize and forward requests. HTTP services can restrict methods and paths.
A session token still grants access
An agent holding a session token has authority through that proxy. A stolen token is therefore not a harmless placeholder: the documented protection is a limited bundle and lifetime, with revocation available.
The operational implication is to scope the session to the actual task. If an agent only needs to read one resource, giving it a broadly privileged bundle creates unnecessary authority even when the underlying API key stays hidden.
This is also why credential hiding does not solve every prompt-injection outcome. An attacker may try to persuade an agent to perform an allowed but harmful action or disclose data returned by an allowed service.
Check the actual traffic path
The docs explicitly note client differences: Node's built-in fetch does not automatically read HTTPS_PROXY by default. They also say requests to unconfigured hosts may pass without credentials or be refused, depending on traffic policy.
Our recommendation is to verify proxy routing, bypass paths and the chosen policy in the real runtime. Do not treat an environment-variable setting as proof of enforced network isolation.
Starkslab's guide to agent control surfaces provides the surrounding questions: where does authority live, what becomes a real external action, and where can someone stop it?
Certificates: manage their lifecycle
A certificate helps another system verify an identity and its associated public key. A certificate authority, or CA, signs certificates; private PKI means an organization operates its own trust structure for internal uses.
Infisical Certificate Management advertises discovery and inventory, issuance, renewal and revocation. It can operate a private CA hierarchy or integrate supported external CAs, with enrollment methods including ACME, SCEP and EST.
For an operator, the recurring problem is often less about creating a certificate than ensuring the replacement reaches the right service before expiry.
Here is the evaluation boundary we recommend: distinguish issued, deployed and accepted by the intended clients. Those are separate checkpoints, even if a dashboard presents a successful renewal.
A fictional internal service could receive a new certificate while a process still serves the old one. A client could also reject the new chain because its trust configuration differs. These are scenarios to test, not failures observed in Infisical during this research.
Certificate lifecycle automation also does not, by itself, establish that every client distrusts a compromised external CA. Trust decisions still need a client-specific verification plan.
KMS: request an operation with a key
A cryptographic key used to encrypt data or sign an artifact is different from an API key presented as a login credential.
Infisical KMS documents encryption, decryption, signing, verification and other operations using managed key material. It also documents key import/export and integrations including KMIP clients, Kubernetes and Sigstore Cosign.
The useful distinction is requesting an operation versus receiving the key material. A workload may only need permission to sign a specific kind of payload, rather than a copy of a signing key.
Do not interpret “the application does not receive the key” as an unconditional statement that every key is non-exportable. Check the actual key settings, permissions, algorithms and deployment.
Our evaluation questions would include: who can decrypt, who can change permissions, who can export, and what happens when a key is rotated or unavailable? This is an acceptance plan; none of those operations was run for the article.
Privileged Access: govern human and operational sessions
Privileged access is administrative or otherwise sensitive access to infrastructure. It is often a human workflow: someone needs to investigate a database, connect to a server or operate a cloud account.
Infisical PAM describes gateways, scoped and time-bound access, approval controls and session auditing. Its published resource list includes databases, SSH, Windows RDP and cloud identities, with capabilities varying by resource type.
That makes it a different problem from putting a database password into an application's startup environment. The desired outcome is an attributable access window with a defined scope and end.
A proposed evaluation should test the boundaries: what an approver actually grants, when access ends, which activity is recorded and which behavior is outside the recording's coverage.
Session recordings also deserve their own retention and access policy. Recordings can contain sensitive operational information even when credentials are masked.
For a solo operator, the question is whether you need a governed administrative workflow now or whether a smaller access arrangement is sufficient. Product breadth is not a reason to add operational complexity without a clear requirement.
Cloud, self-hosting and licensing
Infisical offers managed and self-hosted deployment paths. Its self-hosted Enterprise documentation makes clear that running the software yourself does not unlock every paid feature.
That guide describes a purchased license, regular and offline license modes, and activation on the instance. It says an expired license leaves the instance running while disabling Enterprise-edition features.
Decide who operates the dependency
For a self-hosted evaluation, we would assign explicit owners for upgrades, backups, restoration, monitoring, network policy and emergency access. Hosting it yourself changes who performs that work; it does not remove the work.
For managed hosting, ask which responsibilities stay with the provider and which remain with your organization. Identity configuration, upstream credential scope and application recovery still need owners.
Review source availability and licensing per component and feature. A project's open-source description is not a substitute for checking the terms and entitlements you plan to use.
We did not deploy either option, restore a backup or test licensing failure behavior. Any choice should include a realistic recovery exercise before it becomes a critical dependency.
What it costs—and what to count
The pricing page retained on October 27, 2026 lists the following Secrets Management headline plans:
| Plan | Published headline |
|---|---|
| Free | $0; five identities and unlimited projects |
| Pro | $20 per identity per month, billed annually |
| Advanced | $40 per identity per month, billed annually |
| Enterprise | Custom commercial terms |
An identity includes a human or a machine that authenticates to Infisical. The billing FAQ says the five free identities belong to Free only: after upgrading, every identity in the organization is charged.
A fictional cost calculation
Suppose a team has three human users and four machine identities. At the listed annual-billing rates, seven identities would imply $140/month on Pro or $280/month on Advanced.
That is arithmetic from a fictional identity count, not a quote. It excludes other products, add-ons, tax, deployment-specific terms and any requirements that change the chosen plan.
Infisical says its products are available individually or in combination, and that self-hosted pricing differs from Cloud. Do not apply the Secrets Management identity price to the entire platform.
The retained page did not provide a complete commercial extract for every product tab. Confirm current Agent Vault, certificate, KMS and PAM terms, along with rate limits, audit retention and required features, before budgeting.
One fictional application, several different controls
Consider Harbor Tasks, a fictional small application with a web service, queue worker, nightly job and coding agent. An operator sometimes needs database access during incidents.
This is an original planning example. It is not an Infisical deployment, test result or customer story.
Give each workload the access it needs
The web service and worker need credentials for normal application operations. An appropriate starting question for Secrets Management is which identities should receive which values in development, staging and production.
The nightly job needs its own delivery and verification record. Sharing a repository or image with the web application does not tell us whether it uses the same configuration or reads a value at the same time.
For the coding agent, we would first ask whether direct possession of production credentials is necessary at all. An Agent Vault evaluation could instead define a narrowly scoped service bundle for the task.
A separate operator-access requirement might lead to evaluating PAM. An expiring internal certificate could lead to evaluating certificate management. These are additional requirements, not assumptions that every small application should buy the full suite.
Write down authority before configuration
| Component | Proposed access boundary | Evidence to seek in an evaluation |
|---|---|---|
| Web service | Its own environment and required values | Intended identity can read the right values; other environments are denied |
| Queue worker | Explicit worker permissions | A named job succeeds after an authorized change |
| Nightly job | Its actual scheduled configuration | The executed job uses the intended configuration |
| Coding agent | Task-scoped brokered session | Allowed requests work; forbidden requests and expired sessions fail |
| Operator | Time-bound administrative access if needed | Approval scope, expiry and audit evidence match the request |
These are proposed observations, not completed checks. Record both positive and negative cases, and keep real secrets out of the evidence.
If a database credential is compromised, the recovery plan still needs issuer replacement, consumer updates, verification and retirement of the old credential. The platform can supply parts of that workflow; the operator still has to establish what actually happened.
What to verify before relying on it
Before choosing features, define the result you want to be able to demonstrate. The distinction in Infisical's agent documentation gives one useful starting point: did the workload receive a real secret, or did it receive temporary authority to ask a proxy to act?
The following is our recommended acceptance checklist, derived from the boundaries above. It is not a test suite we executed.
Identity and access
Use a non-production identity with only the scope needed for one workload. Check an intended read and an unintended environment or path.
For a brokered session, try one allowed request and one explicitly forbidden request. Record the permission model and failure result; a successful request alone says little about the boundary.
Document the bootstrap credential or identity mechanism too. Moving a secret into a manager is incomplete if an equally powerful bootstrap credential is left exposed elsewhere.
Credential and session lifecycle
Choose an authorized credential change and name each consumer that should adopt it. Record when the issuer accepts the new value, when each workload uses it and when the old value stops working.
For agent access, test expiry and revocation with a harmless request. Measure the observed cutoff rather than assuming it is immediate.
If your design relies on a proxy, include each actual HTTP client, browser or subprocess involved. Ask what happens when it does not follow the expected route.
Operations and recovery
Specify the expected behavior when the manager, proxy or upstream service is unavailable. Decide what stops, what can safely retry and what requires a person.
Check which logs can connect an identity, request and result without disclosing secrets. Establish who can inspect those logs and for how long.
For self-hosting, include restoration and license dependencies in the acceptance plan. For certificates or KMS, include the specific deployed consumer and trust or cryptographic operation you intend to rely on.
Starkslab's source-to-operating-map guide offers a way to keep these dependencies and unknowns visible. A source read helps plan validation; observed results are still needed before claiming runtime behavior.
Who should evaluate it, and the limits of this article
Infisical is worth evaluating when secret copies, machine identities, certificate renewals or temporary access have become difficult to manage consistently. The documented suite offers several ways to address those jobs, while Agent Vault introduces a different credential boundary for agents.
It may be more platform than a small workflow currently needs. Start by identifying one access problem that your existing arrangement does not solve, then evaluate the smallest relevant capability.
What this article verified
As of October 27, 2026, we reviewed the official funding announcement, product documentation and pages, pricing, and self-hosted Enterprise guidance. Eight primary pages were retained for the article; the funding and commercial claims remain attributed to Infisical.
We did not create a tenant, deploy a proxy, rotate a live credential, issue a certificate, run a KMS operation or record a privileged session. This is a documentation-based explainer, not a security audit, hands-on benchmark or production endorsement.
The fictional application and acceptance checklist are planning aids. No complete cross-vendor comparison or claim of relative novelty is made.
A useful next step is to choose one non-production workload, write down the access it needs and the evidence that would establish success, and obtain authorization for that bounded evaluation.