Daily Reading for 2026-09-23
Daily Reading for 2026-09-23
Simon Willison’s LLM Tooling
Three releases in Simon Willison’s LLM ecosystem land together. The core llm CLI reaches 0.36; llm-anthropic 0.29 adds support for the just-released Claude Opus 5.5; and llm-typesafe 0.1a0 wraps TypeSafe AI’s “Jev” decision model, which answers yes/no, choice and scoring questions with typed probabilistic outputs via simple CLI flags. Together they show the plugin architecture as a fast adapter layer: when a new model or paradigm appears, a small plugin makes it usable from the terminal within days, keeping experimentation cheap.
Watch for:
- Plugin-per-model adapters keeping pace with frontier releases
- The LLM CLI as a common interface across vendors
- Decision/typed-output models (Jev) exposed through familiar CLI flags
- Rapid support for new models such as Opus 5.5 within days
- An ecosystem pattern that lowers switching costs
Wardley signals:
-
Components: the llm CLI; llm-anthropic; llm-typesafe; Claude Opus 5.5; TypeSafe AI’s Jev; API keys; the plugin architecture.
-
Evolution stage: the llm CLI and its plugin model are Product (stable interfaces, growing ecosystem); individual model APIs are Product moving to Commodity; Jev/decision models are Genesis/Custom.
-
Doctrine: “Bias towards open,” “use appropriate tools,” “think small teams,” and “bias towards action” (ship a plugin fast); “focus on the outcome.”
-
Climatic patterns: “Efficiency enables innovation (Componentisation effect)”; “Higher order systems create new sources of value”; “Evolution of communication mechanisms can increase the speed of evolution.”
-
Diffusion markers: a plugin ecosystem, fast vendor-model adoption, standardised CLI conventions, and low switching costs driving broad experimentation.
wardley-beta %% Q1 Who are the users? Developers who drive models from the terminal. %% Q2 What are their needs? One stable interface across many models and paradigms. %% Q3 What capabilities are required? A core CLI, model plugins and typed-output support. %% Q4 What components are used? llm CLI, llm-anthropic, llm-typesafe, Claude Opus 5.5, Jev decision models. %% Q5 How mature are those components? The CLI and its plugins are Product; Opus is Product; Jev is Custom. %% Q6 Who manages them and how? Simon Willison maintains the CLI and plugins; vendors ship the models. anchor cliUser [0.92, 0.95] component llmCli [0.62, 0.72] component llmAnthropicPlugin [0.55, 0.6] component llmTypesafePlugin [0.35, 0.5] component opusModel [0.6, 0.45] component jevDecisionModel [0.3, 0.38] llmCli -> cliUser llmAnthropicPlugin -> llmCli llmTypesafePlugin -> llmCli opusModel -> llmAnthropicPlugin jevDecisionModel -> llmTypesafePlugin
EvilTokens Device Code Phishing
Microsoft’s Threat Intelligence traces EvilTokens, a phishing-as-a-service platform that industrialized device-code phishing. Emerging in February 2026, it abused the legitimate OAuth device authorization flow to steal tokens and compromise more than 12,000 inboxes across 10,000 organizations. The kit bundles AI-assisted lure writing, 44 themed templates, and Microsoft Graph reconnaissance, letting low-skill criminals run business email compromise at scale. Microsoft’s Digital Crimes Unit coordinated an infrastructure takedown and published Defender detections, but token theft persists through malicious inbox rules that survive password resets.
Watch for:
- Device-code phishing kits resold as subscription PhaaS
- AI-generated lures and automated mailbox triage
- Malicious inbox rules and token persistence surviving password resets
- Microsoft Graph reconnaissance mapping org structure and permissions
- Coordinated infrastructure takedowns versus rapid kit re-deployment
Wardley signals:
-
Components: EvilTokens phish kit; the OAuth device authorization flow; Storm-2992; stolen access tokens; Microsoft Graph API; malicious inbox rules; Microsoft Defender detections; Microsoft Digital Crimes Unit.
-
Evolution stage: the OAuth device-code flow is Commodity (a standard protocol); the EvilTokens kit is Product (a rented, templated service); MFA is Commodity; AI-assisted lure generation is Custom/Product.
-
Doctrine: Microsoft “listens to its ecosystem” and shares intel; defenders need “use standards” (spoof protection, mail-flow rules) and “manage failure” via layered controls, favoring “effectiveness over efficiency.”
-
Climatic patterns: “Everything evolves through supply and demand competition” (crimeware industrialising); “Commoditisation <> Centralisation”; “Competitors actions will change the game”; “Efficiency enables innovation (Componentisation effect).”
-
Diffusion markers: 44 lure themes; 12,000 inboxes across 10,000 organizations; a subscription PhaaS market; copy-cat token-theft kits appearing as MFA adoption spreads.
-
Unmasking EvilTokens: Getting to the root of device code phishing
wardley-beta %% Q1 Who are the users? Identity admins and SOC analysts defending Microsoft 365 estates. %% Q2 What are their needs? Keep accounts from being taken over without a password prompt. %% Q3 What capabilities are required? A legitimate auth flow, threat intel, detections and takedown. %% Q4 What components are used? Device-code flow, EvilTokens kit, AI lures, Graph recon, inbox-rule persistence, Defender detections. %% Q5 How mature are those components? OAuth device flow and MFA are Commodity; the kit is Product; AI lures and Graph recon are Custom. %% Q6 Who manages them and how? Microsoft runs identity/detections and the DCU; Storm-2992 runs the PhaaS kit. anchor identityDefender [0.9, 0.95] component deviceCodeFlow [0.85, 0.72] component evilTokensKit [0.55, 0.6] component aiLureGeneration [0.4, 0.5] component graphRecon [0.32, 0.45] component inboxRulePersistence [0.3, 0.4] component defenderDetections [0.6, 0.55] deviceCodeFlow -> identityDefender evilTokensKit -> deviceCodeFlow aiLureGeneration -> evilTokensKit graphRecon -> evilTokensKit inboxRulePersistence -> evilTokensKit defenderDetections -> identityDefender
SideCopy APT Campaign
Trellix reports that SideCopy, a long-running APT, has widened its targeting to academic institutions using MSHTA-driven, fileless RAT delivery. The campaign leans on a Windows living-off-the-land binary, mshta.exe, to execute remote payloads without writing conventional malware to disk, blunting signature-based defenses. For a technical reader the lesson is that commodity OS utilities remain a durable evasion channel, and that research and education networks — often under-resourced relative to the data they hold — are now in the crosshairs.
Watch for:
- Academic and research-sector targeting by state-linked APTs
- MSHTA (mshta.exe) and other LOLBins used as fileless loaders
- Remote payload fetch that avoids on-disk artifacts
- Reuse of SideCopy tradecraft across regional campaigns
Wardley signals:
-
Components: SideCopy APT; mshta.exe (MSHTA); a fileless RAT; remote payload servers; phishing/archive lures; academic targets; AV/EDR controls.
-
Evolution stage: mshta.exe and Windows script hosts are Commodity (built in, ubiquitous); the APT’s bespoke tooling is Custom (repeatedly refined); commodity RATs are Product.
-
Doctrine: a defender miss on “manage inertia” (relying on disk signatures) and “use appropriate tools” (script-host controls, allow-listing); attackers show “bias towards action.”
-
Climatic patterns: “Everything evolves through supply and demand competition”; “Characteristics change as components evolve”; “Competitors actions will change the game”; “No choice over evolution (Red Queen).”
-
Diffusion markers: a known APT widening victim sectors; reuse of commodity OS binaries; TTPs shared across regional campaigns; published IOCs.
-
🚩 SideCopy APT Expands to Academic Targets Using MSHTA-Driven Fileless RAT Delivery
wardley-beta %% Q1 Who are the users? Threat hunters and IT teams in academia, government and research. %% Q2 What are their needs? Detect and contain intrusions that leave little on disk. %% Q3 What capabilities are required? Endpoint detection, script-host control and threat intel. %% Q4 What components are used? MSHTA, a fileless RAT, remote payload hosting, APT tooling, academic targeting, endpoint detection. %% Q5 How mature are those components? mshta.exe and remote hosting are Commodity; the RAT is Product; the APT tooling is Custom. %% Q6 Who manages them and how? SideCopy operates the campaign; defenders run EDR and hunting teams. anchor threatHunter [0.9, 0.94] component mshtaLoader [0.8, 0.68] component filelessRat [0.5, 0.58] component remotePayloadHosting [0.72, 0.5] component aptTooling [0.3, 0.44] component academicTargeting [0.28, 0.38] component endpointDetection [0.55, 0.55] filelessRat -> mshtaLoader mshtaLoader -> threatHunter remotePayloadHosting -> filelessRat aptTooling -> filelessRat academicTargeting -> aptTooling endpointDetection -> threatHunter
Rapuncel Infostealer Campaign
LastPass’s TIME team and Delphos document Rapuncel, an infostealer spread through fake GitHub organizations impersonating at least 40 companies, including a fraudulent LastPass Authenticator. The payload carried a Microsoft-attested kernel driver and a clean VirusTotal score, then terminated 145 antivirus and EDR processes from kernel mode to harvest credentials from browsers, wallets, Discord, Steam, Telegram and Windows Credential Manager. Delphos links the loader to the Cruciferra PUROSANGUE crypter. The report stresses this was opportunistic brand abuse outside LastPass channels, and that the campaign long predates the lure they caught.
Watch for:
- Attested, signed kernel drivers weaponized to kill EDR
- Brand impersonation via fake GitHub organizations and release pages
- Crypter-as-a-service packages (Cruciferra PUROSANGUE) lowering skill barriers
- Infostealers targeting browser, wallet and messaging credential stores
- Trust signals (code signing, clean VT scores) used as attacker cover
Wardley signals:
-
Components: Rapuncel infostealer; Cruciferra PUROSANGUE crypter; Microsoft Windows Hardware Compatibility Publisher attestation; kernel-mode EDR killers; fake GitHub orgs; Windows Credential Manager; LastPass TIME team; Delphos Labs.
-
Evolution stage: code-signing/attestation is Commodity but abused; infostealers and crypters are Product (kit-based, sold, reused); kernel EDR-kill techniques are Custom trending to Product.
-
Doctrine: “Use standards” (verify official distribution channels); “manage failure” and “effectiveness over efficiency” via defense-in-depth; a defender miss on “know the details” (trusting signing alone).
-
Climatic patterns: “Everything evolves through supply and demand competition” (crimeware-as-a-service); “Success breeds inertia” (reliance on EDR and signing); “Competitors actions will change the game”; “Efficiency enables innovation.”
-
Diffusion markers: 40+ impersonated brands; multiple parallel operators; documented prior campaigns (BoryptGrab); crypter reuse across unrelated campaigns; open calls for coordinated disclosure.
-
Fake LastPass Authenticator Installer Bypasses Antivirus and EDR
wardley-beta %% Q1 Who are the users? Endpoint security teams and the software brands being impersonated. %% Q2 What are their needs? Stop credential theft and protect brand trust in distribution. %% Q3 What capabilities are required? Code-signing trust, EDR protection and verified distribution. %% Q4 What components are used? Attested kernel driver, EDR killers, Rapuncel stealer, PUROSANGUE crypter, fake GitHub orgs, credential stores. %% Q5 How mature are those components? Attestation, GitHub and credential stores are Commodity; stealer and crypter are Product; kernel EDR-kill is Custom. %% Q6 Who manages them and how? MaaS operators run the kit; LastPass TIME and Delphos investigate; Microsoft signs drivers. anchor endpointDefender [0.9, 0.95] component attestedKernelDriver [0.78, 0.7] component edrKillers [0.35, 0.55] component rapuncelStealer [0.55, 0.6] component purosangueCrypter [0.5, 0.48] component fakeGithubOrgs [0.75, 0.52] component credentialStores [0.82, 0.42] attestedKernelDriver -> edrKillers edrKillers -> rapuncelStealer rapuncelStealer -> endpointDefender purosangueCrypter -> rapuncelStealer fakeGithubOrgs -> rapuncelStealer credentialStores -> rapuncelStealer
FBI Impersonation Scams
An FBI IC3 public-service announcement updates a 2022 alert on criminals impersonating law enforcement and government officials. Between January 2025 and July 2026 the IC3 logged nearly 61,000 complaints with losses above $1.6 billion. Scammers spoof agency phone numbers and credentials, keep victims isolated on the line, and demand payment via prepaid cards, wires, cryptocurrency or kiosk cash. Common pretexts include fake arrest threats, missed jury duty, expiring licenses, and targeting of ethnic communities and international students. This is social engineering at industrial scale rather than a technical exploit.
Watch for:
- Voice and number spoofing that mimics agencies such as IC3 itself
- Isolation tactics that keep victims from consulting family or banks
- Irreversible payment rails (crypto kiosks, gift cards, wires)
- Tailored pretexts aimed at practitioners, students and immigrant communities
- Complaint volume and loss trends as a barometer of scam industrialization
Wardley signals:
-
Components: IC3; spoofed caller-ID and email; impersonated agencies; prepaid cards, wires and cryptocurrency kiosks; victim PII; public-awareness programs.
-
Evolution stage: telephony/number spoofing and payment rails are Commodity; the impersonation playbook is Product (scripted, repeatable); social-engineering tradecraft is Custom.
-
Doctrine: “Know your users” and “common language” for public awareness; “listen to your ecosystem” (IC3 reporting); a defender miss on “manage inertia” when consumers trust caller ID.
-
Climatic patterns: “Everything evolves through supply and demand competition” (fraud industrialising); “Higher order systems create new sources of value”; “Most competitors have poor situational awareness” (unaware victims).
-
Diffusion markers: ~61,000 complaints and $1.6B in losses; localized pretext variants; multi-language targeting; recurring PSA updates and standardised reporting.
-
FBI Warns of Widespread Law Enforcement and Government Impersonation Fraud
wardley-beta %% Q1 Who are the users? The general public, especially practitioners, students and immigrant communities. %% Q2 What are their needs? Avoid losing money or PII to someone claiming to be an official. %% Q3 What capabilities are required? Trustworthy caller identity, payment safeguards and public awareness. %% Q4 What components are used? Spoofed caller-ID, the impersonation playbook, payment rails, victim PII, awareness programs. %% Q5 How mature are those components? Spoofing and payment rails are Commodity; the playbook is Product; awareness is Product. %% Q6 Who manages them and how? The FBI/IC3 warns and collects reports; scammers run scripted campaigns. anchor citizenUser [0.92, 0.95] component spoofedCallerId [0.8, 0.72] component impersonationPlaybook [0.55, 0.62] component paymentRails [0.85, 0.5] component victimPii [0.7, 0.4] component awarenessPrograms [0.5, 0.55] spoofedCallerId -> citizenUser impersonationPlaybook -> citizenUser paymentRails -> impersonationPlaybook victimPii -> impersonationPlaybook awarenessPrograms -> citizenUser
OWASP 25th & ThreatModCon
Adam Shostack’s post previews November’s San Francisco security calendar: OWASP’s 25th anniversary (Nov 2–6) and ThreatModCon (Nov 6–7). He will present on how the EU’s Cyber Resilience Act forces cloud-scale engineering change, arguing it is not merely a legal matter but a rework of process and documentation for anyone selling into Europe. There is also a fireside chat on a decade of threat modeling and a three-day Threat Modeling Intensive Using AI course, framed around how AI shifts the practice. It is a signal of how compliance and AI are reshaping security training.
Watch for:
- The EU Cyber Resilience Act driving engineering and documentation change
- Threat modeling adapting to AI-assisted and AI-generated code
- Community events (OWASP 25th, ThreatModCon) as diffusion hubs
- Training shifting toward AI-complemented security practice
- A second edition of Shostack’s Threat Modeling book
Wardley signals:
-
Components: OWASP; ThreatModCon; the EU Cyber Resilience Act; threat modeling; Threat Modeling Intensive Using AI; Shostack & Associates; Global AppSec USA.
-
Evolution stage: OWASP and threat modeling are Product (established, taught, standardised); the CRA is Custom/emerging regulation; AI-augmented threat modeling is Genesis/Custom.
-
Doctrine: “Listen to your ecosystem”; “a bias towards open” (OWASP’s free sharing); “provide purpose, mastery & autonomy”; and the co-evolution of practice with activity.
-
Climatic patterns: “Components can co-evolve (practice with activity)”; “Change is not always linear”; “A ‘war’ (point of industrialisation) causes organisations to evolve” (CRA-driven change).
-
Diffusion markers: 25 years of OWASP, conference and training circuits, a new book edition, and certification-style intensives.
-
Heading to San Francisco and ready to party for OWASP’s 25th
wardley-beta %% Q1 Who are the users? Application-security practitioners and threat-modeling teams. %% Q2 What are their needs? Keep design-time security skills current as AI and regulation shift. %% Q3 What capabilities are required? A community, a threat-modeling practice, training and regulatory awareness. %% Q4 What components are used? OWASP community, threat modeling, ThreatModCon, the Cyber Resilience Act, AI threat-modeling training. %% Q5 How mature are those components? OWASP, threat modeling and conferences are Product; the CRA and AI training are Custom. %% Q6 Who manages them and how? OWASP and Shostack & Associates run the community, events and training. anchor securityPractitioner [0.92, 0.94] component owaspCommunity [0.62, 0.72] component threatModeling [0.55, 0.62] component threatModCon [0.5, 0.5] component cyberResilienceAct [0.35, 0.45] component aiThreatModelingTraining [0.3, 0.4] owaspCommunity -> securityPractitioner threatModeling -> securityPractitioner threatModCon -> owaspCommunity cyberResilienceAct -> threatModeling aiThreatModelingTraining -> threatModeling
Attacker vs. Defender AI Advantage
Daniel Miessler argues the decisive AI asymmetry is not model capability but organizational speed. Attackers move from idea to implementation in hours; most defenders are embedded in change control, approvals and bureaucracy, so the same step takes weeks, months or years. Framing it through the Theory of Constraints, he locates the bottleneck in process and politics rather than technology, and notes that AI only makes the gap more visible. Some friction is legitimate, but red will keep outpacing blue until defenders redesign how work gets authorized and shipped.
Watch for:
- Organizational latency, not tooling, as the defender bottleneck
- Theory of Constraints applied to security operations
- Change control and governance as speed limiters
- AI compressing attacker idea-to-exploit time
- Pressure to rethink security process design
Wardley signals:
-
Components: AI attack tooling; enterprise change control; security operations; governance and bureaucracy; the Theory of Constraints; red and blue teams.
-
Evolution stage: AI tooling is Custom/Product (fast-moving, differential); change control and governance are Commodity (entrenched, ritualised); security operations is Product.
-
Doctrine: direct hits on “move fast,” “bias towards action,” “strategy is iterative,” and “distribute power and decision making”; a miss on “optimise flow” is the core thesis.
-
Climatic patterns: “Evolution of communication mechanisms can increase the speed of evolution overall”; “Increased stability of lower order systems increases agility & speed of re-combination”; “Success breeds inertia”; “You cannot measure evolution over time.”
-
Diffusion markers: a widely repeated “red moves faster than blue” meme; AI adoption spreading through attack tooling faster than defensive process change.
wardley-beta %% Q1 Who are the users? Security leaders and defenders in large organisations. %% Q2 What are their needs? Match attacker speed without abandoning governance. %% Q3 What capabilities are required? Fast change, AI attack awareness and redesigned process flow. %% Q4 What components are used? AI attack tooling, enterprise change control, security ops, governance, theory of constraints. %% Q5 How mature are those components? Change control and governance are Commodity; security ops and AI tooling are Product/Custom. %% Q6 Who manages them and how? Red teams act fast; blue teams are bound by corporate process. anchor securityLeader [0.92, 0.95] component aiAttackTooling [0.4, 0.62] component securityOps [0.6, 0.6] component enterpriseChangeControl [0.78, 0.5] component governanceProcess [0.72, 0.42] component theoryOfConstraints [0.3, 0.48] aiAttackTooling -> securityLeader securityOps -> securityLeader enterpriseChangeControl -> securityOps governanceProcess -> enterpriseChangeControl theoryOfConstraints -> securityLeader
Agentic Engineering BoF
Simon Willison is hosting an evening Birds-of-a-Feather session in San Francisco on 14 October with Jesse Vincent, aimed at people building unusual things with and on top of coding agents. Framed as an “agentic show-and-tell,” it favors early, unfinished and odd experiments over product pitches, with an informal flowing conversation rather than presentations. The post is short but tells you where the frontier community is gathering: shared vocabulary, peer learning, and celebrating the weirdness of agentic development before the market sorts it out.
Watch for:
- Community BOFs and show-and-tells as agentic-engineering diffusion
- Emphasis on early and unfinished work over product pitches
- Coding-agent tooling and workflows as a distinct discipline
- In-person meetups complementing fast-moving online discourse
Wardley signals:
-
Components: coding agents; agentic engineering practice; Birds-of-a-Feather meetups; Simon Willison; Jesse Vincent; the San Francisco builder community.
-
Evolution stage: agentic engineering is Genesis/Custom (new, poorly understood, differential); the meetup format is Commodity; coding-agent products are Product.
-
Doctrine: “Bias towards open,” “listen to your ecosystem,” “provide purpose, mastery & autonomy,” and “bias towards action” all fit a peer-learning, experimentation-oriented gathering.
-
Climatic patterns: “The less evolved something is the more uncertain it becomes”; “Components can co-evolve (practice with activity)”; “Higher order systems create new sources of value.”
-
Diffusion markers: informal BOFs, shared vocabulary, rapid community formation, and celebration of unfinished experiments — classic early-diffusion signals.
-
SF October 14th: A Birds of a Feather Session on Agentic Engineering
wardley-beta %% Q1 Who are the users? Builders experimenting with coding agents. %% Q2 What are their needs? Compare notes and learn from peers early, before markets form. %% Q3 What capabilities are required? Working agents, a shared practice and a gathering to exchange ideas. %% Q4 What components are used? Coding agents, agentic practice, a community BOF, a shared vocabulary. %% Q5 How mature are those components? Meetups are Commodity; coding agents are Product; agentic practice and vocabulary are Custom. %% Q6 Who manages them and how? Simon Willison and Jesse Vincent convene the community in San Francisco. anchor agentBuilder [0.92, 0.94] component codingAgents [0.5, 0.68] component agenticPractice [0.3, 0.6] component communityBof [0.75, 0.5] component sharedVocabulary [0.28, 0.42] codingAgents -> agentBuilder agenticPractice -> agentBuilder communityBof -> agenticPractice sharedVocabulary -> agenticPractice
Frontier Model Releases & Price War
Simon Willison rounds up a burst of frontier releases — Anthropic’s Claude Opus 5.5 and OpenAI’s GPT-6 Sol and Luna — landing within hours of each other. The headline is price: GPT-6 Luna is $0.10/$0.50 per million tokens, half the cost of the already-cheap GPT-5.6 Luna, and Opus 5.5 cuts input and output 20% with a 60% cache-read reduction. His pelican-on-a-bicycle test shows the 6 family rendering in muted tones, while Opus 5.5 at max thinking over-thought until it failed to respond. It is a snapshot of a fast-moving price war among top-tier models.
Watch for:
- Rapid, same-day frontier releases from competing labs
- Aggressive price cuts and cache-read economics for agentic workloads
- Model-comparison folklore (the pelican test) as informal benchmarking
- Reasoning-effort settings trading cost against reliability
- The next tier (Sonnet/Haiku) and its price competitiveness
Wardley signals:
-
Components: Claude Opus 5.5; GPT-6 Sol and Luna; Grok 4.7; the GPT-5.6 family; token pricing; cache-read pricing; reasoning/effort levels; the pelican test; the LLM CLI.
-
Evolution stage: frontier chat models are Product (competing feature sets, price cuts); underlying inference is trending to Commodity (utility pricing); the pelican test is a Custom/folk benchmark.
-
Doctrine: “Focus on the outcome” and “think fast, inexpensive, restrained and elegant”; “bias towards action”; “bias towards data” via price-performance tables.
-
Climatic patterns: “Everything evolves through supply and demand competition”; “Efficiency does not mean a reduced spend (Jevons paradox)”; “Shifts from product to utility tend to demonstrate a punctuated equilibrium”; “Competitors actions will change the game.”
-
Diffusion markers: prices halving within a generation, same-day multi-lab releases, shared comparison rituals, and a public price war signalling commoditisation.
wardley-beta %% Q1 Who are the users? Application developers and AI engineers choosing models. %% Q2 What are their needs? The best capability per dollar, especially for agentic loops. %% Q3 What capabilities are required? Model access, transparent pricing and effort controls. %% Q4 What components are used? Frontier models, token pricing, cache-read pricing, reasoning effort, the pelican benchmark. %% Q5 How mature are those components? Token and cache pricing are Commodity; frontier models are Product; effort control and the benchmark are Custom. %% Q6 Who manages them and how? Anthropic, OpenAI and xAI compete on price; developers benchmark informally. anchor aiDeveloper [0.92, 0.95] component frontierModels [0.6, 0.7] component tokenPricing [0.82, 0.6] component cacheReadPricing [0.78, 0.5] component reasoningEffort [0.35, 0.45] component pelicanBenchmark [0.25, 0.38] frontierModels -> aiDeveloper tokenPricing -> frontierModels cacheReadPricing -> tokenPricing reasoningEffort -> frontierModels pelicanBenchmark -> frontierModels
AI-Generated Content Detection
A short Simon Willison “Quoting” post relays @therealcornpop’s take on spotting AI-written scripts for TikTok and YouTube. The tell is not the usual AI-isms — the “it’s not X, it’s Y” cadence, the rule of three, the broken staccato rhythm — but the absence of a real point of view: no definitive voice, no opinions about the subject. It is a compact, useful observation about authenticity as a signal, and a reminder that as generated text floods social platforms, human judgment and voice become the scarce differentiators.
Watch for:
- Voice and opinion as the durable authenticity signal
- AI-ism heuristics (rule of three, “not X but Y”) becoming unreliable
- Detection shifting from pattern-matching to judgment
- Platform incentives rewarding volume over substance
- Editorial and audience trust effects of synthetic media
Wardley signals:
-
Components: AI text generation; social video scripts (TikTok/YouTube); AI-ism heuristics; human voice and authenticity; audience judgment.
-
Evolution stage: generative text tooling is Product/Commodity (cheap, ubiquitous); AI-detection heuristics are Genesis/Custom (unreliable, contested); “voice” is an unmodelled human quality.
-
Doctrine: “Know your users”; “bias towards data” is a miss here — pattern heuristics fail and judgment is needed; “challenge assumptions” about AI tells.
-
Climatic patterns: “Everything evolves through supply and demand competition”; “Efficiency does not mean a reduced spend (Jevons paradox)” (cheaper generation yields more content); “Higher order systems create new sources of value” (authenticity).
-
Diffusion markers: ubiquitous AI-written scripts; a shared folk taxonomy of AI-isms; community debate over detection; platforms awash in synthetic content.
wardley-beta %% Q1 Who are the users? Content creators and the audiences watching their videos. %% Q2 What are their needs? Tell authentic, opinionated work from synthetic filler. %% Q3 What capabilities are required? Generation tooling, publishing channels and a sense of voice. %% Q4 What components are used? AI text generation, social video scripts, AI-ism heuristics, human voice. %% Q5 How mature are those components? Generation is Commodity; video scripts are Product; heuristics and voice are Custom. %% Q6 Who manages them and how? Platforms host the content; audiences judge authenticity. anchor contentCreator [0.92, 0.95] component aiTextGeneration [0.8, 0.7] component socialVideoScripts [0.6, 0.6] component aiIsmHeuristics [0.3, 0.45] component humanVoice [0.22, 0.38] aiTextGeneration -> contentCreator socialVideoScripts -> contentCreator aiIsmHeuristics -> socialVideoScripts humanVoice -> contentCreator
Gemini CLI for Bug Bounty Research
A YesWeHack guide argues that Gemini CLI’s value in bug bounty is not as an attacker but as a cheap, fast, large-context analyst. Because Gemini’s safety filters refuse active exploitation, the workflow feeds it captured proxy traffic (Burp/Caido over MCP) and source code instead, letting its huge context window reason over a whole repository or session at once. The author shows setup, MCP wiring, and where the model earns its slot reviewing responses and code that pricier attacker models already pulled — a pragmatic division of labor between cheap analysis and expensive exploitation.
Watch for:
- Cheap large-context models used as reviewers, not attackers
- MCP wiring into Burp Suite / Caido for captured traffic
- Safety-filter limits (no active exploitation) shaping workflow design
- Whole-repository and whole-session reasoning as the differentiator
- Cost and latency trade-offs versus frontier attacker models
Wardley signals:
-
Components: Gemini CLI; Burp Suite and Caido MCP servers; the Model Context Protocol; source-code review; captured HTTP traffic; the bug bounty workflow; frontier attacker models.
-
Evolution stage: CLI coding agents are Product (competing, maturing); MCP is a Custom/emerging standard; large-context review is Custom; the bug bounty process is Product.
-
Doctrine: “Use appropriate tools” and “focus on the outcome” (analysis, not exploitation); “remove bias and duplication” (don’t waste expensive models on review); “effectiveness over efficiency.”
-
Climatic patterns: “Efficiency enables innovation (Componentisation effect)”; “No single method fits all”; “Increased stability of lower order systems increases agility & speed of re-combination” (MCP as a stable interface).
-
Diffusion markers: published how-to guides, MCP standardisation, generous free tiers, and a split analysis/exploitation workflow spreading across the security community.
-
How to use Gemini CLI for Bug Bounty research: analyse evidence, validate manually
wardley-beta %% Q1 Who are the users? Bug bounty hunters and security researchers. %% Q2 What are their needs? Review large code and traffic corpora cheaply before attacking. %% Q3 What capabilities are required? A cheap large-context agent, tool bridges and captured evidence. %% Q4 What components are used? Gemini CLI, MCP, Burp/Caido MCP servers, captured traffic, source review. %% Q5 How mature are those components? Captured traffic is Commodity; CLI agents and MCP servers are Product; MCP is Custom/emerging. %% Q6 Who manages them and how? Researchers wire their own MCP bridges; Google runs Gemini. anchor bugHunter [0.92, 0.94] component geminiCli [0.55, 0.72] component mcpProtocol [0.35, 0.6] component burpCaidoMcp [0.5, 0.5] component capturedTraffic [0.75, 0.42] component sourceReview [0.55, 0.55] geminiCli -> bugHunter mcpProtocol -> geminiCli burpCaidoMcp -> mcpProtocol capturedTraffic -> burpCaidoMcp sourceReview -> geminiCli