Cloudflare (Oct 7) describes the multi-agent system behind its Managed Defense alert triage (an early beta). Its first single-agent prototype failed in three ways:

• "Context became authority." A detection is a guess, not proof, and the agent blurred the two.
• "Scope drifted." The agent could query the wrong account, time range or source. "You can't rely on a language model prompt to be a boundary."
• "Failure disappeared." A lookup that timed out looked the same as "checked and not found".

The new design:

• Data collection has no AI in it. Fixed code makes versioned API calls and stores every item with its source, version and timestamp. The same snapshot can be replayed, so when two runs disagree, the cause is interpretation, not different inputs.
• Narrow agents. A coordinator runs 4 specialist agents in parallel (traffic, customer history, global telemetry, threat intel). The agent that combines their findings "can't fetch new evidence or choose a classification outside the approved vocabulary".
• Citations are checked in code. Every finding must cite an item in a versioned evidence package. Code checks that each citation exists, belongs to this investigation and supports the claim.
• Three states for missing data: "not checked", "checked, no match" and "checked, evidence supports absence". When the evidence isn't enough, it makes no classification.
• Tenant scope is fixed in code before any model sees data. The global-telemetry agent sees only aggregates.
• Stages are checkpointed (Cloudflare Workflows), so a failed stage reuses evidence that already passed validation instead of starting over.

Gitea, the self-hosted Git service written in Go, released 28.1.0 on Oct 6. CVE-2026-101023 (GHSA-469m-x4mw-38r3): the OAuth2 refresh endpoint checked a token's signature and grant, but not that it was a refresh token. So an unexpired access token could be exchanged for a new access token and refresh token, which extends a stolen token's life. Affects ≤ 28.0.0; fixed in 28.1.0. Gitea rates it Moderate, and no exploitation is reported.

The same release fixes 8 more CVEs. Several are missing-check bugs:

• The push-mirror API checked the repository owner's permission to use local paths instead of the caller's (CVE-2026-86684).
• Asking for a profile page with an RSS/Atom Accept header returned private users' activity feeds, even with feeds disabled (CVE-2026-97626).
• Push-to-create ignored FORCE_PRIVATE (CVE-2026-89182).

Joshua Oluikpe (InfoQ, Oct 7) describes the Kafka layer he led at an unnamed conversational-AI company. Messages pass through 4 stages, and order must hold within each chat session, while many sessions share each partition. The design:

• Two-level dispatch. Dispatch workers pick a session by consistent hashing on session ID, then hand off to one goroutine per active session. Session goroutines are created on demand and removed when idle. This replaced a flat worker pool where one retrying session blocked unrelated sessions.
• Retry in place. The session goroutine sleeps with exponential backoff and jitter, so "message 4 literally cannot execute before message 3 finishes". Bad messages go straight to the dead-letter queue.
• Commit only the contiguous watermark. Per partition, it tracks in-flight and completed offsets and commits only up to the highest offset with no gaps below it. So a finished 104 can't commit past an unfinished 102. Replay is made safe with stable event IDs, but the author says it is not exactly-once.
• Rebalance drain. Mark the partition as revoking, check in-flight work every 50 ms within the rebalance timeout, commit the final watermark, then release it.
• Backpressure. A non-blocking channel send that fails pauses the partition. Records already fetched are buffered as in-flight, and fetching resumes only after the buffer drains.
• Stuck work. The first detector ("in-flight set never empty") gave false positives under load. Now each offset is timed on its own.

The numbers:

• Synthetic test (c5.2xlarge, 3 brokers, 10 partitions, RF 3): 14,027 msg/s, p99 185 ms, and 0 ordering violations across 50,000 messages with 10 sessions and 10% injected failures.
• Load test (1,000 sessions): 48,805 msg/s with 0 send errors, but p99 2.8 s, which the author blames on an API Gateway quota. Ordering wasn't checked in this run.
• Production: >40M messages, with 460 sent to the DLQ (~0.002%).

Natalie Silvanovich (Google Project Zero, Oct 6) surveys how large vendors fix a few actively exploited bugs faster than their normal update process. Her point: emergency fixes are slowed mostly by testing and delivery, not by triage or writing the patch. Four mechanisms:

• Feature flags. Each flag state can be tested in advance, so flipping one ships no untested code. Example: Meta's "dual stack" WebRTC, which compiles two library versions into one binary and switches between them with a flag. She suggests going further: two different libraries for the same feature, or a hardened build with extra checks.
• Filtering. Rules that can be updated live block the input that reaches a bug. It's more flexible than flags, but costs performance and every new rule needs testing.
• Alternate channels. Shipping single components outside the normal update. These become a vulnerability themselves unless the client checks they really came from the vendor.
• Hotpatching (Linux Livepatch, Windows hotpatch). It solves delivery but not testing, and briefly needs memory that is both writable and executable, which weakens exploit defences.

Her reason: LLMs are speeding up how fast attackers find and exploit bugs, so vendors should plan now.