AI Compliance & Cyber Brief — November 3, 2026

A large industrial company just certified the governance wrapper around its agent platform: risk assessment, human oversight, continuous monitoring, and permissions checked every time an agent runs. The certificate covers the management process, not the accuracy of any model, which is exactly what ISO 42001 is designed to evidence. The question for any leader is what, specifically, your own AI governance would put in front of a customer who asked for proof.

Post or podcast segment: 'What a certificate certifies.' Walk through Mitsubishi's scope, then contrast it with the common misread that 'ISO 42001 certified' means 'the AI is safe.' Readiness is a repeatable method, not a feeling, and this is a place where translating between the auditor and the CEO earns its keep. Workshop version: have each leader write a two-sentence scope statement for their own AI use.

The twist is not a smarter exploit. It is that an unprotected model endpoint, AI gateway or MCP server is now something attackers go looking for, and the owner pays for whatever the borrowed model is told to do. In the captured instructions the model was told to treat reading API keys as routine work and to run unattended for up to 100,000 steps. An unexplained jump in an AI provider bill is now a security signal. This is one captured tool from one honeypot, so its reach is unknown, but the exposure it relies on is ordinary configuration.

Post: 'Your AI bill is a security log.' Ask who watches inference spend and whether anyone would notice a tenfold jump on a Tuesday. Workshop exercise: list every place a model endpoint, gateway or MCP server can be reached, and who authenticates each one. This is the human layer again: the test endpoint somebody stood up and forgot. DoCRA-flavored angle (my framing, not new DoCRA writing): reasonable safeguards include knowing what you have exposed.

Nothing was hacked. Employees wanted a tool their market does not officially sell and ran a one-line command from a reseller. The result is an agent with full machine access whose every prompt, file and secret passes through a third party, with the sandbox off and telemetry disabled. There is no evidence of abuse so far, which is the point: the exposure is in the architecture. The tool is genuine; the plumbing is not yours. Where employees cannot get an approved tool, they find an unapproved one.

Post: 'The real tool, the wrong pipe.' Give the three config checks Symantec lists (changed base URL, sandbox mode set to full access, API tokens set outside an approved deployment) and pair them with the human-layer point: people route around access gaps, so a sanctioned path beats a ban. Workshop: audit one laptop's agent configuration together in ten minutes.

Several October findings sit outside the model itself: per an industry roundup, a backdoored agent extension in a lab test, a child session that skipped a hook confirmation, and an unescaped login URL that ran code. Some fixes shipped without a CVE, so a conventional vulnerability scan may not show them. The control that holds up is inventory: which agent tools, extensions and settings exist on developer machines, and who reviews changes to them. Several findings are proofs of concept and vendors dispute the severity of some.

Post for non-technical leaders: 'No CVE, still a risk.' Your scanner reports what vendors label a vulnerability; agent configuration risk often carries another label. Translate 'trust boundary' for the room as 'whose code runs with my employee's permissions.' DoCRA-flavored angle (my framing): reasonable security starts with knowing what you have.