HomeToolsCategoriesModel watchFuelGoldInsightsDailyHow we vetContact
Submit a tool

November 7, 2026 · Security

Your agent has the keys

We gave software our passwords years before we gave it a security model. Agents inherited both, and nobody updated the policy.

Two stories this week, sitting next to each other and not talking.

Security researchers found hundreds of AI-driven hacking tools sitting publicly exposed on the open web — not sophisticated, not targeted, just left running where anyone could reach them. Separately, Palo Alto Networks was reported to be in talks to buy an AI agent security startup called Clutch for around $500 million.

Read together, they describe a market forming around a problem most companies have already created but not yet noticed: we handed agents credentials, and we are only now starting to think about what that means.

Keys and a phone left beside an open laptop on a desk
The credential is the product. Everything else is convenience.

The thing nobody put on the risk register

A traditional integration asks for an API key with a scope. It can read orders, or it can write inventory, and the scope tells you which. An agent asks for something different: it asks to act on your behalf, across systems, with judgement.

In practice that means a service account with broad permissions, an email inbox, a browser session, and — in the setups we have seen — a shared password vault entry that nobody remembers creating.

The failure mode is not dramatic. It is a supplier getting a price confirmation that was never approved. A purchase order raised against the wrong SKU. A forwarded thread that leaks a buyer's margin to a competitor. Every one of those is a normal Tuesday in export ops, and every one of them becomes harder to attribute once an agent is in the loop.

The question is not whether an agent can be trusted. It is whether you can tell, six weeks later, what it did and on whose authority.

Four things to settle before the next agent goes live

This is not a call to ban agents. It is a call to treat their credentials the way you treat a new employee's — with a defined scope, a probation period, and an offboarding process.

Read-only until proven otherwise. Start every agent with read access and add write permissions one workflow at a time. Most agents sold as "autonomous" deliver 80% of their value reading: extracting, summarising, comparing, drafting. Writing is where the risk lives.

One agent, one identity. A shared service account means the audit log cannot tell you which workflow did what. Give each agent its own identity, even if it costs a little administration. The log is the only thing that will save you in a dispute.

Scope by system, not by convenience. The temptation is to grant broad access because scoping takes a week. That week is the cheapest security work you will ever buy. An agent that can read the ERP but not the bank should be the default, not a compromise.

Write the offboarding before the onboarding. What happens when the vendor changes their pricing, gets acquired, or the tool is abandoned? If revoking the agent takes three meetings, you do not have a security posture, you have a hope.

A server room door with an access control panel
Offboarding is a security feature. Most contracts do not mention it.

Why $500 million is the right order of magnitude

It is tempting to read the Clutch deal as hype. We think it is closer to arithmetic.

An agent security product solves a problem that every company adopting agents will eventually have, that no company can solve well in-house, and that becomes more expensive the longer it is ignored. That is a durable market, and the price reflects the fact that the buyer — a network security company — understands exactly how much of the enterprise budget moves when a new class of identity appears.

The uncomfortable implication for a sourcing desk is that this cost is coming to you. Not as a line item called "agent security", but as an enterprise tier, a compliance requirement from a customer, or a delay in a deal because your security questionnaire has a hole in it.

The teams that handle this well will not be the ones with the strictest policy. They will be the ones with the clearest inventory: which agents exist, what they can touch, who approved them, and how to turn them off.

The mundane version of the fix

We keep coming back to the same conclusion with agents, and it is never the exciting one. The work is not a model problem, it is a bookkeeping problem.

Write down every agent you have running, even the ones in a spreadsheet. For each one: the systems it touches, the permissions it holds, the person who approved it, and the date it was last reviewed. Review the list quarterly, the way you review your supplier list.

It takes an afternoon. It will feel disproportionate to the risk right up until the first time you need it — at which point it becomes the most valuable document in the company.

The alternative is what most teams have now: a handful of agents with keys to the building, and nobody who can say exactly how many.


We add a security note to every agent-capable tool in the library: what it can access, whether it supports scoped credentials, and whether it produces an audit log you can actually read. Tools that cannot answer those three questions are marked accordingly.