You can't govern an agent you can't name

It's a standup, ten minutes in, when someone from ops asks the question that empties the room: how many AI agents are running in production right now?

Nobody has the number. Someone guesses "a few." Support mentions the bot they stood up to draft refund replies, and maybe a second one tagging tickets, they're not sure. Finance has something that reconciles invoices, but nobody can say whether that's an agent or a scheduled script with an API key. The engineering lead remembers the Slack bot can open pull requests now.

Three people start typing into the same doc, and by the end of the meeting it has more question marks than rows.

That standup is the reason a Barcelona startup called NeuralTrust just raised twenty million dollars.

The funding is only the market signal

On June 18, NeuralTrust announced a $20M seed round led by Alstin Capital, with VentureFriends, Seaya, Kibo Ventures, Banc Sabadell, EA Ventures Plug and Play Fund, Finaves, the European Innovation Council, and Spain's State Research Agency also named in the release.

The customer list is the part worth reading closely. NeuralTrust says its customers include AirEuropa, Abanca, Iberia, Banc Sabadell, plus other banks, airlines, energy companies, and government agencies. This is not the toy-agent corner of the market. These are organizations where an autonomous workflow can touch regulated systems, customer records, and operational risk.

The product shape tells the story. NeuralTrust describes three pieces: TrustGate, a gateway that brokers LLM, MCP, and tool calls through an enforcement point; TrustGuard, runtime security that detects and stops threats across platforms and endpoints; and TrustLens, posture management to identify every agent in the enterprise and track how it behaves inside and outside the perimeter.

Read that order again. Two of those ideas assume the company knows where its agents are. The posture layer admits the company probably does not.

That is the tell. Agent security is becoming an infrastructure category because agents now sprawl across models, tools, identities, SaaS products, and endpoints faster than anyone is writing them down. As NeuralTrust co-founder and CEO Joan Vendrell put it in the release: "AI agents are now part of enterprise operations, but the controls protecting them are still catching up."

Here is the part that matters for everyone who is not a global bank: you cannot govern a thing you cannot name. Count the swarm before you control it.

What you are actually missing is a roster

A gateway is an enforcement decision. Runtime detection is a monitoring decision. Both depend on a prior, dumber, more uncomfortable fact: a list.

Most teams skip straight to "which tool do we buy" because shopping feels like progress and list-making feels like homework. But if you buy the platform first, you will route the three agents you remembered through it and leave the four you forgot running in the dark.

So start one step earlier. The artifact is a single page. Call it the agent swarm census. Eight columns, one row per agent:

Scroll sideways to see all 8 columns.

Agent name	Owner	Identity	Connected tools	Allowed actions	Enforcement point	Evidence trail	Shutdown path
Refund-draft bot	Support lead	Service account	Help desk, payments read access	Draft reply, propose refund, no execution	None yet	Help desk audit log	Rotate service key
Invoice reconciler	Finance ops	Shared API key	Accounting system, internal database	Match records, flag exceptions, write to staging	None yet	Database write log	Disable schedule, revoke key
PR assistant	Engineering lead	GitHub App token	GitHub, CI	Open PR, comment, cannot merge	Branch protection	GitHub audit log	Revoke App installation

The columns are not arbitrary. Each one answers a question you will otherwise get asked during an incident, when guessing costs the most.

Owner means there is a human whose weekend gets ruined if this agent misbehaves, so it has to be a name, not a department. Identity is how the agent authenticates. If the answer is "a shared API key in someone's .env," the census has already found a problem.

Connected tools and allowed actions are different columns because access and authority are different things. A support bot with read-only payment access is not the same animal as one that can issue refunds, even though both "connect to payments."

Enforcement point is the honest column. For a lot of first-pass rows it will say "none yet," and that blank is the finding. Evidence trail asks whether you could reconstruct what the agent did last Tuesday. Shutdown path asks who can make it stop without inventing the procedure during an incident.

If you can fill every column for an agent, you understand it. If a cell is blank, you have just found your next task.

The census changes the purchase decision

Filling the page sounds like busywork until you see what it sorts. Once the rows exist, every agent falls into one of four piles, and the pile tells you what to do next.

The agents that touch money or customer accounts, like the refund bot or anything with write access to a system of record, are where a single chokepoint earns its cost. The census does not tell you which gateway to buy. It tells you which three rows out of thirty actually justify one, which is the question a sales demo cannot answer for you.

Agents that run unattended are the ones runtime detection is for. The tell is not the hour of day. It is that nothing in the evidence-trail column would show the agent went sideways until someone noticed the damage. The census flags which rows run with no human in the loop, so you are not paying to monitor the PR helper that only wakes up when a developer pushes code.

Then there is the third pile, and it is usually bigger than anyone admits: shadow automation. The agent someone spun up in a weekend, wired to a personal API key, that nobody put on the books. The census does not fix these. It makes them visible, which is the entire point, because you cannot govern what you never counted.

And the fourth pile is the one teams forget exists: agents you should turn off. Not every agent that got built deserves to keep running. Some were experiments. Some duplicate each other. Some have access nobody can justify anymore. The shutdown-path column makes retirement a real option instead of a vague intention.

That is where the census connects to the later control work. Once you know which rows matter, you can run an agent firewall in observe mode for the agents that need a chokepoint, or test an AI identity revocation drill for the agents whose shutdown path is only theoretical. But the census comes first. Otherwise you are securing the agents you remembered, not the agents you have.

Bounded action is turning into infrastructure

The census assumes a principle that is hardening into infrastructure: an agent should only be able to do what someone explicitly authorized, and that authorization should be checkable after the fact.

You can see the same principle in standards work. In April, the FIDO Alliance announced agentic authentication and payments work focused on verifiable user instructions, agent authentication, and trusted delegation for commerce. The useful detail is not the spec acronym. It is the worldview behind the work: when an agent acts for a person, a service should be able to verify who authorized the action, under what conditions, and within what limits.

That is the standards-body version of the allowed-actions and evidence-trail columns. You do not need to wait for the standards process to finish before you write down what an agent is allowed to inspect, propose, change, spend, or escalate.

The first useful version does not have to be elegant. It has to be specific enough that someone can make an enforcement decision from it.

Your first week

Do not try to census the whole swarm. You will stall on completeness and ship nothing.

Pick one agent, preferably the support bot or the back-office automation that touches customers, money, code, or production data. Fill all eight columns for that one row. You will hit a blank within minutes, probably in enforcement or shutdown, and that blank is your real starting point.

Then make one decision about that agent: does it need a gateway in front of it, a revoke drill to prove you can cut it off, or quiet retirement because nobody can explain why it is still running?

Bring that one agent workflow to your next planning meeting and build the first census row in the room. One honest row beats a tool you bought before you knew what it was protecting.

The twenty-million-dollar version of this problem has a sales team. Yours has a spreadsheet and an afternoon. Start there.

If you want a structured way to map the first row, start with AI workflow controls or the AI workflow security review worksheet. The useful question is not whether your company has an AI governance program. It is whether you can name one agent, one owner, one identity, one evidence trail, and one shutdown path before the swarm grows again.