← All insights
Governance1 min read

A Security Incident Is Usually a Procurement Failure

When an agent breaches an enterprise platform, the root cause is rarely hygiene — it's a buying process that still treats agentic software like SaaS.


An autonomous agent recently spent about twenty dollars and walked into an enterprise AI platform used across one of the largest firms in the world: writable access to data, user accounts, and the system prompts governing how the platform reasons, all through an endpoint that never asked who was calling. The post-mortem said the right things — authenticate endpoints, sanitize inputs, treat AI like production. All true. None of it is the story.

The hygiene was never the hard part

The team had excellent engineers, and yet 22 of 200 endpoints shipped with no authentication. That isn't one person skipping a checklist on a Friday; that's a pattern. The real gap is that no one asked whether the software was the right shape for a world where agents, not humans clicking through screens, would be calling it.

Agents break the buying sequence

For fifteen years enterprise software was bought in one order: strategy at the top, procurement, security review, IT, and developers last. That works for SaaS because SaaS is bounded. An agent is not. A single task crosses the CRM, support tickets, contracts, and wikis — each with its own permissions and audit trail that has to exist as code. With agents, implementation isn't downstream of the strategy. It is the strategy. Put your developers last and you commit capital to a plan whose viability was never tested.

Three questions before you sign

  • Identity. Does the platform tell a human user apart from an agent, and bound each accordingly?
  • Audit. Can you prove what the system did on someone's behalf, not just what a user did?
  • Control. Can someone revoke an agent from a console in five minutes — no ticket, no deploy?

If you can't answer those, the exposure isn't an IT problem. It's a board-level liability you're carrying unpriced.