AI risk after Black October: from Davos to the runtime

Davos and the development machine run on different clocks

In his World Economic Forum article on technology risk, Marsh’s Andrew George connects AI adoption with cybersecurity, infrastructure resilience and business governance. Those are board-level questions. On a developer’s machine, the same questions become much more specific: which token is available to the agent, which package just updated, and who can stop the next command?

The Global Risks Report 2026 ranks adverse outcomes of AI 30th over two years and fifth over ten years. Cyber insecurity ranks sixth in the two-year outlook. These are perceptions of different categories of global risk over different periods. They do not predict when an individual company will be breached, and they do not say AI-enabled attacks are ten years away.

The Forum’s cybersecurity work already describes the immediate problem. In the Global Cybersecurity Outlook 2026, 87% of respondents identified AI-related vulnerabilities as the fastest-growing cyber risk during 2025; 94% expected AI to drive the most change in cybersecurity in 2026. Those are survey responses, not measured increases of 87% or 94% in vulnerabilities or attacks.

October’s incidents make the implementation question harder to postpone. I use “Black October” here as a description of a difficult month for defenders, not as the name of one campaign or evidence that AI caused every incident. The useful connection to Davos is the gap between a governance commitment and the access a deployed system actually holds.

LiteLLM: a key survived deletion, and an agent held owner access

LiteLLM’s October 23 investigation describes an administrative key committed publicly in opencode.json on May 27. The file was deleted about three hours later, but the key was not revoked. On October 10, an attacker used it to enter an internal Agent Platform deployment.

The platform created pull requests using a GitHub CLI OAuth token belonging to an organization owner. That authority enabled further token theft and an override of branch protection. Stolen identities were then used to trigger and approve the compromised 1.107.0 release on October 21. This is the vendor’s investigation, which supersedes its earlier initial-access hypothesis.

The important distinction is between removing a secret from a file and removing its authority. A deleted configuration can remain in Git history, clones, caches and logs. Once exposed, the key needs revocation at the issuing system; editing the repository cannot accomplish that.

What I would test in another deployment

• Credential purpose: identify the credential used to open pull requests. Check its repository scope, organization permissions and ability to change release workflows.
• Separation of duties: verify that compromising the agent cannot also obtain the identity that approves deployment. Two accounts provide little separation when one environment can retrieve both credentials.
• Revocation: revoke a test credential and attempt the same authorized operation again, including through any cached session. Record when access actually stops.
• Recovery: identify downstream credentials reachable through the compromised account. Rotating the first exposed key does not invalidate credentials already stolen through it.

These checks address the failure modes in the account. They are not a claim that installing one product would have prevented the incident. Our LiteLLM advisory maintains affected-artifact and response details separately from this analysis.

Cursor: the extension could execute before the agent was asked anything

Cursor’s notice identifies malicious Anthropic.claude-code versions 2.1.312 and 2.1.313 for Windows and macOS in its extension marketplace on October 29, approximately 09:27–20:35 UTC. The code collected host details and attempted to establish persistent SSH access. Success depended on host privileges and execution conditions; installation alone does not establish that every remote-access step succeeded.

Cursor describes unauthorized SSH keys and persistence outside the extension itself. Removing the extension can therefore leave artifacts behind. Its notice calls for endpoint and network investigation, isolation where execution or backdoor evidence exists, and credential review from a trusted system. The affected packages were not developed by Anthropic.

This failure occurs at a different boundary from prompt injection. A model does not need to accept malicious instructions for an editor extension to execute code. A policy on MCP tool calls does not automatically mediate the editor’s own processes, filesystem access or network connections.

What the inventory needs to answer

An entry that says “Claude Code approved” is insufficient. The incident question is whether a particular artifact from a particular distribution channel reached a particular host. Keep the extension identifier, version, source, available artifact digest, installation history and endpoint owner. Correlate that inventory with execution telemetry and credentials available to the user session.

Inventory speeds scoping; it does not prevent execution or clean the machine. Endpoint controls, controlled software distribution and incident response remain necessary. Neither a failed tunnel nor the absence of one indicator proves that the host was unaffected. See the Cursor extension advisory for the maintained exposure window and investigation steps.

An incident calendar is not a causal explanation

It is tempting to put every October vulnerability and breach into one AI narrative. That weakens the analysis. A vulnerability discovered with AI, an attacker using AI, and a compromised tool used by AI developers describe different relationships. Each needs its own evidence.

The PHP2Shell and Brotli advisories require product-specific exposure checks and fixes. Their presence in an agent’s dependency tree does not prove exploitation. Likewise, the Binance incident should be followed through its own investigation. It is not evidence that either of the agent-tooling incidents above caused it.

Keep three questions separate in a response: what was installed, what executed, and what the actor could access afterward. Package inventory helps with the first. Endpoint and service logs help with the second. Identity, credential and authorization records are needed for the third.

Translate governance into a testable workflow

The Forum and Capgemini’s AI Agents in Action organizes evaluation around an agent’s role, autonomy, predictability and operating context, with governance proportionate to deployment. The operational checks below are my application of that approach, not a WEF certification scheme.

Take a coding agent assigned to fix a bug and open a pull request. Its task needs repository access, a test environment and permission to propose changes. Whether it can access production secrets, modify release policies or approve its own deployment is a separate design decision. Choosing a more capable model does not require granting those permissions.

1. 01 · InputUntrusted materialRepository files, messages and tool responses can influence the proposed action.
2. 02 · DecisionIndependent access checkEvaluate the caller, tool, arguments, destination and any required approval.
3. 03 · ExecutionConstrained backendUse scoped credentials. Prevent a direct path that bypasses the check.
4. 04 · EvidenceRecorded outcomePreserve the decision and backend result outside the agent’s control.

The decision must happen before the external action. Logging afterward helps investigation but cannot undo a sent email or a published secret. An approval also needs to refer to the operation actually executed: approving one recipient and then allowing the agent to change the address is not meaningful approval.

Run these with synthetic data and an agreed scope. A successful denial in a demo proves only that test case. Repeat the relevant checks when credentials, tools, routing or deployment settings change. Our articles on autonomy and authority and workflow evaluation develop those boundaries further.

Five board priorities, with an owner and an artifact

George’s WEF article recommends AI governance, board oversight of cybersecurity, infrastructure resilience, quantum preparedness and workforce development. The following deliverables translate those priorities into work an organization can review.

1. Give each deployed agent an owner and an access record

Record the business task, operator, host, tools, credentials and permitted destinations. Include local developer tools and integrations introduced through updates. An owner should be able to identify which actions require approval and how to disable the workflow. A procurement list alone will miss software installed directly on a workstation.

2. Report exposure and control coverage to the board

Useful measures include the share of production workflows with a named owner, the number holding organization-wide credentials, and the share whose revocation and bypass tests passed. Give each metric a denominator and a collection date. A rising count of blocked calls may reflect higher usage or a noisy rule; it is not, by itself, evidence that risk fell.

3. Treat tooling changes as changes to production access

Compare installed versions and artifact sources with the approved baseline. Review changes to tool definitions, hooks and outbound destinations. Keep a rollback path and preserve the old artifact for investigation when appropriate. A valid signature establishes a relationship to a signing key; it does not establish that a compromised publisher produced safe code.

4. Put agent credentials in the cryptographic inventory

Record algorithms, issuers, expiry, rotation procedures and dependencies for agent identities and audit signatures. Include them in the organization’s cryptographic migration planning. This does not make post-quantum cryptography a remedy for today’s leaked tokens: credential custody and revocation still need to work now.

5. Train the people who authorize actions

Use a workflow the team already operates. Show how untrusted content can influence a proposed action, which control should reject it and which evidence confirms the rejection. Practice revoking access and resuming work safely. A generic warning about hallucinations will not teach an engineer to recognize an overprivileged release credential.

The staffing constraint matters in Latin America

The Global Cybersecurity Outlook reports that 65% of surveyed organizations in Latin America and the Caribbean lacked critical people or skills to meet their cybersecurity objectives. Only 13% of respondents in the region expressed confidence in their national response to attacks on critical infrastructure. These are respondent perceptions, not a measurement of every organization’s readiness.

For a small security team, requiring manual review of every routine call is unlikely to be sustainable. Start with the workflows that can move money, publish software, alter access or retrieve sensitive records. Give common low-risk actions narrow permissions; reserve human approval for consequential changes and exceptions. Make the escalation route explicit, including when the approver is unavailable.

Automation can reduce repetitive review, but it cannot supply missing ownership. Someone must maintain the permitted scope, investigate unexpected denials and approve policy changes. The Argentine healthcare analysis examines a reported campaign in the region and the operational evidence teams should check.

Where Oktsec fits, and what the deployment still has to do

I build Oktsec, so the product boundary matters in this analysis. Oktsec’s gateway evaluates the messages and tool calls routed through it. Depending on configuration, that includes identity verification, per-agent access rules, tool restrictions and content inspection. Its audit records can preserve the decision made at that boundary.

That does not make the gateway an endpoint response platform or a replacement for the service’s own authorization. An editor extension executing outside the gateway is outside that inspection path. A process that can retrieve backend credentials and connect directly can bypass a gateway unless the deployment prevents that route.

The NIST tenets self-assessment maps the implemented controls and their deployment requirements in more detail. In an Oktsec Assessment, the useful work is to agree the workflow, test those boundaries, preserve reproducible evidence and retest the corrections. A finding should explain the reachable action and its impact, not just attach a score to a configuration file.

The first review should end with evidence

Choose one agent that has meaningful access. Before expanding its scope, ask the team to produce these five artifacts:

1. A deployment inventory: where it runs, what it loads, who owns it and which version was reviewed.
2. An authority map: the credentials it can obtain and the systems each credential can change.
3. A test record: permitted actions, denied actions, attempted bypasses and observed backend results.
4. A response procedure: who can disable the workflow, revoke credentials and investigate reachable systems.
5. A review trigger: the tool, permission or infrastructure changes that require another assessment.

A ten-year outlook helps decide where to invest. These artifacts establish what an agent can do today, and whether the organization can still control it when a credential leaks or a trusted component changes.

Sources and scope

Reviewed October 31, 2026. WEF figures are survey findings and risk perceptions. Incident descriptions are attributed to the vendors’ investigations. The acceptance tests, implementation priorities and product-boundary analysis are Oktsec’s interpretation. Linked Radar advisories may contain later updates.

• Andrew George / WEF: technology risks and opportunities.
• WEF: Global Risks Report 2026, two- and ten-year horizons.
• WEF / Accenture: Global Cybersecurity Outlook 2026, chapter 3.
• WEF / Capgemini: AI Agents in Action, November 2025.
• LiteLLM: investigation of the 1.107.0 release compromise.
• Cursor: malicious Claude Code extension notice.