What you need to know
- $435 million across 12 financings, April to September 2026, for enterprise AI agent security and governance companies. Nine of the 12 were aimed squarely at making agents safe enough to run inside a business.
- Zenity raised a $125 million Series C led by Norwest, announced in early August 2026 (3–4 August). Qumra Capital, SoftBank Vision Fund 2, Hitachi Ventures and LG Technology Ventures came in as new investors, alongside existing backers Vertex Ventures, Third Point Ventures, DTCP and Intel Capital.
- AIR came out of stealth on 1 September 2026 with $50 million in seed funding, structured as two rounds — $10 million led by Sequoia and $40 million led by Greenoaks.
- Arga Labs raised $10 million led by General Catalyst to build digital twins of enterprise software so agents can be tested before they touch production.
- The demand signal is uncomfortable. IDC and Lenovo research found 88% of enterprises with agent initiatives never ship to production; for every 33 AI proof-of-concepts launched, only four graduated.
- The counterweight is real too. Gartner has forecast that more than 40% of agentic AI projects will be cancelled by the end of 2027. This is a funding wave, not a proven category.
Read the cheque sizes on their own and you learn something fairly ordinary: a fashionable category attracted capital. The more interesting reading is what the nine companies have in common. They are not selling agents. They are selling the conditions under which somebody else's agents are allowed to run — identity, permission, containment, testing, evidence. That is a very specific product shape, and it implies a very specific kind of engineer.
What the money actually bought
The funded companies fall into three broad groups, and the distinction matters because they need different people.
| Company | Round | Category | What it does |
|---|---|---|---|
| Zenity | $125M Series C, led by Norwest, early August 2026 | Governance and posture management | Security and governance for agents across enterprise platforms; more than 230 employees, R&D in Tel Aviv, go-to-market and operations run from New York |
| AIR | $50M seed in two rounds — $10M led by Sequoia, $40M led by Greenoaks; out of stealth 1 September 2026 | Runtime firewall | Inline firewall for AI agents that discovers and vets the skills, plugins and MCP servers agents use; reports more than 20 customers |
| Arga Labs | $10M led by General Catalyst | Pre-production testing | Digital twins of enterprise software — Salesforce, Workday, email clients — so agents can be tested safely before production deployment |
Zenity's investor list is worth a second look. Qumra Capital, SoftBank Vision Fund 2, Hitachi Ventures and LG Technology Ventures joining alongside Vertex Ventures, Third Point Ventures, DTCP and Intel Capital is not a purely financial syndicate. Hitachi and LG are industrial operators with their own agent deployment problems; strategic investors on a security round usually means the thesis is being tested internally as well as backed externally. The stated use of funds — global expansion, particularly into Europe and Asia Pacific, plus expanding Zenity Labs — puts both of our markets directly in the path of the hiring.
AIR's shape is different and, for an engineer, more legible. An inline firewall that discovers and vets the skills, plugins and MCP servers an agent uses is, in plain terms, supply chain security for tools. An agent with a tool-calling loop is a program that loads and executes third-party capability at runtime, often described in natural language, often installed by whoever thought it looked useful. That is a dependency graph nobody is auditing. AIR reports more than 20 customers with strongest demand from regulated industries such as financial services and pharmaceuticals, which is exactly where you would expect a tool supply chain question to surface first.
Arga Labs is the quietest of the three and the most instructive. Building digital twins of Salesforce, Workday and email clients means accepting that you cannot safely test an agent against production and that mocks are not faithful enough to catch the failures that matter. If that premise is correct, a great deal of current agent testing practice is theatre.
Nine rounds in five months is a signal about investor conviction, not about product-market fit. Not one of these companies has a publicly verifiable track record of preventing a named enterprise incident, because the category is too young to have one. Treat the funding as evidence that serious people think the problem is real — which it is — and not as evidence that any particular product solves it.
The demand signal, honestly stated
The number doing most of the work in every pitch deck in this category is 88%: IDC and Lenovo research found that 88% of enterprises with agent initiatives never ship to production. The same body of research offers a second framing that is arguably starker — for every 33 AI proof-of-concepts a company launched, only four graduated to production, or roughly 12%.
That is a genuine finding and it is also being quoted without its neighbours. Lenovo's CIO Playbook, built on IDC research across 800 European and Middle Eastern organisations, found that 46% of AI proof-of-concepts had already progressed into production. A Wakefield Research survey conducted for Teradata found that 78% of enterprises have at least one agent pilot running, yet only 14% have scaled an agent to organisation-wide use.
Most of these numbers are not in contradiction, and anyone presenting them as though one debunks the others is being careless. They largely measure different points in the lifecycle. One pair genuinely does conflict, though, and it is worth naming rather than glossing over: the 12% graduation rate above and the 46% graduation rate below measure the same bar — proof-of-concept to production — and disagree by nearly a factor of four. Different samples, different instruments, different definitions of “production”. Treat that spread as itself a finding about how soft this evidence base is. “Has a pilot” is a low bar and 78% clear it. “Moved a proof-of-concept into some production use” is a middle bar and roughly 46% clear it in the European and Middle Eastern sample. “Runs agents at organisation-wide scale” is a high bar and 14% clear it. The 88% figure describes enterprises whose agent initiatives specifically never reached production at all. Different denominators, different questions, different answers.
What survives all four numbers is the shape of the problem rather than its exact size: a large gap between starting and finishing, and a long tail of projects stuck somewhere in between. Our read of McKinsey's 2026 State of AI data on build-versus-buy for agents found the same pattern from a different angle. The interesting question is not how big the failure rate is, it is what the projects are dying of — and the answer, consistently, is that nobody could sign off the risk.
When you quote the 88% figure in a proposal — and you will, because it is persuasive — put the 46% and the 14% next to it in the same paragraph. A senior stakeholder who later discovers you cited only the worst number will discount everything else you said. Showing that you understand why three surveys disagree is a stronger signal of judgement than the scary statistic was.
The skills being bought
Here is the part with consequences for your week. Nine funded companies, all hiring at once, all needing roughly the same profile. That profile did not exist as a job title two years ago, which means the supply side has not caught up and probably will not for a while.
It is worth being concrete about what the work actually is, because “AI security” as a phrase is broad enough to be useless.
| Skill | What the work is | What proof looks like |
|---|---|---|
| Permission boundary design | Deciding which tools an agent may call, under what conditions, with what scope — and writing that down as something enforceable rather than a prompt instruction | A published permission model for a real agent, with the rejected designs explained |
| Blast-radius containment | Sandboxed execution, reversible actions, dry-run modes, rate limits that fail closed rather than open | A post-mortem of an agent action that went wrong and the containment that limited it |
| Agent identity and credentials | Giving an agent its own identity rather than borrowing a human's token; short-lived credentials, delegation chains, revocation | An identity design that survives the question “who did this, the agent or the person?” |
| Tool and plugin vetting | Auditing MCP servers, plugins and skills as a supply chain: provenance, permissions requested, update behaviour | A written review of MCP servers you actually assessed, including ones you rejected |
| Human-in-the-loop escalation | Designing the queue, the approval thresholds, and the interface a reviewer sees — including what happens when nobody responds | A review queue you built, with measured approval latency and override rates |
| Cost and token governance | Overrun caps, per-agent budgets, runaway-loop detection, and attributing spend to the agent that caused it — our guide to building the control plane that enforces them walks through the ledger and quota design | Before-and-after spend numbers from a cap you introduced |
| Audit trails and evidence | Producing a record that satisfies an auditor: what the agent did, why, on whose authority, and what it was allowed to do at the time | An audit schema that a compliance function signed off on |
If that table reads like security engineering rather than machine learning, that is because it largely is. The scarce combination is not “knows transformers” plus “knows IAM”. It is someone who understands why an agent's plan step is a trust boundary, and who can then design the enforcement that makes it one. We have written the practical version of two of these rows: designing tool permission boundaries for agents and building the human review queue an agent escalates into. If you want the measurement discipline that sits underneath all of it, setting a reliability target and building the qualification harness is the one hiring managers probe hardest.
Every article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →The incumbents are building what the startups are raising for
On 2 September 2026, Boomi announced its Agent Control Plane: centralised agent identity, rate limits, token-overrun caps and human approval gates for high-risk transactional actions, deployable across public cloud, a customer's own VPC or on-premises. Read that feature list next to the skills table above and the overlap is close to total.
This cuts two ways for anyone deciding what to learn. The pessimistic reading is that integration platforms already sitting inside the enterprise will absorb agent governance as a feature, and the startups raising against it are competing with a free checkbox. The optimistic reading — and the more likely one on current evidence — is that an incumbent shipping the same primitives is the strongest available confirmation that the primitives are correct. Identity, rate limits, overrun caps and approval gates are now converging as the standard vocabulary from two directions at once.
Either way, the engineer wins. If the startups take the market, they are hiring. If the platforms take it, they are hiring for the same thing. The concepts are portable in a way that a specific vendor's product knowledge is not. We saw a similar convergence when OpenAI moved to managed agents and sunset Agent Builder — the platform absorbed the orchestration layer, and the durable skill turned out to be the reasoning about boundaries, not the tool.
A theme that recurs in conversations with Verified Builders in both markets: the agent pilot was never blocked on model quality. It was blocked for months because nobody could answer what happens if it emails the wrong customer, and there was no way to prove it could not.
— Paraphrased from Verified Builder conversations · India and the UKIndia and the UK: same demand, different route
Zenity directing its new funding at Europe and Asia Pacific is the most direct statement in this whole cluster that both our markets are in scope. AIR's strongest demand coming from financial services and pharmaceuticals sharpens it further, because that is a precise description of where the work sits on both sides.
In Britain, that means financial services, insurance and pharmaceutical organisations, and it means meeting the question through existing sector regulators rather than a dedicated statute. The United Kingdom has no AI Act. Agent governance obligations arrive through the bodies that already exist — the Information Commissioner's Office on personal data and automated decision-making, the Financial Conduct Authority on conduct and operational resilience. Practically, that means your evidence has to satisfy an established regulatory conversation rather than a new compliance regime, which is in some ways harder: the auditors already know what good looks like in adjacent domains and will expect the same standard.
In India, the same demand arrives through global capability centres and BFSI work, with the Digital Personal Data Protection framework's substantive compliance obligations landing on 13 May 2027. Worth stating plainly, because it is routinely got wrong: DPDP's cross-border provision is a negative-list model. Transfers are broadly permitted unless the government notifies a country as restricted, and none has been notified. If someone tells you agent architecture in India is constrained by a data transfer bar, they are describing a rule that does not exist.
The practical consequence for a builder is that an Indian engineer working on a GCC BFSI agent deployment and a British engineer working on an insurer's agent rollout are solving the same technical problem with different paperwork attached. The identity model, the permission boundaries, the audit schema and the escalation queue are the same artefacts. That portability is unusual and it is worth exploiting. If you want the wider picture of which roles this opens up, our breakdown of where the AI hiring gap actually sits covers it across both markets.
The honest risk
Gartner has predicted that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. That is a forecast, not an observation, and forecasts about emerging categories have a poor record. But it is a reasonable forecast, and anybody redirecting a career towards agent security should hold it in mind rather than dismiss it.
If it lands, some of these nine companies do not have a market, and a specialism that looked scarce in 2026 looks crowded in 2028. That risk is real. What reduces it considerably is that the underlying disciplines are not new. Least privilege, supply chain vetting, credential lifecycle, containment, audit evidence and human escalation are decades-old security practice applied to a novel surface. An engineer who learns them through agents has learned something that outlives the agent framework, the vendor, and quite possibly the category name. Compare that with someone who learned one orchestration library very well.
The other thing that reduces the risk is that safety work tends to survive a downturn better than capability work. When budgets tighten, the projects that get cancelled are the speculative ones; the ones that continue are the ones already in production, and those are precisely the ones that need controls. The direction of travel on enterprise frontier safeguards points the same way.
What to do this month
If any of the seven skills in that table describes work you have actually done, the useful move is not to wait for a job posting that uses the right words. It is to make the work findable now, while the demand curve is ahead of the supply curve.
Concretely: pick one agent you have built or operated, and write up its permission model — what it was allowed to do, what you deliberately refused it, and what you would change. Add the containment design and what happened the first time something went wrong. Publish the MCP servers or plugins you assessed and rejected, with reasons. None of that requires permission from an employer if you write it at the level of design rather than internal detail, and all of it is more persuasive than any list of technologies.
Then make it visible. Nine funded companies expanding into Europe and Asia Pacific are looking for this profile right now, and they are looking in the places where engineers have published evidence rather than the places where they have listed keywords.