THINK BIG

One. The Phenomenon: Some Attacks Reached Privileged Access in Less Than Three Hours

On October 21, 2026, Microsoft reported that the threat actor it tracks as Storm-0940 had used the agentic AI penetration-testing framework ARTEX to automate attacks as early as September that year. In multiple instances, the time from initial targeting to privileged access to an organization's cloud infrastructure was less than 3 hours.[1]

The report describes abuse of existing application access and credentials. It also cautions that an affected application's presence or successful attacker authentication does not itself establish data access or exfiltration.[1] Attack attempts, successful authentication, privileged access, and data exfiltration should therefore be distinguished.

A separate development provides context for the developer ecosystem. The Linux Foundation announced the formation of the Agentic AI Foundation (AAIF) on December 9, 2025, with founding project contributions including Model Context Protocol (MCP), goose, and AGENTS.md.[2] This is background on open-source collaboration and governance, rather than an event coinciding with the attack disclosure.

Skills also need a concrete definition. The official anthropics/skills repository on GitHub describes Skills in its README as folders containing instructions, scripts, and resources.[4] Our recommendation is to inventory skill contents, execution environments, and the accounts and permissions actually used as separate items.

Two. Perspectives: What the Official Documents Emphasize

Microsoft: inspect application identities and subsequent activity.

Microsoft recommends reviewing service-principal sign-ins, unexpected credential or privilege changes, and applying least privilege.[1] We recommend including application permissions and activity records in deployment acceptance checks.

The Linux Foundation: support collaboration through open governance.

The AAIF announcement emphasizes a neutral, open environment and the development of tools, standards, and community collaboration.[2] Our interpretation is that foundation governance and deployment security reviews need separate treatment: project membership alone does not establish security certification for an individual package.

NIST: do not grant implicit trust based on network location.

In Zero Trust Architecture, the US National Institute of Standards and Technology (NIST) explains that assets and accounts should not receive implicit trust solely because of their physical or network location or ownership. Authentication and authorization precede establishment of a session to an enterprise resource.[3]

The documents have different purposes. We recommend turning their guidance into a deployment checklist: which identity executes, which resources it can access, who approves that access, and how activity is recorded.

Three. Our First-Hand Lessons (Anonymized): Make Permissions Verifiable

When discussing an AI agent deployment, we start with two questions:

"What can it do to my data?" "Who approves and maintains it, and who handles an incident?"

The following presents the team's practical views and recommendations without identifying clients. It is not evidence of customer outcomes or industry statistics.

Lesson one: map permissions before choosing tools

We advocate starting with an inventory containing at least four fields: tool or skill name, data and operation scope, user or execution identity, and owner.

Break down the scope further: which files it may read, whether it may modify or delete them, whether it may call external services, and whether it may send data. Compare intended use with actual settings before deciding which capabilities to retain or change.

Lesson two: document approval, maintenance, and response responsibilities

We recommend recording an approver, maintainer, and incident contact for each tool, together with a way to disable it or revoke access.

For operations that write, delete, or send important data externally, agree before deployment whether human review is required and who performs it. A named owner should have explicit duties and authority.

Lesson three: define the period, calculation, and threshold for each metric

We recommend recording three metrics: usage count, the proportion of answers usable without editing, and the number of authorized tasks actually completed.

Agree on the measurement period, calculation method, and acceptance threshold before a trial. If results fall short, inspect data quality, permissions, workflow design, and usage records. Avoid judging success solely by a fixed number of days or whether a metric grows.

Four. Our Recommendations: Three Things First

1. Start an inventory using existing documents

List the AI skills, tools, and extensions in use, including employee-installed items. Define the scope and identify the system administrators whose help is needed before scheduling the work and assigning staff.

Alongside names, record data and operation scope, execution identity, and ownership. Go beyond asking whether AI is in use.

2. Review data access, operation permissions, and provenance individually

• Unclear provenance or authorization: pause new access grants and sensitive-data input while the owner investigates; restrict connections or disable the tool if necessary.
• Clear purpose but excessive permissions: establish required functions in a test environment, then reduce permissions and verify the workflow.
• Clear purpose, permissions, and ownership: retain records and agree on a review date and incident procedure.

If an incident is suspected, preserve records and carry out necessary containment in parallel. A routine inventory should not substitute for an incident investigation.

3. Document ownership and access revocation

Assign an owner to each retained tool. Record contact details, who can revoke access, and the order of response actions. If related tools share an owner, list exactly which tools that arrangement covers.