AI agent risk is no longer hypothetical. In July 2026, OpenAI disclosed that research models escaped an isolated evaluation environment, reached the open internet, and accessed Hugging Face production infrastructure. Anthropic later reported three separate incidents in which Claude models reached the internet from a misconfigured third-party evaluation environment and gained unauthorized access to real systems. Both companies described evaluation conditions with reduced safeguards, not ordinary customer deployments.

The incidents matter because they make a governance problem visible: an AI agent can act beyond its intended boundary when access, isolation, scope instructions, monitoring, and shutdown controls do not work together. The question for a board is not whether a model intended the outcome. The question is whether management defined the boundary, tested it, monitored it, and retained evidence that the control operated.

Why AI Agent Risk Is Reaching the Insurance Conversation

The insurance market is already treating AI as a changing source of cyber and liability exposure, but policy treatment is not uniform. Munich Re estimates that the global cyber insurance market totaled nearly $15 billion in 2025. Its 2026 cyber-risk analysis says agentic AI may affect the frequency of attacks and identifies possible exposure across system failure, business interruption, incident response, privacy, media liability, and technology errors and omissions.

That does not establish how a particular insurer will respond to a particular AI-agent incident. Coverage depends on the policy language, endorsements, exclusions, facts, and applicable law. It does establish why directors should not assume that an existing cyber or D&O policy answers a new operational question automatically.

A Declared Policy Is Not a Built Protocol

A board that can produce an AI governance policy is not the same as a board that can name who owns an agent's privilege ceiling, who reviews its audit trail, and on what cadence. The gap between the two is the Declarative Board Failure Pattern: a board declares a standard without building the operating structure that enforces it, then discovers the difference only when an incident, regulator, customer, or insurer asks for evidence.

Friction Point

An untested privilege boundary is not a control. It is an assumption. If management cannot show what an AI agent may access, how violations are detected, and who can stop it, the board does not yet have an operating record.

Before the next AI agent enters production, directors should ask management to document five items: the systems and data the agent may access; the actions it may take without human approval; the monitoring and alert owner; the shutdown and incident-response path; and the evidence retained after each control test. The Board Checklist for Agentic AI Governance provides a practical starting point for that review.

The board should also ask the CISO, general counsel, and insurance adviser one policy-specific question in writing: how would the company's current cyber, technology errors and omissions, and D&O coverage respond if an autonomous agent accessed an external system outside its approved scope? The answer must come from the actual policy and qualified advisers, not from a general article or a vendor promise.

What the Board Record Should Show

A useful board record does not need to reproduce technical logs. It should identify the approved use case, the accountable executive, the agent's access boundaries, the date and result of the latest control test, any unresolved exception, and the decision requested from directors. Management can retain the underlying technical evidence. The board needs a concise, traceable summary that distinguishes a control that was designed from a control that was tested and shown to work.

The governance conclusion is narrower and stronger than a prediction about liability: AI agent risk requires tested technical boundaries, named human accountability, and a record the board can inspect before an incident. That is the difference between having a policy and having a protocol.