DEV Community: Harshith Vaddiparthy

Keep the thread, wherever the work goes

Harshith Vaddiparthy — Thu, 22 Oct 2026 22:32:48 +0000

Keep the thread: designing account and conversation boundaries

My contributions to the Kenzai team’s product, merged on October 13, 21, and 22, 2026, share a design problem: a transition should not erase a decision that still applies.

These changes are development work, not a confirmed production rollout.

1. Separate identity from integration consent

The October 22 Google sign-in contribution adds identity-only login and signup, separating account access from optional Gmail linking. Live Google sign-in and onboarding acceptance are still pending.

The reusable lesson is to distinguish two questions:

Who is signing in?
Which additional service does that person want to connect?

Treating those questions independently avoids making optional integration consent part of the account-entry requirement. This is a design principle, not a claim about measured signup performance.

2. Give setup completion its own meaning

Another October 22 contribution restores authenticated setup for accounts without stored connections. Finishing or skipping setup preserves each user’s completion state across reloads and retries, without changing other users’ data. Deployed onboarding remains unverified.

A useful modeling rule follows: connection presence and setup completion are not interchangeable. An account can have no stored connections and still have a meaningful setup decision.

When designing a comparable flow, define what finishing means, what skipping means, and which user owns that state. Do not let a reload redefine a decision the user already made.

3. Define continuity beyond message history

The October 13 work includes a full-page agent chat interface that preserves the current conversation and unsent drafts across workspace views. A separate New chat action starts a fresh session. This remains a draft release candidate.

The October 21 contribution extends the continuity principle to moving the same conversation from the sidebar into Work, preserving drafts, attachments, audience and model choices, and pending actions. Production availability is not established.

For a similar interface, write down a continuity checklist before wiring navigation:

Current conversation
Unsent draft
Attachments
Audience selection
Model selection
Pending actions

This is a suggested engineering checklist, not a report of additional testing. Its purpose is to prevent a narrow definition of state preservation in which message history survives but the user's current work does not.

4. Specify placement and input together

The October 13 sidebar contribution docks agent chat beside the task board on wide screens and slides it in from the right on smaller screens. It includes suggested prompts, a new-chat button, Enter to send, and Shift+Enter for a new line.

Responsive placement is only half of the interaction contract. Keyboard behavior also needs an explicit meaning. Moving a composer should not make writing feel like a different operation.

The boundary rule

Navigation preserves activity. Reset is explicit. Optional consent remains separate from identity. Those rules are useful because they make product behavior understandable before any implementation detail enters the discussion.

Finally, keep evidence language precise: a merged contribution establishes a merge, not deployment or a customer outcome.

Build notes and sources: https://www.harshith.com/diffs/build-notes-2026-10-23-1839228855

Black October 2026: what happened, what AI changed, and what to do now

Harshith Vaddiparthy — Thu, 22 Oct 2026 22:06:21 +0000

By Harshith Vaddiparthy

Research checked October 23, 2026. Incident reports are still developing; versions and provider status below describe the evidence captured for this edition. Dates in the technical timeline use UTC unless noted otherwise.

“Black October” is the name spreading through technology and cybersecurity circles for a cluster of serious software vulnerabilities, supply-chain compromises, and data breaches reported during October 2026.

It is a useful signal that something needs attention. It is a poor substitute for an incident report.

The most alarming posts describe the worst 48 hours in cybersecurity history, hundreds of millions of endangered websites, an approaching internet lockdown, and the beginning of an AI takeoff. Those are different claims. They require different evidence.

The verified story is already significant. AI-assisted researchers helped develop exploits against longstanding PHP flaws. PHP released emergency patches. An AI gateway's release pipeline distributed malware. Hosting providers disclosed exposure of customer secrets. Weak certificate-authority keys forced trust-store changes across the software ecosystem. At the same time, older attacks were being disclosed, investigated, or added to public threat reporting.

This article separates those layers, explains the mechanisms in plain language, and gives you a way to decide what to do about your own systems. It also preserves the uncertainty: a disclosed vulnerability is not proof of a breach, a breach affecting some customers is not proof every customer was compromised, and a series of frightening headlines is not proof that one actor or one AI system caused them all.

What the phrase refers to

The current discussion concerns cybersecurity in October 2026. It should not be confused with historical financial crises or other events that have also been called Black October.

A particularly influential post from AISafetyMemes lists 27 items and calls the preceding period “the most serious 48 hours in cybersecurity history.” The list includes PHP2Shell, eMudhra, California student records, Railway, Zeabur, LiteLLM, GitLab, Cairn, and numerous other incidents.

The post helped connect stories that many readers had encountered separately. It also compressed several timelines and types of evidence into one dramatic narrative. Some entries concern newly available patches. Some concern malicious software that was actually distributed. Others concern attacks that began months earlier or operational shutdowns undertaken as a precaution.

Another widely shared essay by John Milinovich interprets the moment as a fast AI takeoff. That is his assessment. The vulnerability and incident reports reviewed here do not establish it. His claims about national strategy and relative model capability are also distinct from the directly documented security events.

The important question is what these events tell us about security work, and what changes when more of the research and attack process can be automated.

Source screenshot: an excerpt of the viral post examined below. The following audit distinguishes its claims from confirmed evidence.

Four terms that keep the discussion honest

A vulnerability is a weakness that can be used to violate a system's intended security. It can exist for years before someone finds a practical way to exploit it.

An exploit is a method of using that weakness. A demonstration against a test deployment establishes exploitability under the tested conditions. It does not count the number of production systems an attacker has compromised.

A compromise means someone gained unauthorized access, caused malicious execution, or otherwise breached a security boundary. Its scope depends on the investigation. “Some environment variables were decrypted” and “all customer databases were stolen” describe very different situations.

A disclosure is when information becomes public. The date of the disclosure may differ substantially from the dates of initial access, discovery, containment, notification, and patch release.

There is another distinction worth keeping: a mitigation can reduce risk without removing the underlying weakness. A remediation addresses the problem itself. Firewall protections may block known requests while an unpatched runtime remains vulnerable through an unprotected route or a different variant.

Once these terms are separated, the month becomes easier to understand. It contains a real emergency, several separate compromises, and a large amount of information arriving at once.

PHP2Shell: the most consequential technical story

On October 21, the PHP project released fixes for CVE-2026-109618 and CVE-2026-109619. Its official advisory describes two critical vulnerabilities that can allow unauthenticated remote code execution. Both were rated 9.2 under CVSS v4.0 in the advance notice.

The research effort calls the family PHP2Shell. Researchers from Wiz, OpenAI Codex Security, and Calif worked with PHP's maintainers and other organizations on discovery, validation, coordinated disclosure, and protections.

PHP is an interpreter and runtime used to execute the code behind websites. WordPress, Drupal, Joomla, MediaWiki, and many custom applications run on it. The affected code is in PHP's own engine, below the application layer.

This is why telling a website owner to update their plugins is insufficient. A site can have current application code while running a vulnerable PHP process. The relevant version is the runtime that handles real web requests, including instances hidden inside containers, hosting panels, legacy services, and background workers.

Source: PHP official security advisory; screenshot is an excerpt of the original page.

What goes wrong inside the engine

The official advisories group the findings into two related classes.

In the out-of-memory corruption class, a memory allocation can fail while internal request data is only partly initialized. PHP's error-handling path can leave that data in a state that later cleanup treats as valid. Under exploitable conditions, that can lead to memory corruption and code execution.

In the stale-global-state class, a worker retains references to memory belonging to an earlier request after the backing memory has been freed. A subsequent request can encounter that state before initialization resets it. The result can be a use-after-free, memory disclosure, or code execution.

Imagine a hotel receptionist keeping a room key on the desk after the room has been reassigned, then using the old key-label combination to decide who can enter. The analogy is imperfect, but it captures the lifecycle error: the system trusts a reference after the thing it referred to has changed.

A working exploit still has to account for the PHP build, server interface, configuration, worker behavior, and memory layout. The advisory explains that some paths were demonstrated against Apache's mod_php and others against PHP-FPM with suitable application conditions. That variation affects exploitation. It does not create a general exemption from patching.

What the demonstrations prove

Wiz's report describes unauthenticated code-execution demonstrations against WordPress, Drupal, and Joomla container deployments. It also describes reading sensitive PHP worker memory without first achieving code execution.

Calif's account reports additional tested applications and explains its research process. The joint PHP2Shell site emphasizes that the applications are representative targets: the weakness resides in PHP, rather than in a particular CMS plugin.

The practical impact can include control of the affected process, access to application data and credentials available to it, and opportunities to move further through a system. The exact blast radius depends on permissions and architecture. Code execution as a web worker does not automatically mean administrator access to every connected service.

The demonstrations establish a serious, practical vulnerability. They do not establish the percentage of websites already compromised.

The “70% of websites” number

The joint research materials and Wiz describe PHP as powering approximately 70% of websites. That is an ecosystem-use claim used to convey the possible reach of a foundational runtime problem.

It is not a measured count of exploited sites. It is also not evidence that every PHP deployment exposes the same attack path or that every affected deployment was still unpatched at publication.

Whenever a percentage this large appears in a security headline, ask what is being counted: technology usage, potentially affected installations, reachable vulnerable services, observed attack attempts, or confirmed victims. Those denominators cannot be substituted for one another.

The fixed PHP versions

The PHP project identifies the following first fixed releases:

PHP branch	First fixed release
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

Apply a release containing the fixes, then restart or redeploy the workers that handle traffic. A package installed on disk does not prove a long-lived process has loaded the new version.

Linux distributions and LTS vendors may backport fixes without adopting the same upstream version string. Check the vendor's security notice and package revision. PHP 8.1 and older no longer receive regular upstream security maintenance. The project provided minimal source backports for 7.4, 8.0, and 8.1 for this emergency, but that does not restore those branches to supported status.

For a managed host, obtain an answer to a specific question: which package or runtime revision addresses both CVEs on the instance serving this application, and when was it activated?

Why firewall protection is not the endpoint

Cloudflare, Vercel, Google Cloud, and other providers prepared protections and guidance. Vercel's bulletin states that its WAF rules reduce exposure to known exploit patterns and do not replace patching. It also states that requests bypassing Vercel's network, including direct requests to an external PHP backend, are not covered.

Google Cloud's guidance distinguishes automatically updated services from services requiring a rebuild or redeployment. A supported App Engine Standard runtime and a self-built Cloud Run container do not have the same operator responsibilities.

The PHP advisory is explicit: interim configuration changes reduce exposure to specific paths, but updating is the only complete solution. Some suggested settings have significant memory-management and availability tradeoffs. Copying one setting out of context can move the failure elsewhere rather than make the application safe.

If you cannot patch promptly, follow the maintainer and provider instructions, consider restricting or removing public exposure, and make the temporary state an owned incident with an expiry. Do not let a successful WAF block become the evidence that the origin was patched.

The timeline that changes the interpretation

The PHP Foundation's account is essential reading because it describes the work behind the release, including earlier knowledge and difficult tradeoffs.

Date	Documented development	What the date means
2024	Work following an external audit exposed the first signs of the out-of-memory problem.	Earlier recognition of a design problem, without a concrete exploit vector at that stage.
July 30, 2026	Calif began auditing PHP through Patch the Planet.	Start of a specific audit effort.
August 11	Calif reported unconditional remote code execution with the same root cause.	A concrete report that clarified impact.
August 19–24	Wiz describes discovery, confirmation against test applications, and reporting to PHP.	Independent research and disclosure to maintainers.
September 18	The Foundation records further attack vectors from OpenAI.	Continued research before public release.
October 20	CVE identifiers circulated with a wrong release time and an incorrect score of 10.0. PHP brought forward its pre-announcement.	A disruption to the embargo and communication plan.
October 21, 14:00 UTC	The emergency release became available, one day earlier than originally planned.	Patch availability and coordinated public disclosure.

The Foundation explains why fixing the out-of-memory design was hard: competing approaches introduced compatibility problems, new denial-of-service risks, or extensive changes involving extensions. It describes the earlier delay as a structural failure involving decision processes and insufficient resources.

It also reports premature disclosure of a demonstration video and early publication of patched images by a distributor. Those details matter because even a partial demonstration or a binary patch can help an attacker narrow the research problem before the rest of the ecosystem has updates ready.

At the time of the coordinated release, the Foundation says it had inspected circulating proof-of-concept attempts without identifying functional exploits. That is a statement about the evidence available at that time. It should not be converted into a claim that no attack could occur later or that every suspicious request was harmless.

The larger lesson is that disclosure coordination is an engineering operation. You need validated findings, tested fixes, downstream packages, instructions, protections, and enough communication that people can act. Speed in one stage can increase risk if the other stages have not caught up.

Original explanatory timeline. Sources: PHP Foundation, Zeabur and LiteLLM.

What AI demonstrably changed

There is direct evidence for AI's role in the PHP research. OpenAI says Calif identified a critical flaw using GPT-5.6 Sol. Wiz describes using Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol during discovery, exploit development, detection, and patch validation.

These are reports from participants in the work, not an independent benchmark of every model or a general claim that all AI can perform the same task. The important mechanism is nevertheless clear.

A difficult memory bug can involve repeated cycles of source review, hypothesis formation, test construction, failure analysis, and adaptation. Different builds and applications change the conditions. Automating part of that work lowers the effort required to investigate and adapt an exploit.

This can change the practical value of a flaw. Something that was theoretically dangerous but prohibitively difficult to exploit may become a realistic attack target when the cost of iteration falls.

The same capability can help defenders test patches and identify related variants. It is a dual-use change in research economics. It does not tell us that defense will automatically win, or that attacks will automatically succeed.

The maintainer bottleneck

The PHP Foundation reports that the security team published 15 CVEs since July 1 and processed more than 100 reports that were invalid, duplicates, or not reproducible. AI helps with validation and grouping, but people still make decisions and work on patches.

That is a less cinematic problem than autonomous hacking. It may be more important to fixing the system.

More findings require more triage. More variants require more testing. A fix to a foundational runtime may involve several operating systems and deployment models. If experienced maintainers have no time or funding, increasing the rate of incoming reports can lengthen the queue.

OpenAI's proposed coordination framework describes upstream validation, advance notice to organizations that can prepare protections, government coordination, downstream updates, and deployment support after publication. It is a proposal informed by the participants' experience. Its effectiveness still depends on execution, coverage, and incentives.

The measurable question is how long it takes a verified finding to become a verified fix on an exposed production system. Counting reports alone does not answer that question.

Actual AI-assisted attack operations

NorForge's investigation of Cairn provides a separate line of evidence. Researchers examined publicly exposed control panels associated with AI-driven operations, identified more than 20 panels they assessed as likely malicious, and described how agents moved through targets, facts, plans, and goals.

The largest cluster used Chinese-language instructions and had more than 1,100 attack projects across 14 dashboards. That is an observed project count. It is not 1,100 independently confirmed breaches. Independent SecurityWeek reporting also covers the research and reports the broader compromise claims.

NorForge says the activity it could observe appeared financially motivated and that it saw no obvious state-sponsored intrusion activity. This is a useful corrective to posts that turn language and model origin into proof of a government's strategy. Attribution requires evidence beyond those characteristics.

The report supports a serious conclusion: adversaries are using agent frameworks to organize and scale parts of real intrusion work. It does not support claiming that every October incident came from Cairn, that every targeted company was successfully breached, or that the operator had unlimited autonomous capability.

LiteLLM: when the release itself becomes malicious

On October 21, LiteLLM's maintainers disclosed that its release pipeline had distributed 1.107.0 containing compiled malware that steals credentials and loads additional code. This is a supply-chain compromise: the artifact customers expected to trust was itself malicious.

The official incident report, last updated at 20:30 UTC in the captured edition, identifies the following exposure windows:

Artifact	Documented affected window on October 21
PyPI `litellm==1.107.0`, all seven wheels	Approximately 11:39:51–13:23 UTC
Docker Hub `v1.107.0`, `latest`, `main-latest`, `main-stable`	Approximately 11:46:56–14:20 UTC
GHCR equivalents listed in the incident report	Beginning approximately 11:46:56 UTC, made unavailable by 13:51 UTC

The maintainers say their private enterprise registry was unaffected. That is a scope boundary in the report, not a reason to assume every artifact bearing the product name had the same exposure.

Clean source and poisoned artifacts

One of the most important details is that the official GitHub source tag did not contain the malicious files. The compromised artifacts were built from a lookalike, attacker-controlled repository.

The maintainers' preliminary account describes stolen developer credentials, an organization-owner credential used to override branch protections, a modified workflow, and signed publication through the established pipeline. They also describe suspected token exposure through responses and logs in their internal deployment. Parts of that causal chain remained under investigation.

That means several reassuring signals could coexist with a malicious release: a familiar package name, an official distribution channel, a clean source tag, a passing publication workflow, and signatures produced using compromised authority.

A signature tells you who, or which authority, signed something. It does not by itself prove that the authority remained uncompromised or that the artifact was built from the repository you intended.

Why “just downgrade” is insufficient

The report says malicious Python startup files can execute whenever Python starts, including when pip starts. That makes the instinctive cleanup step, running another pip command in the contaminated environment, potentially counterproductive.

If an affected artifact executed, treat the environment as compromised. Use a clean administrative environment, preserve relevant evidence, and follow the maintainers' removal and recovery instructions. Rebuilding affected images and virtual environments from trusted inputs is preferable to trying to prove every malicious file was removed.

Then address credentials. The report explicitly includes provider keys stored in the proxy database, master and virtual keys, database passwords, environment secrets, and reachable cloud roles.

A container boundary does not guarantee that secrets were safe. What matters is what the process could read or obtain: environment variables, mounted files, cloud identity endpoints, application databases, and connected services.

A current package version also does not erase history. An environment that briefly ran 1.107.0 can be compromised even if it was subsequently downgraded. Look at build records, image digests, package caches, deployment timestamps, and process history, rather than only the present pip show output.

Railway and Zeabur: two separate secret-exposure incidents

Railway's October 21 notice says an unauthorized third party may have accessed encrypted customer environment variables and obtained decrypted contents for some of them. Its initial analysis suggested a subset of users. It recommended that all users rotate stored environment variables, API keys, and private registry credentials as a precaution and review service logs.

The notice also says deployments were paused during investigation. That describes the captured announcement. Check the live status page for current operational state; a historical statement is not evidence that builds remain paused indefinitely.

Environment variables often contain the authority an application uses to reach other systems. A stolen database password can expose data. A model-provider key can incur charges or access resources permitted by that key. A registry credential can affect software distribution. The consequences differ by scope and permissions.

Railway's incident report does not prove all customers' secrets were decrypted. It does establish why the provider recommended a broad precautionary response.

Zeabur's preliminary report concerns access on October 14–15, not a fresh compromise first occurring on October 21. It confirms reads of 3,218,965 environment-variable records and account information covering 321,810 accounts. It also distinguishes confirmed server sign-ins, assessed database access, and access whose use could not be determined.

Zeabur's shutdown announcement says some services begin shutting down December 1 and dedicated servers and shared clusters are scheduled to be shut down by December 31. A company announcing closure and a company already being offline are different facts.

Rotation while the attacker can still read backups

Zeabur describes a particularly useful operational failure. A new credential rotated during the incident was captured by a subsequent backup and later used without authorization. Its report qualifies which downloads were assessed and which later uses were confirmed.

This illustrates why credential rotation must be connected to containment. If an attacker retains access to the secret store, a backup, a deployment pipeline, or the new runtime, a replacement credential can be exposed immediately.

The recovery sequence needs to establish a clean control plane and trusted destination for new secrets, revoke the old authority at its source, and verify that the attacker cannot obtain the replacement. That can require parallel work and careful ordering; it is not a single universal command.

Afterward, inspect the services the credentials authorize. Updating an environment variable in your hosting dashboard does not necessarily revoke the old key at the model provider, cloud platform, registry, or database.

eMudhra: a certificate-trust incident, not every website's master key

Eight eMudhra intermediate CA private keys were reported compromised after being generated with insufficient randomness. A certificate authority is part of the machinery clients use to establish whether an HTTPS certificate should be trusted.

A weak intermediate signing key can permit forged certificates for clients that trust the affected hierarchy and lack other blocking protections. That is serious. It is more specific than saying the master keys to every website were cracked.

Google's October 20 account records receipt of the report on October 17 at 18:05 UTC and a Chrome CRLSet update blocking the affected public-key hashes at 19:45 UTC. It explains that the block did not require a browser update or restart for standard Chrome protection. Android received an equivalent update through Google Play Services on a separate timeline.

Google also describes Certificate Transparency protections and subsequent removal of emSign ECC Root CA - G3 from its root store for consumers that do not receive CRLSet updates. The broader root-store removal was expected to reach the relevant stable devices on October 27. Operators with certificates chaining to that root were instructed to obtain replacements from a different trusted hierarchy.

eMudhra's statements say the weakness involved intermediate keys, rather than root private keys, and that the affected intermediates had issued no end-entity certificates. Its October 21 account says the exact root cause remained under investigation. Those are vendor statements and should be attributed accordingly. Browser operators' independent protective actions remain relevant regardless of the vendor's explanation.

The Cloudflare analysis supplies more technical detail, including why absurdly weak private-key values appeared in the discussion. The meaningful issue is failed key generation and trust handling, rather than the shock value of a small number.

Your browser and your installer may trust different things

Software does not all share one certificate store or one revocation mechanism. Browsers, operating systems, Python libraries, package installers, language runtimes, and containers can have different update paths.

That is why a browser being protected does not prove every process on the same device has the same protection. Conversely, the existence of an old bundle does not prove that someone intercepted your traffic. Identify the actual trust path and follow its maintainers' update guidance.

Do not disable certificate validation to work around a failed connection. An intentional loss of trust can produce breakage that is evidence a protection is doing its job. Replace the affected certificate hierarchy or update the relevant bundle rather than suppressing the check.

Node.js, GitLab, and HTTP/3 also deserve attention

The Node.js October 21 security release includes CVE-2026-111497, a high-severity out-of-bounds write in its Brotli decoder that permits remote code execution. The advisory identifies affected 22.x, 24.x, and 26.x release lines and credits OpenAI Codex Security researchers for reporting the finding.

The release also addresses other issues and dependency updates, including certificate-store changes related to eMudhra. For operators, the correct action is to use the official security release for the branch actually deployed, update base images where appropriate, redeploy, and verify the running version. Merely updating the development laptop leaves production untouched.

GitLab's October 21 patch release addresses CVE-2026-110264, a critical integer overflow in a regular-expression compiler. Under the described conditions, an unauthenticated user could execute code on the affected server. Its published CVSS v3.1 score is 10.0.

The fixed GitLab CE/EE releases listed are 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, and 19.5.1. GitLab says GitLab.com is patched and identifies Dedicated versions already containing the fixes. That is why “GitLab users need to patch” is too broad without distinguishing self-managed installations from the managed service.

CERT-EU independently recommends updating affected assets, prioritizing internet-facing systems, and assessing compromise. Available detection rules support that assessment; they are not proof that every instance was attacked.

FoxIO's Header Accordions research describes another kind of risk: HTTP/3 implementations allocating far more memory for decoded headers than the incoming compressed representation occupies. Its summary says seven of ten tested implementations were vulnerable, with several already fixed at publication.

This is principally an availability problem in the described research. A denial-of-service attack that exhausts a server's memory and a remote-code-execution vulnerability are not interchangeable. “Seven of ten tested implementations” also does not mean 70% of the internet's servers were compromised.

The report lists fixed library versions and mitigations for unpatched implementations. An operator needs to determine whether HTTP/3 is exposed and which implementation is running, including inside gateways and bundled tools. Turning off one protocol temporarily can be an appropriate scoped mitigation while a fix is tested; the exact action depends on the deployed stack.

A closer look at the viral 27-item list

The following table follows the order of the influential AISafetyMemes post. It is a claim audit, not a count of confirmed attacks in a particular 48-hour period. “Documented” describes the type of evidence reviewed. Where the research packet did not establish a first-party confirmation, the row says so.

Some entries have independent reporting rather than a complete public forensic report. That reporting can establish a useful lead or a dated event without settling every question of scope or attribution.

Item in the viral list	Evidence and timing	The qualification that matters
1. PHP2Shell	PHP advisory, research reports, and emergency releases on October 21.	A documented vulnerability family and controlled exploit demonstrations. Potential exposure is not a count of breached websites.
2. eMudhra	Google records weak intermediate keys and protection starting October 17.	Intermediate CA key compromise and root distrust have distinct meanings. Browser and non-browser clients can receive protections differently.
3. California student records	The Record reports data copied from May 22 through September 18, discovery September 25, and family notification beginning October 16.	A serious data breach whose access period predates the claimed 48-hour window. Avoid replacing the affected population with one current-enrollment statistic.
4. Railway	Provider notice on October 21 describes possible access and some decrypted environment variables.	Scope remained under investigation. The recommendation to all users is precautionary; it does not prove every user's secrets were taken.
5. Zeabur	Preliminary provider report describes October 14–15 access, confirmed account and environment-variable reads, and assessed additional access.	The October incident and the separately announced December shutdown schedule must not be collapsed into “the company just went offline.”
6. LiteLLM	Maintainer report confirms compromised release artifacts on October 21.	A poisoned release is different from a software vulnerability. Affected artifacts and execution history determine response; download totals do not establish victim totals.
7. GitLab	Vendor patch release on October 21 identifies a CVSS 10.0 issue and fixed versions.	The managed service and self-managed installations have different responsibilities. “Could execute code” is not a statement that every server was breached.
8. Cairn	NorForge, published October 19, documents exposed control panels associated with AI-driven operations.	Attack projects, panels, attempts, and confirmed compromises are different measures. The researchers' observed language does not establish government sponsorship.
9. Ahold Delhaize	Corporate update describes a cyber incident and service disruptions. Context reporting dates the incident to October 12.	Stores remaining open, websites being unavailable, and customer-data compromise are separate questions. Use the corporate update for current scope.
10. Onamae Desktop Cloud	GMO notice confirms unauthorized access and unauthorized programs in some customer server environments, with 26,739 potentially affected servers.	“Potentially affected servers” is the provider's scope language. It does not establish 26,739 independently confirmed infected systems.
11. Signal	Reporting on RingRTC concerns calls failing to terminate. The fix was available in September.	A disclosure discussed in October is not necessarily a newly introduced flaw or a fresh attack. This packet does not establish known exploitation.
12. NGINX	Project security advisories identify affected conditions and fixed versions. Releases 1.30.6 and 1.31.7 arrived October 14.	Severity labels differ between the project and vendor reporting. Configuration prerequisites matter; a server-usage percentage does not measure compromise.
13. HTTP/3 / QPACK	FoxIO research tests header-to-memory amplification across implementations.	The described outcome is denial of service. The sample of tested implementations is not the entire deployed internet.
14. Plex2Shell	CISA's October 20 notice includes Plex vulnerabilities based on active exploitation evidence.	This is stronger exploitation evidence than a hypothetical impact description. Apply the specific vendor updates and investigate relevant exposure.
15. SafePay ransomware	Joint advisory describes a ransomware threat and previously observed victims.	An advisory's cumulative victim count is not the number of new incidents that day. Initial access methods and affected assets still need case-specific review.
16. Palo Alto / GlobalProtect	Unit 42 and independent reporting describe attacks against CVE-2026-0257. The patch dates to May.	Active exploitation of an older vulnerability illustrates unresolved exposure. It is not evidence that the vulnerability first appeared during Black October.
17. Bullhorn	BleepingComputer reports the platform being taken offline during response.	The company's customer count describes reach, not a verified count of breached customers. A shutdown alone does not establish data theft.
18. Medi-Cal / Paradigm	SecurityWeek reports more than 970,000 affected members, with unauthorized access detected in October 2025.	This is the clearest reason not to treat the list as 27 attacks in 48 hours: the underlying access was a year earlier.
19. WordPress / UpdraftCentral	TeamUpdraft and Patchstack describe stolen connection keys and backdoor installation.	A management connection can provide a route into an otherwise updated website. Plugin updates, key revocation, and inspection for persistence are different actions.
20. AOMEI	Google Threat Intelligence / Mandiant describes short tampering windows in May and July.	The October reporting date must not replace the actual delivery window. Restoring the update server does not clean customers already infected.
21. Meta Muse	The viral list alleges sensitive exposure; supplementary reporting concerns discoverable shared-chat links.	This packet does not establish that an autonomous agent newly stole all the described secrets. Public-link exposure, intended sharing, and unauthorized access require separate scope evidence.
22. Tor	Researcher's account describes 333 compromised exit relays used for SSH interception beginning October 2, with blocking and shutdown by October 5.	The write-up appeared October 20. It describes an earlier campaign and emphasizes the significance of SSH host-key warnings.
23. TiDB Cloud / PingCAP	Provider report dates unauthorized internal access to September 9–October 7.	PingCAP identifies exposed account and operational information while stating there was no evidence data stored in TiDB was affected. Do not turn that into “all hosted databases leaked.”
24. State Bank of India	The viral list claims confirmation of a breach. No first-party SBI confirmation was established in this packet.	Keep this as an unresolved lead, not a confirmed bank-compromise claim or a reader action directed at SBI accounts.
25. OVHcloud CLI	BleepingComputer reports backdoored release binaries on October 19.	A CLI release compromise is not the same as compromise of every cloud customer. Installed artifact identity and the credentials the tool could reach determine exposure.
26. Siemens Software Center	Siemens ProductCERT confirms exploitation of a DLL-loading vulnerability.	Attackers combining legitimate signed software with malicious DLLs does not mean Siemens' official update infrastructure was poisoned.
27. North Korea / South Korea campaign	Kaspersky describes Operation FlashHole and attributes it to Lazarus.	The report dates activity to at least July 2025. Attribution is the research team's assessment, and publication in October is not the start of the campaign.

This table does not make the individual risks smaller. It makes the interpretation more accurate. A data breach from last year can still hurt people today. An old unpatched vulnerability can still be an immediate operational priority. You do not have to invent simultaneous origins to take either seriously.

The detailed SecurityToday timeline review was useful for tracing several of these dates to vendor and independent reports. Its German original is identified as authoritative by the publication; translated wording should be checked against the linked sources when exact phrasing matters.

Does this mean the internet is going into lockdown?

Some organizations did take services offline, and security authorities advised that removing exposure may be appropriate when critical systems cannot be patched. That is a real operational response.

The UK NCSC's PHP warning and its earlier patch-wave guidance explain the need to prepare for increased vulnerability discovery. These should be read as guidance about organizational risk and response.

They do not establish a centrally coordinated shutdown of the internet. A government website being taken offline, a hosting provider pausing deployments, and a company preparing to close its platform have different causes and consequences.

“Internet lockdown” turns these decisions into an expectation about the entire network. The sources captured here do not support that leap. Nor do they establish a date on which ordinary users will lose general internet access.

For a team deciding whether to take its own service offline, the relevant facts are narrower: is a vulnerable component exposed, can a reliable fix be applied, what mitigation covers the actual traffic paths, what evidence suggests compromise, and what is the consequence of continued operation versus temporary interruption?

Does this prove AGI or recursive self-improvement?

No such conclusion follows from these incident reports.

AI-assisted exploit research and agent-directed attacks are important capabilities. They do not, on their own, demonstrate a system that outperforms humans across every knowledge task, recursively improves its own underlying model, or has entered a particular takeoff regime.

You can discuss those scenarios as hypotheses. You should not present a news cluster as if it were a controlled measurement of them.

The immediate change is enough to justify attention: tools can make costly security tasks easier to attempt and repeat. That affects both adversaries and defenders, while putting greater pressure on maintainers and operators who have to act on the results.

A practical response for website and AI-app operators

The following is a suggested operating sequence, not a claim that every reader is affected or a replacement for the relevant vendor incident instructions. Run it against systems you own or are authorized to manage.

1. Build a small exposure inventory

Start with the applications that are public, handle sensitive data, or possess powerful credentials. Record the actual owner, deployed runtime or artifact, internet exposure, relevant advisory, and remediation state.

An inventory row might look like this:

Asset	Evidence to collect	Closure condition
WordPress or custom PHP site	Hosting revision, PHP worker version, provider bulletin, restart or redeploy receipt.	Both PHP CVEs addressed on every serving instance, with the new runtime verified.
Node service	Deployed Node branch, container image digest, build and release records.	Official branch security release deployed and running.
Self-managed GitLab	Installed edition and version, exposed endpoints, vendor patch notice, detection review.	Appropriate fixed release installed and relevant compromise assessment complete.
LiteLLM gateway or worker	Package and image history, affected execution window, reachable credentials.	Compromised environment contained and replaced, exposed authority revoked, downstream activity reviewed.
Hosting environment	Stored credentials, provider incident scope, access and billing logs.	Required rotations completed at issuing services and replacements stored on trusted systems.
Certificate-dependent software	Actual trust bundle, revocation path, affected hierarchy, image or binary update.	Relevant trust changes applied and tested without disabling verification.

There is a common trap here: checking the CLI version on one machine and assuming it represents a web worker in another container. Version evidence must come from the service and instances that actually handle traffic. Keep diagnostic endpoints private; a publicly exposed phpinfo() page can reveal more information than necessary.

2. Split patching from incident response

If the evidence is a vulnerability and no compromise has been identified, patch or apply the documented mitigation, verify it, and assess whether prior exposure warrants investigation.

If the evidence is malicious execution or exposed secrets, add containment and recovery. An update alone cannot revoke a stolen credential or remove persistence an attacker installed elsewhere.

For LiteLLM, do not start the affected interpreter just to inspect it casually. For a compromised hosting control plane, do not put replacement secrets back into a system whose unauthorized access remains unresolved.

Preserve useful logs and build records before they expire. Evidence should be protected and access-limited. Avoid spreading secrets through incident chat, screenshots, or exported logs during the cleanup.

3. Revoke authority at the source

A secret copied from a hosting environment belongs to another service's authentication system. Changing its local value does not necessarily invalidate the original credential.

For each exposed credential, identify the issuer, permissions, permitted resources, expiry, and activity history. Revoke or rotate it at the issuer, then distribute the replacement to trusted consumers and confirm that the old credential is rejected.

Where appropriate, inspect cloud audit logs, model-provider usage and billing, registry activity, GitHub access, database connections, and unusual exports. Review findings according to the credential's actual permissions rather than assuming either zero impact or unlimited impact.

Cloud identity can be more complicated than a static environment variable. A compromised workload may obtain temporary credentials through its role. Respond using the cloud provider's instructions for sessions, role permissions, and access containment.

4. Verify the running fix

Completion evidence should include the advisory addressed, the actual package or digest deployed, the activation time, and a live check on the serving system.

For a cluster, verify coverage across instances. For a containerized service, rebuilding the image is only one step; the new image has to replace the running workloads. For a library bundled into a binary, rebuilding and redeploying the binary may be required.

Then test the application paths that could regress. Memory-management changes can affect uploads, error handling, and worker behavior. A patch that is installed but immediately rolled back after a broken workflow has not produced durable protection.

5. Improve the release and secret boundaries

Use explicit dependency versions and image digests, but remember what they prove. They identify an artifact. They do not establish that the chosen artifact was safe at the time you selected it.

Review who can modify release workflows, bypass branch protections, access signing authority, and publish artifacts. Keep production release credentials narrower than general development credentials where the platform supports it. Reduce secrets in logs and give credentials realistic expiry and rotation plans.

Separate build environments from production data and credentials. Limit a compromised build or dependency's ability to access unrelated systems. Review network egress and workload identity with actual operational requirements in mind.

These controls make the blast radius smaller even when the next vulnerability has not yet been named.

A practical response for everyday users

Most readers do not administer PHP runtimes or package registries. That does not mean every security headline requires an emergency purchase or a new app.

Keep your operating system, browser, messaging apps, and important software updated. Prefer official update mechanisms. A real security incident creates excellent cover for fraudulent “patches” sent by direct message or promoted in search ads.

Use unique passwords through a reputable password manager. Enable passkeys or phishing-resistant multifactor authentication where available, especially for email and accounts that can reset other accounts. Keep recovery codes safely and review account recovery details.

If a service you use issues a specific breach notice, follow its instructions and monitor the affected accounts. A confirmed provider notice is more actionable than a repost naming a bank without a source.

Keep backups of important data and check that restoration is possible. A backup connected to the same compromised account or machine may share its risk. The right design depends on the data and devices involved, but a recovery test gives more evidence than merely seeing a backup icon.

For home devices, keep software current and reduce unnecessary remote exposure. Separate less-trusted IoT devices when your router supports it and you understand the configuration. That is sensible hygiene, not evidence that all home devices were affected by these incidents.

You do not need to abandon the internet to respond intelligently. You need trustworthy updates, protected accounts, usable recovery, and attention to notices that actually apply to you.

Questions that deserve direct answers

Is PHP itself affected, or only WordPress?

The vulnerable code is in PHP's engine. WordPress and other applications were demonstration targets. Updating a plugin or CMS alone does not update the runtime beneath it.

Am I safe because I use a managed host?

That depends on the service. Some providers automatically update supported runtimes; others require customers to rebuild or redeploy. Ask for the advisory, patched revision, and activation evidence for your actual deployment.

Does Cloudflare or Vercel protection mean I can postpone the patch?

Their protections reduce exposure to known paths. The PHP project says updating is the only complete solution. Direct origin access and different variants can change the remaining risk.

Should I set PHP's memory limit to unlimited?

The advisory discusses this as an interim measure with important limits and availability consequences. It is not a generic safety setting. Follow the complete maintainer guidance, contain resource usage appropriately, and apply the patch promptly.

What if my Linux package version looks older than the fixed PHP release?

Distribution vendors may backport security fixes. Check the vendor's package revision and advisory for both CVEs. An upstream version comparison alone can produce a false conclusion.

Does a lockfile protect me from the LiteLLM incident?

A lockfile reduces unexpected version movement if you honor it. It can still pin a compromised artifact. Verify the resolved version, artifact identity, installation history, and whether the affected release executed.

What if LiteLLM is clean now?

Current state does not establish historical safety. If the malicious version previously executed, investigate and rotate reachable credentials even if the environment has since been changed.

Should every Railway customer rotate credentials?

The captured Railway notice recommends that all users rotate stored variables, API keys, and private registry credentials as a precaution. That recommendation is broader than the provider's initial suspected subset of affected users.

Were all TiDB databases stolen?

The reviewed PingCAP report does not say that. It identifies specific account and internal information exposure and states that there was no evidence data stored in TiDB was affected. Investigation limits and unresolved scope should remain visible.

Were eMudhra's root private keys compromised?

The reported weakness involved eight intermediate CA keys. Browser programs also removed trust in the relevant root to protect consumers. Root distrust is not the same as proof that the root's private key was recovered.

Does a protected browser mean my Python environment is protected?

Not automatically. Applications can use different trust bundles and revocation systems. Determine what that Python environment, installer, and container actually trust, then apply the relevant maintainers' updates.

Did AI cause all these incidents?

The sources establish AI involvement in specific research and attack operations. They do not establish AI as the common cause of every item in the list. Credential theft, legacy vulnerabilities, exposed control planes, and weak key-generation procedures have their own causal chains.

Is this the worst 48 hours in cybersecurity history?

That is a superlative in a social post, not an independently established comparison. The list includes attacks and fixes outside the claimed window. A meaningful comparison would need a defined measure of impact and a consistent historical dataset.

What I would watch next

The useful indicators are operational rather than theatrical.

Watch how quickly exposed deployments are patched and verified. Watch whether stolen credentials continue to be used after providers announce containment. Watch whether small maintainers receive enough engineering capacity to turn higher report volume into reliable fixes.

Watch the quality of attribution. An agent framework in an attack does not establish the origin of every operation. A model vendor's research success does not provide a neutral measure of every model's capability. A source announcing a large number does not remove the need to identify its denominator.

And watch whether incident reports preserve uncertainty while they improve. Reports that distinguish confirmed reads from assessed access, describe failed controls, and update remediation instructions are more useful than a permanent claim that everything was instantly safe.

The frightening part of Black October is supported by the evidence: shared software and trusted distribution paths can create broad risk, and AI can lower the cost of finding and using weaknesses.

The useful response is equally concrete: know what is running, know what it can access, fix the relevant problem, revoke exposed authority, and verify the result.

The gap between discovery and protection is where engineering judgment, maintainer funding, and operational discipline matter most.

Sources and research method

This article uses first-party advisories and incident reports for the central technical and operational claims, independent security reporting for additional context, and original X posts to examine the public narrative. Original X posts were inspected alongside the advisories rather than used as substitutes for them. Source pages were archived in a research packet so dates, scope language, and later changes can be checked.

The main first-party sources are PHP and the PHP Foundation; Wiz, Calif, and OpenAI; LiteLLM; Railway; Zeabur; Google and eMudhra; Node.js; GitLab and CERT-EU; FoxIO; PingCAP; NorForge; CISA; and the linked provider incident updates. The 27-item table states when it relies on independent reporting or when first-party confirmation was not established.

The research does not include access to private victim systems, leaked customer records, or exposed attacker dashboards. It does not independently reproduce offensive exploits. Demonstrations and forensic findings are attributed to their publishers. Source pages and X metrics can change after capture, and no social reach statistic is used as evidence that a security claim is true.

Original response graphic based on PHP, LiteLLM and Google advisories.

Three merged PRs: making evidence, exports, and discovery easier to trust

Harshith Vaddiparthy — Thu, 22 Oct 2026 18:26:52 +0000

Improve the interface without weakening the contract

Three of my PRs merged in October 2026: Refund Desk on October 2, Grain Studio on October 5, and my website on October 22. These are contribution dates, not deployment claims or claims of sole project authorship.

1. Bind actions to saved evidence

Refund Desk separates customer claims from merchant confirmations and PayPal facts. Approval binds the exact saved review, case version, and full USD sandbox amount. A durable submission claim precedes the refund; an independent readback verifies the result.

The reusable principle is to identify the decision being authorized precisely. Also keep validation boundaries explicit: matching a quotation does not prove the interpretation is correct.

2. Make output behavior explicit

Grain Studio adds deterministic, colour-preserving Silver Grain without changing existing effect IDs or recipe URLs. PNG/WebP alpha remains intact; JPEG white flattening is disclosed. Bounded worker exports and cancellation make export handling part of the design rather than an afterthought.

Before changing a renderer, list the contracts that existing recipes and output formats depend on.

3. Preserve context during discovery

My website adds dated, source-linked publication records, keyboard-accessible search, and a photo gallery retaining original captions, posting dates, and Instagram links.

Discovery should shorten the path to content without stripping away provenance. Static screenshots can illustrate layout, but they cannot establish interaction behavior or deployment status.

Build notes and sources: https://www.harshith.com/diffs/build-notes-2026-10-22-0108b4c5a6

Make AI Project Warnings Traceable—and Retire Them When Facts Change

Harshith Vaddiparthy — Wed, 21 Oct 2026 02:50:22 +0000

An agent that summarizes project updates can still leave a developer or program owner doing all the dependency analysis. “The test environment is delayed” is an event. Working out which tests, reviews and commitments it affects is a separate task.

OpenAI's October 20 Orchestra Bio acquisition announcement describes a coordination use case in drug development. Its example is a failed manufacturing batch that can delay a clinical trial. OpenAI says Orchestra's agents help identify affected activities and timelines, gather information and compare responses, while scientists and program leaders decide what to do.

The announcement also says OpenAI aims to combine Orchestra with Rosalind to build agents connecting scientific findings with studies, decisions and next steps. It does not publish a controlled evaluation or quantified time savings for this workflow.

For developers, that suggests a concrete design problem: how do you represent an impact claim so a user can inspect it, correct it and withdraw it when the evidence changes?

The design below is a proposed implementation approach. It is not documentation of Orchestra's architecture or an available OpenAI API.

Store the dependency separately from the warning

A dependency records why one activity relies on another. A warning records what a particular event might mean given those dependencies.

Those have different lifetimes. “Integration testing requires the vendor environment” may remain true for months. “Integration testing cannot start” may become false this afternoon.

Start with three concepts:

An event: a dated observation from a source record.
A dependency: a relationship between activities, with evidence and any condition that makes it apply.
An impact assessment: the consequences proposed for a particular event and set of dependency versions.

Keep the source references in your application's own trusted record store. A model-generated record ID should never be accepted as evidence without checking that the record exists and the user can access it.

Represent uncertainty where it arises

Consider an illustrative release pipeline. Integration testing needs a vendor environment. Release approval normally needs the integration test result. A training session may depend on the release, but nobody has recorded whether its material uses the changed features.

Here is an illustrative impact record, expressed as JSON rather than a vendor-specific schema:

{
  "assessment_id": "impact-17",
  "trigger_event_id": "event-42",
  "dependency_versions": ["dep-3:v2", "dep-8:v1"],
  "affected_activity_id": "release-review",
  "basis": "conditional",
  "evidence_ids": ["record-11", "record-19"],
  "open_question": "Is the alternative test route accepted?",
  "decision_owner_id": "release-owner",
  "state": "open",
  "supersedes": null
}

These identifiers are fictional. In a real system, the dependency records referenced here must contain the actual relationship and its condition; IDs alone do not explain an impact.

The useful field is basis. Give the application a small, explicit vocabulary such as confirmed, conditional and unknown. Treat it as the reviewable basis for the claim, not as a calibrated probability supplied by a language model.

An impact farther down the chain cannot silently become confirmed just because the model produces a confident sentence. If a necessary upstream relationship is conditional, the downstream conclusion must preserve that condition unless separate evidence resolves it.

Use graph traversal to collect candidates

Once dependencies are represented explicitly, ordinary application code can find activities reachable from the changed activity. Maintain a visited set so cycles do not cause endless traversal. Set a work limit and report incomplete traversal instead of silently dropping the rest of the graph.

Reachability establishes candidates for review, not proof that every reachable activity is delayed. Conditions matter. An approved alternate environment may satisfy a dependency even while the original environment remains unavailable.

A practical division of work is to let deterministic code collect candidate paths and let the model draft explanations against the retrieved evidence. Require the output to reference actual candidate activities and evidence records. Reject references outside that supplied set.

That validation checks the structure. It does not establish that the model's interpretation is correct. Show the path and supporting records so the responsible people can review them.

Recompute when evidence changes

Refreshing the summary is insufficient if yesterday's warning remains active elsewhere in the product.

When a source event is corrected or a dependency is revised, identify assessments that reference it. Reassess those claims and preserve the earlier assessment as history. A replacement should point to the version it supersedes.

Use explicit states such as open, resolved and superseded. A restored vendor environment may resolve the immediate blocker while leaving a later deadline affected because a test slot was lost. The new assessment needs to explain that difference.

Avoid converting every new model response into a fresh notification. Compare meaningful changes: affected activity, condition, decision owner, evidence revision or resolution. Then apply your application's notification policy. Whether a user needs another alert is a product decision, not a side effect of generating more text.

Keep analysis separate from schedule mutation

For an initial pilot, produce assessments without changing due dates. A proposal to move a release should identify the decision owner and the evidence behind it.

If you later add authorized schedule changes, check that the plan version still matches the version reviewed. A decision based on yesterday's dependency graph should not silently overwrite today's plan. Make the proposed changes inspectable before applying them, and record the actual outcome.

This boundary also makes evaluation easier: you can compare the agent's suggested consequences with the owners' assessments before it changes the system it is supposed to understand.

Evaluate the reversal as well as the disruption

Build a small set of historical scenarios using only evidence available at each scenario's time. Include a genuine blocker, an optional dependency, a missing relationship and contradictory source records.

Then add follow-up events: the blocker clears, an alternative is accepted, or a supposed requirement is removed. Check whether the old warning is withdrawn and whether any remaining consequences are explained.

Have activity owners review missed dependencies, unsupported connections, stale warnings and incorrect decision ownership. A graph validator cannot substitute for that review. Track correction effort before drawing conclusions about productivity.

The first deliverable can be modest: one process, a handful of evidenced dependencies, and a screen that lets an owner move from a warning to the exact relationship behind it. Expand when those explanations remain useful as the plan changes.

Ego Browser: give the agent a workspace, then check its work

Harshith Vaddiparthy — Tue, 20 Oct 2026 10:45:22 +0000

I've been using Ego Browser since it was released on GitHub. The useful idea is that an agent gets its own browser space while the human keeps their own browsing context.

That is a practical change in how browser automation fits into a working day. An agent can have a task and a set of pages to work through, without that task becoming a pile of tabs in the middle of whatever I am doing.

Ego calls these workspaces Spaces. Its documentation describes separate task tabs with access to the browser's available login state. The agent can use structured page snapshots, navigate, click, fill controls and capture screenshots. The visible agent cursor and action labels help a person follow the interaction.

Start with one question and a result you can inspect

A good first task is small and read-only. For example:

Compare these three product pages. For each product, find the supported operating systems, whether data export is documented, and where the pricing is explained. Return a table with a source URL for every answer. If the page does not answer a question, say that. Do not sign up, submit a form or change any account settings.

This task has a clear end. It also gives me something to check: each answer should agree with its source. A polished summary with no traceable evidence is harder to trust than a modest table that admits what is missing.

The same pattern works for release research. Open the repository, follow the relevant documentation, distinguish released features from roadmap items, and retain the exact sources.

Animation: Ego / Citro Labs, excerpted from the official GitHub demo.

Three useful applications

Research and comparison. Give the agent the same questions for each product or source. Ask it to preserve URLs and uncertainty. This is more useful than asking it to browse broadly and report whatever looks interesting.

Website checks. Pick one journey: find a feature, use a navigation menu, or complete a form in a test environment. Ask for the steps taken, the resulting state and a screenshot of anything confusing or broken. Successful clicking does not establish that the site saved the result correctly.

Content preparation. Gather original sources and relevant screenshots before drafting. Keep the evidence beside the draft so that a factual claim can be checked without repeating the entire browsing session. Preparing an article and publishing it are different actions; authorize the latter explicitly.

These are suggested workflows, not performance results from a benchmark or claims that every website permits automation.

What the animation tells me

A visible cursor and a short action label make the next interaction easier to follow. They help answer: which control is the agent targeting, and what does it think that control will do?

The next question still matters: what happened on the page?

After navigation, check the destination. After filling a field, check its value. After an authorized save, reload and check that the result persisted. An action receipt establishes that an input was sent; it does not establish that the task succeeded.

The accompanying clip is an excerpt from Ego / Citro Labs' official demonstration. It shows the browser's own interaction treatment. The documentation screenshot was captured through Ego on my Mac mini; it is a separate source, not a claim that I recorded the official demo.

Footage: Ego / Citro Labs. The excerpt preserves the browser's actual visual feedback.

A small implementation pattern

On the installed Ego API used for this walkthrough, a task has a persistent space ID and managed page labels. Reuse them across rounds:

const task = await taskSpace("Compare product documentation");
const page = task.page("p1");
await page.goto("https://lite.ego.app/document/en/docs/space");
console.log({ spaceId: task.spaceId, page: page.label });
console.log(await page.snapshot());

Read the current installed Ego guide before adapting this example. Observe the actual page before choosing a click target; do not assume a selector from another site will apply.

Keep the boundary clear: which pages may the agent inspect, which changes may it make, and when should it stop? Separate task spaces organize the work. Account access still needs an explicit scope.

Sources and credits

Product descriptions were checked against the project's documentation. Ego Browser and its interface are the work of the Ego / Citro Labs team.

Before an AI migration, build a behaviour comparison harness

Harshith Vaddiparthy — Tue, 20 Oct 2026 02:43:09 +0000

An AI-generated replacement can compile, start and produce plausible output while changing a business rule. For a migration, the useful question is whether you can identify and explain each observable difference from the old implementation.

OpenAI’s October 19 research on low-resource programming languages distinguishes building new functionality from preserving existing behaviour. MultiLangBench asks models to build a SQLite-compatible engine across 20 languages. A separate evaluation migrates COBOL programs to other languages, with hidden tests requiring byte-for-byte parity on observable outputs. A migration passes only if all its tests pass.

OpenAI reports 86.6% accuracy for GPT-6.1 Sol at low reasoning effort on that migration evaluation and 97.9% at higher effort. Those are benchmark results, not a forecast for your repository. The announcement explicitly retains expert review and testing against production business rules and dependencies.

Here is a small migration workflow I would use to make those distinctions operational. It is a proposed implementation approach, not a reproduction of OpenAI’s evaluation or a tested production framework.

Start with an observable boundary

Choose a routine whose inputs, outputs and side effects you can isolate. A record-processing batch is a better first unit than an entire application with loosely understood integrations.

Write down:

Input format, encoding and missing-value conventions.
Output format, precision and ordering rules.
Error codes and rejected-record behaviour.
State changes, messages and other externally visible effects.
Environment assumptions such as timezone, locale and dependency versions.

The point is to define what a comparison will cover. A matching output file says nothing about an unobserved message sent twice.

Separate parity from intentional changes

Create a fixture directory with input and expected-output files from an approved, isolated run of the old implementation. Use synthetic or appropriately protected data. Pin the old executable and its environment so that the reference result is reproducible.

Alongside the fixtures, keep a small decision ledger:

# Illustrative structure; identifiers and values are hypothetical.
case_id: positive_fraction_boundary
rule: retain_two_decimal_places
old_result: "12.34"
decision: preserve
approved_result: "12.34"
owner_role: financial_process_owner
reason: preserve_existing_contract

OpenAI’s article supplies the mechanism behind this example: COBOL fixed-point arithmetic discards excess decimal digits unless rounding is requested. For a hypothetical positive value of 12.349, discarding excess digits gives 12.34; rounding to the nearest hundredth gives 12.35.

A replacement that chooses the second result can run perfectly well. Whether that difference is a regression depends on the requirement. If the owner approves a rule change, record it separately and retain the old expected result as historical evidence.

Avoid quietly regenerating all expected files from the new implementation. That can turn the code being evaluated into the authority for its own correctness.

Make the first comparator deliberately strict

For a byte-oriented interface, a basic file comparison is useful. The following standard-library script compares two existing files and reports a mismatch. It does not execute either program, validate business correctness or prove migration completeness.

from pathlib import Path
import sys


def main():
    if len(sys.argv) != 3:
        raise SystemExit("Usage: compare.py expected.bin actual.bin")

    expected = Path(sys.argv[1]).read_bytes()
    actual = Path(sys.argv[2]).read_bytes()

    if expected != actual:
        first = next(
            (i for i, (left, right) in enumerate(zip(expected, actual))
             if left != right),
            min(len(expected), len(actual)),
        )
        print(
            f"Mismatch at byte {first}; "
            f"expected length={len(expected)}, actual length={len(actual)}"
        )
        return 1

    print("Outputs match byte for byte")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Start strict so differences become visible. If a format permits harmless differences, such as a field order that consumers explicitly do not depend on, define a narrow semantic comparison for that field. Keep the original output files. Broad whitespace stripping or sorting can hide changes that matter to a downstream consumer.

For the initial fixture set, include normal records and examples around the actual workflow’s boundaries: empty input, missing references, repeated records, date transitions and decimal precision. A passing set establishes evidence for those cases; it does not establish universal equivalence.

Inspect failures as part of the interface

Run the candidate in a sandbox with live writes disabled. Observe exit status, output files, state changes and attempted side effects. Use captured or simulated dependency responses to investigate retries and partial failures where appropriate.

Classify each discrepancy against the decision ledger: a candidate defect, an explicitly approved change, an unstable test environment or an unresolved requirement. Keep unresolved cases visible. An unexplained difference should not disappear behind a passing aggregate percentage.

Finally, measure generation effort separately from investigation, review and integration work. A lower API bill is one cost component. It does not tell you how much work remains to understand undocumented behaviour.

The first deliverable I would ask for is one isolated routine, a repeatable fixture set and a reviewed list of differences. That gives a team concrete evidence for deciding whether to expand the migration.

What an AI work-week review taught me about prototypes and finishing

Harshith Vaddiparthy — Mon, 19 Oct 2026 14:43:46 +0000

I asked AI to review a partial record of my work week, and the most useful result was a development pattern: I keep turning explanations into tools.

During workshop preparation and delivery, an idea would become an interactive analysis view, a small campaign workspace, or a reusable project. A working example makes the inputs, calculations and limits visible. It also creates another implementation to maintain.

Give the prototype one job

For a teaching tool, I want a learner to change an input and understand one consequence. That is a useful scope boundary. If I need ten minutes to explain the interface before the concept, the prototype has become another lesson.

The same rule applies to a product spike. State the decision it should resolve before choosing the framework or building the shell.

Review a real artifact early

One presentation grew to 44 slides. Reviewing the deck made the problem concrete: I wanted a practical demonstration-led session and a maximum of 15 slides.

For software, a small working surface plays the same role. It lets a reviewer inspect what expands, what survives navigation, what state is visible, and what happens next. A rough implementation can improve the brief, provided it is small enough to change cheaply.

Separate activity from completion

My history contained repeated visits to builds, renders and release sessions. An open terminal tells me a process was visible. It does not prove a feature works in the destination environment.

For a development task, I would keep a completion note like this:

Changed: the specific behaviour the user can now exercise

Inspect: the artifact, route or revision that demonstrates it

Evidence: the check actually performed against that result

Remaining: any unfinished dependency or limitation

A prototype checked with example records should say so. A video render still needs review. A release receipt should agree with the live page.

Use the history as evidence, then challenge the interpretation

The review covered available activity from October 12–19, 2026. It was not a complete time audit. A visible window cannot establish attention, and a long sequence of events cannot establish useful output.

I found it useful to ask what repeated, check that reading against the work itself, and choose one adjustment. Mine is making the finish condition explicit before opening the next build.

There was also a television that became a Jarvis project. Apparently my side quests now need repositories.

The habit I want to keep is making ideas tangible. The habit I want to improve is deciding which ideas deserve implementation today.

Read the original work-week reflection: https://www.harshith.com/blog/ai-reviewed-my-work-week

More field notes in The H Letter: https://www.harshith.com/newsletter

Four UI projects, four different jobs for the interface

Harshith Vaddiparthy — Sun, 18 Oct 2026 06:53:40 +0000

I’ve brought four of my projects into a UI gallery: an image editor, a content dashboard, a video-workflow canvas and a CRM. Each study includes real application screens, design decisions and links to the implementation.

The gallery itself is open source. It is a small React application you can run locally. The four applications remain in their own repositories, with their own setup instructions and MIT licenses.

These are the decisions I wanted each interface to make easier.

Grain Studio: judge the image while changing it

An image-effects tool needs a short feedback loop. Grain Studio keeps the image stage, texture dock and material controls in the same workspace. Its before-and-after scrubber lets you compare the effect while you tune it.

Export introduces a different set of decisions: format, dimensions and transparency. I gave those choices a dedicated flow with progress and cancellation states. The source uses Canvas 2D for the preview and a bounded OffscreenCanvas worker on supported browsers for export.

The reusable pattern is to keep comparison close to the adjustment and make output choices explicit at export time.

This capture uses the included sample artwork. The behavior was independently implemented after studying Textures; the dock’s proximity and tactile feedback are informed by ThreeUI Community, with its notice retained.

Inspect the case · Read the implementation

AI Content Dashboard: make content states easy to scan

The working sequence is brief → draft → review → library. The overview helps someone understand the collection; the library provides type and status filters; the editor gives an individual piece a focused working area.

The same content model feeds summary metrics, activity charts and recent-content rows. Reusing type and status labels across these views keeps the navigation predictable. A person can move from an overview count to the actual pieces behind it.

This is built on shadcn/ui, Base UI and the tweakcn Caffeine theme. The screenshots use fictional sample content and illustrative metrics. The source README distinguishes the implemented writing workflow from planned video-rendering and database integrations.

Inspect the case · Read the sample-data model

UGC Genie: show where work is in the process

UGC Genie connects product input, visual analysis, creative direction, generation, rendering and review. React Flow supplies the canvas; the application defines the stages and their state.

The source initializes every step explicitly:

export function createSteps(): WorkflowStep[] {
  return workflowDefinition.map((step) => ({ ...step, status: "pending", progress: 0 }));
}

That gives the interface a clear vocabulary: pending, running, completed and failed. The canvas can show which stage is active while the input and output-review areas remain available alongside it.

The screenshot shows a simulated, credit-free local demo. Its displayed progress describes application stages. The visual foundations include shadcn/Base UI and tweakcn claymorphism; my work is the workflow composition, feedback and review experience.

Inspect the case · Read the stage definition

PulseCRM: bring context to the next action

Sales work needs the pipeline, a record’s history and a useful next step. PulseCRM brings pipeline health, priority deals, account activity and follow-up work into one navigation system.

I adapted shadcn’s sidebar-07 into the CRM shell. Sales Copilot suggestions remain review-required, so record summaries and follow-up drafts have a clear human review step.

Preparing this case also exposed a small implementation bug: --font-sans referred to itself. I corrected it to the Geist font variable supplied by the layout, rebuilt the application and recaptured the interface. The linked source includes that fix.

These screens use bundled demo records in an isolated environment. The source also includes a separately configured Supabase-backed path.

Inspect the case · Read the captured revision

Explore an interaction in the code

For each study, start with one control and follow it through the implementation:

What decision is the person making?
Which state changes when they act?
What feedback makes that change clear?
How does the screen handle loading, empty and failed states?

The gallery credits the component libraries and visual foundations used in each project. Keep the original copyright, license and third-party notices when reusing the source. Individual applications have their own runtime and provider requirements; the gallery itself needs no API key or database.

Browse the interface studies or run the gallery from GitHub.

Build an Independent Attempt into Your AI Training App

Harshith Vaddiparthy — Sun, 18 Oct 2026 02:44:24 +0000

If your AI training app marks a lesson complete when a conversation ends, its completion record tells you very little about what the learner can explain or apply.

A useful alternative is to model guided practice and independent assessment as separate activities. Keep the learner's first attempt, any assistance they received, and the subsequent review distinguishable. That gives a reviewer something concrete to inspect without treating the assistant's confidence as a competence score.

This design is inspired by OpenAI's October 15 article, “Teaching students to think and learn through questions”. Its classroom example has students explore evaporation with Study Mode, then write an explanation and a discussion question without referring back to the conversation. The teacher uses those responses to identify what to revisit.

OpenAI also suggests that teachers try familiar subjects first and assess whether the questions and explanations suit their class. The article does not establish the effectiveness of a workplace training application. What follows is a proposed software design based on that exercise, with explicit limits on what its records can prove.

Start with an observable decision

Define a small learning target before building a chat interface. For a hypothetical internal support course, the target might be: “Identify which team should review an account-access exception, using the approved support guide.”

The exercise needs a reference version, a reviewer-approved case, and expected reasoning. Avoid asking a model to invent the organization's policy or grade against a standard it generated during the same conversation.

Keep the reference and case versions attached to the attempt. If the policy changes later, the reviewer should be able to see which version the learner was given. A version identifier is useful only if it points to content your system actually retains.

Separate the stages in the application

A small state model is sufficient:

Stage	Learner experience	Record
Guided practice	Answer questions, request hints, read explanations	Practice case and assistance events
Independent attempt	Read a fresh case and explain a decision	Initial answer and assistance status
Review	Receive feedback from a qualified reviewer	Reviewer, rubric findings, unresolved points
Revision	Consult the reference and revise the answer	New answer linked to the initial attempt

The independent case should differ from the practice case in one meaningful condition. In the hypothetical support course, the practice case could have all required identity evidence. The second could have missing evidence and an urgent request. The approved guide determines what happens next; urgency should not become an invented exception.

Show the independent case on a separate screen without the practice transcript or generated hints. Explain the purpose of that short attempt before the learner starts. If they request help, make it available through an explicit action and record that the attempt became assisted.

Hiding a transcript in your application does not prove that the learner used no other resources. Report the condition your application provided and the assistance it observed. Avoid describing this as a secure examination system.

Preserve the first answer

Here is an illustrative record, not a platform API or a complete production schema:

{
  "attempt_id": "attempt-101",
  "exercise_version": "support-routing-v3",
  "reference_version": "support-guide-v8",
  "case_id": "missing-evidence",
  "stage": "independent_attempt",
  "assistance": "none_observed_in_app",
  "answer": "The required evidence is missing. I would route this for review using the owner named in the guide.",
  "review_status": "pending",
  "revises_attempt_id": null
}

When the learner revises, create a new answer record linked to the original. Do not overwrite the initial explanation and then report the revised answer as unaided performance.

Similarly, keep an assistance event separate from answer content. An event can record that a hint was requested, when it was provided, and which attempt it belonged to. Only retain the content you need under your organization's data policy; these records are for learning review, not an excuse to collect unrelated employee activity.

Keep transitions under application control

The application should decide which actions are available at each stage. A learner's answer or pasted reference is data; it should not be able to mark an attempt reviewed or change the recorded assistance status.

If you use a model to propose feedback, save that feedback as a suggestion awaiting review. For this design, a qualified reviewer makes the competence decision. The distinction should be visible in the interface and enforced wherever state changes are accepted.

Keep submission handling predictable. A repeated submit for the same attempt should return the existing result, rather than creating multiple initial answers. Persist the answer before showing the confirmation. If a response is lost, the client should be able to retrieve the recorded attempt and display its actual state.

These are implementation recommendations, not claims about how Study Mode works internally.

Review reasoning, evidence, and boundaries

Use a short rubric that asks whether the answer identifies the applicable rule, cites the relevant evidence, notices the changed condition, and recognizes any unresolved question or need for review.

An answer that admits a specific uncertainty can reveal a useful learning gap. An answer that invents an owner or exception deserves different feedback, even when it sounds fluent.

Avoid compressing everything into a single model-generated score. Store the reviewer's findings by criterion and the reference supporting each correction. A later reviewer can then understand why the learner was asked to practise again.

Verify behavior with a few meaningful cases

Before piloting the app, check these situations:

A hint request during the independent stage changes the assistance record before the answer is assessed.
A revised answer preserves the initial attempt and links back to it.
Repeated submission creates one initial answer record.
Text inside an answer cannot change review status or the reference version.
Feedback distinguishes an incorrect decision from a reference that does not resolve the case.

Start with one approved exercise and inspect the resulting records with a knowledgeable reviewer. The initial outcome you can honestly report is what the learner explained under the observed conditions, what help they requested, and what changed after feedback.

That is useful evidence for deciding the next practice. Establishing lasting competence requires more than one interaction, especially when the real task has meaningful consequences.

What is an AI agent harness?

Harshith Vaddiparthy — Sat, 17 Oct 2026 23:26:01 +0000

By Harshith Vaddiparthy. Originally published in my AI agent harness guide.

An AI agent harness is the software around a model that lets it do work: supply the right information, offer tools, enforce permission rules, return results, and decide when to continue or stop. The model helps choose the next action. The harness connects that choice to an actual environment.

The walkthrough uses real software footage, fictional expense data, and my AI avatar and cloned voice. The transcript is available below without signing in.

That distinction matters when you are choosing an AI tool. A model name does not tell you whether the application can read your files, preserve the originals, ask before saving, recover from a failed action, or prove that the final result is correct. Those are properties of the complete system.

I recorded the walkthrough above to make those moving parts visible. The task is deliberately ordinary: read a small file of fictional expenses, calculate spending by category, flag a missing category, and save a short summary. There is no real financial account or customer data in this example. A small, inspectable task makes the boundary between a convincing answer and completed work much easier to see.

Model, tool, harness: three different jobs

The pieces of the expense demonstration

Piece	Its job	What to inspect
Model	Interprets the request and proposes the next response or action.	Did it understand the missing-category rule?
Tool	Performs a specific operation outside the model.	Which file did it read, or which calculation did it run?
Harness	Connects instructions, context, tools, permissions, and results.	Which actions are available, which are blocked, and what evidence returns?

The recorded application is DeepSeek Harness. In the interface, a conversation sits beside file tools and permission controls. You do not need that particular application to use the evaluation method. What matters is being able to inspect the input, the action, its result, and the boundary around it.

This general pattern also appears in Anthropic's guide to building effective agents: the model uses tools, receives feedback from the environment, and continues until it completes the task or reaches a stopping condition. The useful part is the feedback. Each step can give the system new evidence, rather than requiring it to finish everything from its first guess.

Start with a task whose answer you can check

My input contains 12 expense records. Eleven have a category. One does not. The instruction is explicit: retain that record, group it separately, and flag the missing category. Do not invent a label, delete the row, or quietly change the original file. The amounts are fictional and have no assigned currency.

Expected totals from the original 12 records

Category	Amount
Software	78.00
Supplies	46.00
Travel	86.00
Uncategorized	17.00
Grand total	227.00

The uncategorized amount is part of the 227.00 total. It is not an extra amount to add afterward. This is a small detail with a large lesson: handling uncertainty is part of the task definition. If I only asked for a tidy report, a plausible-looking classification could conceal the very exception I need to review.

Before running an agent, I want three things written down: the input it should use, the output I expect, and the rule for anything uncertain. For this task, that means the expense file, a category summary, and an explicit uncategorized group. A stronger prompt helps, but the application must still load the right files and enforce the allowed actions.

Follow the activity between the prompt and the answer

After submitting the task, I open the tool details. The first useful question is whether the agent read the intended input. A polished summary is weak evidence if I cannot connect it to the source records. The activity view should identify the action and show a result that I can interpret.

Read: The application supplies the instructions and the expense records through file tools. Check the file identity and the returned data.
Calculate: A verification command computes category totals, the grand total, and the number of records with a missing category. Inspect the actual output.
Propose: The model uses those results to prepare the summary. Compare its claims with the original input and the calculation.
Save and reopen: After the specific write is authorized, inspect the file that was actually saved and run the post-write check.

This is the agent loop in practical terms: choose an action, act through a tool, inspect what happened, and choose the next step. A tool request is not the same thing as a successful action. A planned save is not a saved file. A result saying that no summary exists yet is useful information, even when the arithmetic has already passed.

The harness should preserve those distinctions. If it reports every tool request as a success, the model may continue from a false premise. If it hides a failed write behind a generic error, recovery becomes harder. Clear results help both the model and the person reviewing the work understand the current state.

A saved file is not automatically remembered

Context is the information the model receives for the current step. In this example, the expense records and the rule for blank categories are relevant context. Unrelated files and old conversations are not automatically helpful. The harness decides what to load, what tool results to retain, and how to manage limited context space.

For longer tasks, the application may summarize earlier conversation or retrieve only selected material. That can keep a task moving, but summaries can drop detail. I prefer important facts and decisions to live in an artifact that can be reopened: the original data, a written instruction, or a checked output.

Persistence and retrieval are separate steps. The saved summary can survive the chat, but the next model response will not know its contents merely because it exists somewhere on disk. The system has to load it again. When someone says an agent has memory, ask what is stored, how it is retrieved, and how you can tell that the current response actually used it.

Approval and a sandbox answer different questions

In the recording, the initial write is blocked by the read-only setting. The agent then requests one-time permission to save the summary. I inspect the destination and the proposed content before allowing that action. The original expense file remains unchanged.

This demonstrates an application permission boundary. It does not demonstrate an operating-system sandbox. Approval answers whether a particular action may proceed. A sandbox limits which resources the execution environment can reach. A prompt saying 'do not touch other files' is neither a permission implementation nor proof of isolation.

For a learning exercise, the practical choice is a small disposable workspace with fictional inputs and only the capabilities needed for the task. Reading a file, creating a new summary, modifying the source, and sending the result to another person are different actions. Permission for one should not silently imply permission for all four.

Check what was saved, not just what was said

Once the summary is saved, I reopen it. The checker compares its category totals, grand total, and missing-category record count against the source data. In this example, those checks pass. That is stronger evidence than the final chat message saying the task is complete, because it tests the artifact I will actually use.

The limit matters just as much as the pass. This checker does not verify every sentence, decide whether an expense is legitimate, or tell me which category the blank row should have had. Correct arithmetic over incorrect source data would still be incorrect business information. The scope of a check determines what its result supports.

Input preserved. The original records remain intact, so the output can be traced back to them.
Exception retained. The 17.00 blank-category record remains visible instead of being guessed away.
Output reopened. The saved artifact exists and can be inspected independently of the chat response.
Checks named. A passing calculation has a specific meaning; it is not a blanket guarantee of correctness.

Four questions to ask of any agent

I use four questions to evaluate the complete system. What information can it see? Which actions can it take? How is the result checked? Where must it stop? These questions are useful even when you have no interest in building the harness yourself.

Take a weekly report as another example. The agent might be allowed to read a folder of approved inputs and draft a summary. Its check could reconcile totals and link each factual claim to a source. Its stopping point could be the reviewed draft. Publishing the report would remain a separate decision. That is a clearer design than asking an agent to 'handle reporting' and discovering its interpretation afterward.

Try the method on one small task

Choose a small set of fictional or non-sensitive records whose expected result you can calculate yourself. Use an agent application that exposes its tools and lets you restrict writes. Adapt this task brief to the capabilities it actually has. If it cannot show a tool result or enforce a permission boundary, record that limitation instead of assuming it exists.

A task brief you can adapt

Read the supplied expense file and preserve it unchanged.
Calculate totals by category and a grand total.
Keep blank categories in an Uncategorized group and report their count.
Show the calculation evidence and a proposed summary.
Do not save or send anything yet.
After I approve one destination and the summary, save that file only.
Reopen the saved file and compare its totals with the source.
Report which checks passed, which were not performed, and stop.

Then change one input deliberately: remove a category, add a row, or supply a destination the application is not allowed to write. Does the system retain the uncertainty, notice that the expected total changed, or stop at the boundary? A small controlled failure can teach you more about an agent than another polished demonstration.

You do not need a multi-agent architecture to learn this. Start with one task, a few tools, and one visible completion check. If you want to understand the implementation after that, my guide to building a coding agent from scratch explains the loop and the operating machinery around it. If you want more practical field notes like this, subscribe to The H Letter.

Sources

My recorded AI harness walkthrough

The fictional expense task, tool activity, blocked write, one-time approval, and saved-file check shown in this article.

Anthropic: Building effective agents

Primary guidance on tools, environmental feedback, stopping conditions, and human oversight. It supports the general pattern, not a security certification of this demonstration.

Frequently asked questions

Is an AI harness the same thing as a model?

No. The model produces responses and requests actions. The harness is the surrounding software that supplies context, exposes tools, applies permission rules, runs permitted actions, and returns observations. The same model can behave differently in two applications because those surroundings differ.

Does an approval dialog mean an agent is sandboxed?

No. Approval decides whether a particular action may proceed. A sandbox limits what an execution environment can reach. The walkthrough demonstrates an application permission boundary; it does not demonstrate an operating-system sandbox.

Does saving a file give an agent permanent memory?

Saving creates a durable artifact. The model can use that artifact in a later response only if the system loads its contents into the context it receives. Persistence and retrieval are different steps.

Full transcript and downloads

The complete transcript follows. You can also read it alongside the video in the original guide or download a copy:

0:00: What makes an agent work

When an AI reads a file, uses a tool, and checks a result, the model is only part of what you're seeing. The surrounding software makes that work possible. That surrounding system is called a harness. I'm going to show you one real task, and point out the pieces that make an agent useful.

0:18: The model and its harness

I'm using DeepSeek Harness, a real agent app with a conversation and tools for files. The model is one component inside this application. The instructions, available tools, and permission settings all affect what the complete system can do. The name in the model selector does not tell you everything about what the complete system can accomplish.

The model chooses what to say or which action to request. A tool does something outside the model, such as reading a file. The harness connects those pieces. It supplies context, makes allowed tools available, runs permitted actions, and returns their results.

The model can then use that new information to decide what to do next.

0:59: Give it the right context

For this task, I have a small file of fictional expenses. The goal is to calculate spending by category, flag anything that needs attention, and create a short summary. First, look at the information we are giving the agent. The file contains the original records.

The instructions say how to handle a blank category: keep the record, group it separately, and do not guess. We also tell it to preserve the input instead of quietly changing the source. These details are context: the information available to the model for this job. More context is not automatically better.

Unrelated files and old conversations can distract from the task. A useful harness helps select the relevant instructions and evidence, within the scope we allow. For longer tasks, a harness also has to manage limited context space. It may select earlier results or summarize older conversation.

Summaries can lose detail, so keep critical facts in an artifact you can reopen. The file is durable; whether the next response uses it depends on what the system actually loads. Before pressing send, check that the request names the input, the expected output, and the rule for uncertainty. That makes success something we can actually inspect.

2:19: Follow the real tool loop

Now we submit the task. Watch the activity between the prompt and the final response. The agent requests a tool, and the application performs the action. Opening the tool details lets us see which file it read and what information came back.

We can see what it actually read. The model uses that result to choose its next step. If it needs another file or a calculation, another tool request can follow. This is the basic agent loop: decide, act through a tool, inspect what happened, and continue.

This example uses files and a calculation. Those capabilities come from the integration around the model, and they should be limited to what the task needs. Installing a connector does not mean the agent should have unrestricted access. The loop does not guarantee that every decision is correct.

It gives the system a way to work with evidence instead of stopping at a single response. In this example, the useful evidence is the original expense data and the calculations made from it. We can follow the activity and compare the proposed summary with those records. Notice that an empty category is still something to flag, not an invitation to invent a label.

Check whether the actions and results support the answer.

3:35: Check the result and the boundary

Before accepting the summary, we check it against the original data. First, the calculator totals the source records. At this stage, it correctly reports that no summary has been saved. The expense with a missing category must remain visible in that check. Twelve records total two hundred and twenty-seven, including seventeen without a category.

The calculated totals match the source records; that is evidence for this calculation. Now look at the write boundary. Reading the input and saving a new file are different actions. The first write is blocked by the read-only setting. The agent then asks for one-time permission to save this summary.

Here, the application restricts which files and command the agent can use, and asks before writing this summary. This demonstrates an application permission boundary. An operating-system sandbox is a separate boundary, and we have not demonstrated one here. Inspect the proposed destination and contents before allowing this specific action.

After the file is saved, reopen it and confirm what actually exists. The checker compares the saved category totals, grand total, and the count of records missing a category against the source. A pass supports those checks; it does not verify every sentence in the report. That final readback matters more than a message saying the work is done.

Saved files only become context when the system loads them again. Approvals and sandboxes also do different jobs. An approval asks whether an action may proceed. A sandbox limits what the execution environment can reach.

Always check what is actually enforced.

5:22: Judge the whole system

The original file is unchanged, the totals have been checked, and the saved summary can be reopened. Following those steps gives us a practical way to evaluate the system. When you evaluate an agent, ask four questions. What information can it see?

Which actions can it take? How is the result checked? And where must it stop? Those questions tell you much more than the name of the model alone.

Try this with one small task of your own. Follow the actual steps, inspect the output, and identify one check you would want before trusting the result.

Version AI Outputs Before People Rely on Them

Harshith Vaddiparthy — Tue, 13 Oct 2026 02:45:50 +0000

A generated analysis can change after somebody has already acted on it. If your application overwrites the output in place, a later reviewer cannot reliably reconstruct which recommendation the person saw.

OpenAI’s October 6 mathematics release offers a useful engineering prompt. The announcement describes manuscripts, Lean formalizations of many proofs, reasoning summaries and information about attempted problems. The repository says corrections become new versions while earlier released versions remain accessible.

It also says results are at different verification stages, not all have accompanying formalizations, and some unformalized results could have issues. This article does not validate those mathematical results. The design lesson I am taking from the release is narrower: preserve the specific artifact that a review or decision refers to.

Separate a result from its revisions

For an AI-assisted report, keep a stable result ID and a separate revision ID. The result ID identifies the continuing task; the revision ID identifies one frozen output and its associated evidence.

A minimal record could contain the artifact digest, creation time, prior revision, reason for the change, source references and review status. Record model and prompt versions when available and relevant to reproducing the process. Do not claim that these fields make a nondeterministic generation reproducible by themselves.

Keep the output file and its receipt together. If somebody changes an assumption or conclusion after handover, create a new revision. The old revision remains the object of any earlier review. “Latest” can be a convenience pointer, but it should not be the identifier saved with a consequential decision.

Bind a receipt to exact bytes

Here is a small Python example using only the standard library. Run it in a temporary working directory. It creates a new directory for each revision and refuses to reuse an existing revision name.

from hashlib import sha256
from pathlib import Path
import json


def save_revision(root, revision, text, *, previous=None, reason):
    if not revision.isalnum():
        raise ValueError("Use an alphanumeric revision ID")
    if previous is not None:
        read_revision(root, previous)
    folder = root / revision
    folder.mkdir()  # Existing revision names are never overwritten.
    payload = text.encode("utf-8")
    (folder / "output.txt").write_bytes(payload)
    receipt = {
        "revision": revision,
        "previous": previous,
        "reason": reason,
        "artifact_sha256": sha256(payload).hexdigest(),
        "review_status": "not_reviewed",
    }
    (folder / "receipt.json").write_text(
        json.dumps(receipt, indent=2), encoding="utf-8"
    )
    return receipt


def read_revision(root, revision):
    if not revision.isalnum():
        raise ValueError("Use an alphanumeric revision ID")
    folder = root / revision
    receipt = json.loads((folder / "receipt.json").read_text("utf-8"))
    payload = (folder / "output.txt").read_bytes()
    if receipt["revision"] != revision:
        raise ValueError("Revision identity mismatch")
    if sha256(payload).hexdigest() != receipt["artifact_sha256"]:
        raise ValueError("Artifact differs from receipt")
    return payload.decode("utf-8"), receipt


root = Path("revisions")
root.mkdir(exist_ok=True)
save_revision(root, "v1", "Supplier covers region A.",
              reason="Initial unreviewed analysis")
save_revision(root, "v2", "Supplier excludes region A.",
              previous="v1", reason="Corrected coverage assumption")
assert read_revision(root, "v1")[0] == "Supplier covers region A."
assert read_revision(root, "v2")[1]["previous"] == "v1"

The example demonstrates an application convention and a byte-integrity check. It is not an immutable storage system. A person with filesystem write access can change both files, and a digest does not authenticate the author or establish that a claim is true.

There is also no transaction across the two file writes. An interrupted save can leave an incomplete directory; the reader fails instead of treating it as a valid revision. A service implementation needs a transaction or an explicit completed state, appropriate permissions and a recovery process. Keep those requirements separate from what this short example proves.

Store review decisions separately

A reviewer should reference the revision ID and artifact digest they actually inspected. Keep the reviewer identity, time, intended use and scope of checks in a separate review record.

For example, “arithmetic checked against supplied spreadsheet” is narrower than “recommendation approved.” If the spreadsheet itself has not been verified, that uncertainty should remain visible. A changed output should get a new review decision; copying an earlier approval onto the new revision would erase the very boundary the receipt is meant to preserve.

Do the same for inputs that can change. A source URL alone may later show different content. Where you are permitted to retain it, capture the relevant source version or snapshot and its timestamp. For private material, use restricted references and your existing retention rules. Do not turn a review feature into an uncontrolled copy of confidential documents.

Track the consequences of a correction

A revision chain says what came before. It does not tell you who acted on it.

If a report informs a consequential action, store that action’s reference to the specific revision. When an assumption changes, those references help identify decisions requiring another look. The correction event should describe the changed assumption and its possible consequence, rather than silently regenerating every downstream artifact.

Avoid auto-invalidating every decision merely because wording changed. Define which changes require review for your use case: a different source, an altered calculation, a changed eligibility assumption or a reversed recommendation may matter more than an editorial fix.

Test the handover, not just the happy path

Useful checks include retaining access to the earlier output after a new revision, refusing accidental reuse of a revision name and detecting an output that no longer matches its receipt. Test an interrupted write too: incomplete data should be visible as an error, not accepted as a completed record.

If you also evaluate generation quality, keep task IDs distinct from attempt IDs. OpenAI’s repository reports attempted problems and groups outputs into manuscripts and families; those different units do not support a simple success-rate division. In your own pilot, attach retries to the original task and define what counts as a usable result before comparing runs.

Start with one report or generated analysis that already crosses a team boundary. Save the revision people use, attach the scope of review, and make the next correction explicit. You can improve the storage architecture later; first make it possible to answer which version somebody trusted.

Gate AI Workflow Acceptance on Mandatory Checks

Harshith Vaddiparthy — Mon, 12 Oct 2026 02:54:37 +0000

An agent can configure most of a workflow correctly and still leave a required approval broken. If your evaluation reports only an average score, that failure can disappear inside an encouraging number.

OpenAI's October 6 publication, Advancing computer use with Ironclad, makes this a concrete engineering problem. The researchers worked with practitioners to define 11 tasks across legal, commercial and procurement work, with 8 to 50 evaluation criteria per task.

OpenAI reports mean rubric scores of 55.0% for GPT-6 Astra at Max reasoning and 41.6% for GPT-5.6 Sol at High reasoning. Those averages describe criteria met, not the percentage of workflows completed perfectly. The reported 19.2 versus 37.0 minutes per attempt are simulated estimates, not measured customer savings. The results cover those 11 research tasks, not every Ironclad workflow.

The implementation lesson I take from this is to separate a score that measures progress from the conditions that permit a workflow to be used. The design below is my proposed pattern, not a description of Ironclad's implementation.

Start with a versioned requirement

Suppose a fictional purchasing policy requires Finance approval for amounts strictly above USD 10,000, excluding tax. A real owner would need to confirm those details; they should not be invented by the agent.

Represent the amount in cents for this example, so the boundary is 1,000,000. Then define observable cases:

999,999 cents follows the ordinary path.
1,000,000 cents follows the ordinary path because the rule says strictly above.
1,000,001 cents requires Finance approval.
A missing amount remains incomplete rather than silently taking the ordinary path.
Editing an existing request across the boundary triggers the review behavior specified by the owner.

The last two cases are additional proposed requirements. They need agreement before implementation. Their purpose is to expose ambiguity rather than turn an assumption into policy.

Attach the accepted cases to a configuration version. A passing observation from yesterday's configuration should not authorize today's changed one.

Keep mandatory checks separate

A rubric can measure helpful labels, document quality and configuration details. Maintain that score for comparisons and debugging. Separately keep an explicit set of mandatory check IDs selected by the process owner.

Here is a small Python gate for observations collected by a trusted test runner. It accepts only explicit passes with an evidence reference for the requested version. Missing, stale or inconclusive observations remain unverified.

def acceptance(required, observations, version):
    if not required:
        raise ValueError("Define mandatory checks before evaluation")

    failed = []
    unverified = []
    for check_id in sorted(required):
        row = observations.get(check_id)
        if (not row or row.get("version") != version
                or not row.get("evidence")):
            unverified.append(check_id)
        elif row.get("status") == "fail":
            failed.append(check_id)
        elif row.get("status") != "pass":
            unverified.append(check_id)

    return {
        "ready": not failed and not unverified,
        "failed": failed,
        "unverified": unverified,
    }

There is deliberately no aggregate score in this decision. A high score for optional checks cannot cancel a failed mandatory check. Both failed and unverified conditions prevent ready from becoming true, while remaining distinct in the report.

For example, these are synthetic fixtures demonstrating the gate's behavior, not evidence from a real workflow:

required = {"above_threshold", "missing_amount"}
observations = {
    "above_threshold": {
        "status": "pass",
        "version": "config-7",
        "evidence": "fixture:above-threshold",
    }
}

result = acceptance(required, observations, "config-7")
assert result["ready"] is False
assert result["unverified"] == ["missing_amount"]

An empty required set raises an error because an accidentally empty checklist should not produce a passing result. An unexpected status also remains unverified. This function assumes the input mapping follows the shown schema; validate untrusted input at the boundary before calling it.

Collect observations outside the agent's narration

The gate above checks references and statuses. It does not prove that a referenced artifact exists or that the result is true. If the same agent can invent observations or rewrite the mandatory set, the gate offers little assurance.

Have a separate test controller submit known requests in a safe environment and read the resulting route or approval state. Save the request ID, tested configuration version, input, expected outcome, actual outcome and supporting evidence. Check that the evidence reference resolves to the observation for that exact case and version before passing it to the gate.

Use screenshots when visual context matters, but capture the actual result state too. A screenshot of a rule in an editor establishes what the configuration looks like. A routed test request establishes something different: how that configuration behaved for a particular input.

Preserve failures as reproducible cases. "The agent missed some steps" is difficult to debug. "Increasing a saved request from 900,000 to 1,100,000 cents did not trigger Finance review" describes an input transition and an observable defect.

Recheck after changes

After a configuration change, collect fresh observations for the mandatory cases. Do not reuse an old pass solely because the visible form looks unchanged. Approval routing may depend on fields, conditions or later edits that the screenshot does not reveal.

For a first pilot, a small mandatory suite is more useful than a large collection of vague checks. Add cases when the owner identifies another requirement or a failure reveals a missing boundary. Track the broader rubric alongside it so you can see improvements that do not yet justify acceptance.

Also record the human effort required to reach an accepted result: preparation, review, repair and repeated tests. Keep those measurements separate from model execution time and from the simulated timing in the research.

OpenAI's publication explicitly retains a role for human oversight in complex contracting. This proposed gate does not remove that responsibility. It gives the responsible person a clearer view of what passed, what failed and what nobody has verified yet.

Start with one workflow, one agreed version of its rules and a few meaningful cases. A reliable acceptance decision begins with a precise definition of what the finished system must do.