Tech Radar - 2026-10-10 18:00

Priority Today

GitHub Copilot local sandboxing reaches general availability across CLI, app and VS Code

GitHub made local sandboxing generally available on October 7 in Copilot CLI, the Copilot app, and VS Code sessions using Agent Host, and it is included with a standard Copilot seat at no additional cost. Sandboxing puts the shell commands, file search and, by default, the MCP and language servers an agent launches inside an operating-system sandbox governed by a policy you control, instead of letting them inherit the full access of the account running the CLI.

Why it matters: An agent's shell commands normally run with everything your user account can reach, so a single bad tool call or prompt injection can touch any file, credential or network host you can; moving that boundary to the OS is the difference between trusting the model and bounding it. What changed: The feature graduated from an experimental flag. On macOS the backend is Seatbelt, on Linux bubblewrap and on Windows the BaseContainer tier of Microsoft's open-source MXC library; sandboxed commands get placeholder Git and gh credentials that are swapped for real ones only for approved HTTPS destinations, and by default the working directory is read/write while the rest of the system is read-only or unreachable. Enterprise managed settings can require sandboxing, in which case /sandbox disable is refused unless the effective policy permits a bypass. For me: If you run Copilot CLI on agent-generated code, turn on local sandboxing and inspect /sandbox policy before you trust a repository; the same idea, a policy layer around the agent, is what the AWS Strands Box story below approaches from the other end.

Tags: #topic/ai-coding #topic/security #entity/github #entity/copilot #technology/agent-security #event/tool-release #relevance/developer #learning/awareness

Sources:

Kiro CLI V3 becomes the default, with CLI 3.0 due by end of October

AWS's Kiro began rolling out CLI V3 as its default terminal experience on October 9, bringing the same agent harness that powers Kiro IDE and Kiro Web into the terminal. V3 adds background workflow agents that handle planning, implementation and review in parallel, cloud sessions you can close your laptop on, a spec mode for reviewing requirements and design before code is written, and a tangent mode for branching parallel conversations without polluting the main session context.

Why it matters: The harness now owns tools, context, permissions and model interactions across every Kiro surface, so agent configuration and behaviour travel between the terminal, the IDE and the web rather than being reimplemented per client; workflow agents and tangent mode are the first signs of the terminal agent moving from one serial chat to several supervised workstreams. What changed: A startup prompt invites users to switch ahead of the CLI 3.0 release by the end of October, and you can opt in now with kiro-cli --v3. CLI 3.0 retires inline shell autocomplete and the CLI desktop app, and V3 drops the built-in use_aws tool (AWS access moves to MCP servers), with a V3 session store that cannot be read back in V2. For me: Try kiro-cli --v3 on a non-critical task; if you have customised use_aws allow or deny rules, recreate them as shell permission rules before CLI 3.0 lands.

Tags: #topic/ai-coding #entity/kiro #entity/aws #technology/agent-orchestration #event/agent-release #relevance/developer #learning/awareness

Sources:

Astron Agent CVE-2026-108263: an unsandboxed code node gives any tenant root, then every other tenant's data

CVE-2026-108263, published October 9 at CVSS 9.9, is a cross-tenant remote code execution in iFlytek's Astron Agent agentic workflow platform. Through releases up to 1.1.1, the default workflow code node selects a LocalExecutor (CODE_EXEC_TYPE=local) that supplies full Python builtins with none of the documented sandbox restrictions, so any authenticated low-privilege tenant who can author a workflow runs code as root inside the core-workflow container. From there the shared MySQL, PostgreSQL, Redis and MinIO credentials let the code bypass the console's tenant checks entirely and read, modify or delete any other tenant's data, or drop tables to take the platform down.

Why it matters: It is a near-perfect example of the failure mode agent platforms keep hitting: the documentation claims a sandbox that is not actually a dependency, the insecure path is the shipped default, and isolation fails at the shared-data layer rather than the application layer, so one tenant's code node is every tenant's breach. What changed: Fixed in Astron Agent 1.1.2, which rejects unsafe local execution and enables the built-in isolated LangChain/Pyodide executor by default, tightens Workflow and Tenant API authentication and credential handling, and adds outbound plugin SSRF protection; CODE_EXEC_TYPE=local is no longer supported. For me: If you self-host the docker/astronAgent Compose stack, treat anything below 1.1.2 as compromised, upgrade and set ASTRON_AGENT_VERSION=v1.1.2, and if you cannot upgrade immediately, disable the Code node and restrict workflow authoring to trusted admins.

Tags: #topic/security #topic/ai-agents #entity/iflytek #technology/agent-security #event/security-issue #relevance/developer #relevance/infrastructure #learning/understand

Sources:

Webcmd lets a browser agent learn a site once and replay it as a cheap command

AgentR launched Webcmd on October 8, an Apache-2.0 browser layer that records what an agent observes on a site, pages, states, actions, workflows, APIs, pitfalls and fallbacks, as a local agent-facing sitemap, then compiles repeated knowledge into deterministic CLI commands. It installs with npm install -g @agentrhq/webcmd and requires Node.js 20.6 or later.

Why it matters: Browser agents are good explorers and wasteful repeaters, re-reading the same page and re-reasoning the same workflow on every visit; promoting a learned site into a fixed command is a concrete attack on the token spend that makes long browser-automation runs expensive. What changed: A four-stage model, live browser control, a shared sitemap, authored adapters with structured output, and tailored commands, each layer collapsing cost and variance for the layer above. In AgentR's own published comparison against BU Bench V1 (the browser-use project's 100-task benchmark), Webcmd passed 67 tasks at an estimated $0.255 per completed task and 9.8 agent turns, against $0.297 for browser-use; these are the vendor's numbers, not an independent run. For me: If you run browser automations against the same sites, the idea worth stealing is persisting a site's action space locally so the agent pays for the task and not the navigation; the npm package ships the core but no site adapters, which you install from a plugin catalog.

Tags: #topic/ai-agents #topic/open-source #entity/webcmd #technology/browser-agents #technology/agent-memory #event/open-source-release #relevance/ai-workflow #learning/understand

Sources:

Models and Capabilities

TII ships Falcon-Emirati, Falcon-ASR and Falcon-OCR-Arabic for Arabic and Emirati

Abu Dhabi's Technology Innovation Institute announced three models on October 6: Falcon-Emirati, a 7B model purpose-built for Emirati Arabic; Falcon-ASR, a 1.6B speech recognition model covering Emirati and Modern Standard Arabic plus English, French, Spanish and Portuguese, with per-word timestamps; and Falcon-OCR-Arabic for text extraction from images. TII reports Falcon-Emirati scoring 84.83% on a native Emirati benchmark and Falcon-ASR outperforming a 30B multimodal model on Emirati speech.

Why it matters: It is a reminder that the open-weights race is not only frontier English models: a compact 1.6B ASR model that beats much larger general models on a low-resource dialect, and ships word-level timing, is directly usable for subtitling, transcription and accessibility work that the big labs treat as an afterthought. What changed: Three open models targeting a specific language and dialect, released together with the supporting task, rather than another general-purpose checkpoint. For me: Not urgent unless you handle Arabic or Emirati content; if you do, Falcon-ASR's word timestamps make it worth a look for a self-hosted transcription pipeline.

Tags: #topic/ai-models #entity/tii #event/model-release #relevance/discovery #learning/awareness

Sources:

Agent Capability

BU Bench v2.1 puts browser-agent scores and per-task cost side by side

Browser Use published results for BU Bench v2.1 on October 7, a set of long tasks run on live websites in its open-source BrowserCode harness, scoring both task success and the estimated model cost per task. GPT-6.1 Sol (medium) topped the list at 79.6 for an estimated $1.30 per task, while Browser Use's own BU fast agent scored 72.9 at about 11 cents a task, level with Claude Sonnet 5.5 (high) at a fraction of the cost.

Why it matters: Browser-agent leaderboards usually report only accuracy, which rewards an expensive model that barely generalises; putting cost per task next to the score and shipping the runner and encrypted dataset so anyone can reproduce it makes the accuracy-per-dollar tradeoff the actual comparison. What changed: The v2.1 dataset and runner are public (browser-use/benchmark), the scoring is a weighted rubric rather than pass/fail, and the harness runs the same tasks for every model; the page reports 180 tasks while the repository's default run loads the 200-task dataset, so treat exact counts as version-dependent. For me: If you are choosing a model for web automation, read the cost column, not the rank: the cheap agent that is within a few points of the leader is often the right production choice.

Tags: #topic/ai-agents #entity/browser-use #technology/agent-evaluation #technology/browser-agents #event/benchmark #relevance/developer #learning/awareness

Sources:

Asana cut a browser agent's cost 76x by letting its context stay cache-stable

Asana published a study on October 8, also written up by OpenAI on October 9, in which its StackAI browser agent was made 76x cheaper and about 5x faster on GPT-6.1 Sol. The fix was to stop the agent editing its own earlier history on every step: cache the full conversation history and prune screenshots in batches rather than one at a time, so the unchanged prefix survives and prompt caching can actually reuse it.

Why it matters: Provider prompt caching only reuses the longest unchanged prefix, so an agent that trims text or drops a screenshot on every call rewrites its own cache and pays full price forever; making context append-only is a cheap, measurable lever that most agent code gets wrong by default. What changed: In a 144-run study across four models, the best policy allowed up to 20 screenshots before cutting back to one and raised the history budget from 120,000 to 480,000 characters. On GPT-6.1 Sol, cost fell from $1.97 to $0.47 per run with 89% of input read from cache at about 5% of the uncached price; with the smaller budget only 3 of 18 runs returned an answer, and with the larger budget all 18 did. For me: If your agent resends a growing history, keep it append-only and prune in large batches, set the history budget to fit the model, and watch the provider's own cache-read counters before assuming caching is helping.

Tags: #topic/ai-agents #entity/asana #entity/openai #technology/context-engineering #event/technical-demo #relevance/ai-workflow #learning/understand

Sources:

Security That Affects You

PraisonAI's CodeAgent runs LLM-written code with your whole environment and no sandbox

GHSA-2xv2-w8cq-5gxw, published October 8 and tracked as CVE-2026-61447 at CVSS 10.0, is a critical flaw in the praisonaiagents Python library. CodeAgent._execute_python() writes LLM-generated code to a temp file and runs it in a subprocess with os.environ.copy(), no AST validation, no import restrictions and no sandbox enforcement, and the sandbox=True option in CodeConfig is never checked; an attacker who can influence model output through prompt injection can exfiltrate every API key, database URL and cloud token in the environment and run arbitrary code on the host.

Why it matters: "Executes model-generated code" is the entire point of a coding agent, so the environment handed to that subprocess is the blast radius, and copying the parent environment while advertising a sandbox that does not exist is the worst of both worlds: developers think they are contained when they are not. What changed: Fixed in praisonaiagents 1.6.78; the advisory affects versions up to 1.6.77. For me: If you use PraisonAI's CodeAgent, upgrade now and stop passing real secrets via the process environment, since any prompt-injectable input it ingests can read them.

Tags: #topic/security #topic/ai-agents #entity/praisonai #technology/agent-security #event/security-issue #relevance/developer #learning/understand

Sources:

Open Source Momentum

Superfluid is a local LLM server built for multi-agent inference

Basecompute released Superfluid on October 8, an Apache-2.0 server for running local models behind the APIs agents already speak: it exposes OpenAI, Anthropic and Ollama-compatible endpoints over llama.cpp for GGUF models, MLX for MLX directories, and its own BaseRT engine for .base bundles. It is aimed at the case where several agents share one machine's inference rather than one chat hitting one model.

Why it matters: Multi-agent setups multiply concurrent requests against one local GPU, and the common thread of running separate servers per framework wastes VRAM and complicates routing; a single server that speaks all three popular client APIs is the lazy path to serving a fleet of local agents. What changed: A new open-source inference server, rather than a model: the value is the compatibility surface and the runtime choice, not a new checkpoint. For me: If you self-host models for agent work, this is worth a benchmark against your current llama.cpp or Ollama setup; verify the runtime support you actually need before migrating.

Tags: #topic/self-hosting #topic/ai #entity/superfluid #technology/inference #technology/self-hosting #event/open-source-release #relevance/self-hosting #learning/hands-on

Sources:

Introducing Superfluid: the local-AI native LLM server for multi-agent inference (Hugging Face, Oct 8)

Follow-ups

Claude for Startups: Anthropic paused the free year of Claude Team and the $1,000 API credit offers on October 9, saying it received hundreds of thousands of applications (21x the prior five months in the first 48 hours) and is re-reviewing all applications; already-claimed offers stay in accounts, and the $45,000 Startup Stack partner offers remain.

New Concepts

cache-stable-context (new, stage: awareness). Treating an agent's conversation history as an append-only prefix so a provider's prompt cache can keep reusing it, and accepting that any rewrite of earlier context invalidates that reuse. It matters because the caching that makes agents affordable only pays off while the prefix is unchanged, so screenshot removal, text trimming and summarisation all fight the cache unless they are batched; Asana measured a 76x cost reduction on one browser agent largely from this one discipline.

Tag Index

topic

#topic/ai #topic/ai-agents #topic/ai-coding #topic/ai-models #topic/open-source #topic/security #topic/self-hosting

entity

#entity/asana #entity/aws #entity/browser-use #entity/copilot #entity/github #entity/iflytek #entity/kiro #entity/openai #entity/praisonai #entity/superfluid #entity/tii #entity/webcmd

technology

#technology/agent-evaluation #technology/agent-memory #technology/agent-orchestration #technology/agent-security #technology/browser-agents #technology/context-engineering #technology/inference #technology/self-hosting

event

#event/agent-release #event/benchmark #event/model-release #event/open-source-release #event/security-issue #event/technical-demo #event/tool-release

relevance

#relevance/ai-workflow #relevance/developer #relevance/discovery #relevance/infrastructure #relevance/self-hosting

learning

#learning/awareness #learning/hands-on #learning/understand