Apple tightens Full Disk Access for agents, and OpenAPPA polices data flow
Monday's thread is who controls what an agent can touch: Apple's disk permissions, a policy engine for exfiltration, and a declared plan that doesn't get followed.
Most of today’s items ask the same awkward question: once an agent can act, who decides what it’s allowed to touch? Some answers come from an OS vendor, some from a policy engine, and one from a paper about plans that quietly fall apart.
1 · Top story
Apple is tightening Full Disk Access because of AI agents
Apple said it will require more explicit user action before granting Full Disk Access, which exposes files, messages, mail and browsing history. TechCrunch quotes the company saying the risks “will grow substantially” as agents become more autonomous, and notes the move followed reports about Meta’s Muse app and a ChatGPT Mac app vulnerability. Apple hasn’t said which release carries it, and TechCrunch’s correction says this is about informed consent, not new hard limits.
If you ship a desktop or local agent, plan for broad filesystem access to become a visible, revocable ask rather than a one-time click. I’d scope access per folder now, since that’s the design that survives whatever Apple lands on.
2 · Models & features
Cloudflare puts web search behind AI Gateway
Cloudflare launched a Web Search API in AI Gateway on October 2, with Ceramic.ai, Linkup and Exa behind it. Per the details reported by PPC Land, prices run $0.25, $5 and $7 per 1,000 requests at list price with no markup, billed through gateway credits or your own provider key. It’s available over REST or a Workers binding.
The useful part is the control point: search spend, logs and access rules sit next to your model calls instead of in each agent’s own key. The catch is a 10-result cap per query and a 3x-to-28x price spread, so you’d want to measure answer quality per provider before defaulting to the cheap one.
3 · Agents
A policy engine that sits outside the agent loop
Archestra released OpenAPPA, an open-source engine that enforces data-flow rules deterministically, outside the agent. You label sources by audience and trust, labels only get stricter, and a violation triggers a sanitizer, a human approval, or a throwaway child branch that reads the untrusted data. InfoQ reports 0% attack success on Bench-Corp and AgentThreatBench with 89% task completion, against 10% for Claude Code’s auto mode and 31% for Microsoft FIDES.
Treat that as a vendor claim on two benchmarks, and the project calls itself a preview. One number deserves a second look: completion falls to 35% with recovery strategies turned off, so the safety comes with real policy-authoring work.
4 · Research
Agents often don’t follow the plan they announce
A new arXiv paper finds that generic Plan+ReAct preserves the declared plan structure in only 22–45% of trajectories across three benchmarks. The authors have the model pick one of four modes (predefined, sequential, hierarchical, search) and hand off to a deterministic executor. Task success on ALFWorld goes from 0.48 to 0.92, and on SWE-bench Verified from 0.36 to 0.44.
The modest SWE-bench gain and the admission that models still pick the mode unreliably keep this in “interesting” territory. Still, it’s a decent argument for logging whether your agent did what its plan said, not just whether it finished.
5 · People worth following
Alex Zhang on why a harness can be almost nothing
On Latent Space, Alex Zhang defines a recursive language model as a harness whose only tool is code, with state held in a code environment and the option to call itself. He argues Claude Code and Codex are “virtually the same thing” architecturally, and that training on short tasks generalises to tasks “8–30x longer”.
That last claim is his, from an interview, so check it against the paper before building on it. The idea worth borrowing is smaller: fewer tools and more code often means less surface to secure and evaluate.
6 · Architecture
Databricks makes moving an Iceberg table between catalogs a two-call job
Databricks describes REGISTER and UNREGISTER APIs for Iceberg REST Catalogs. REGISTER attaches an existing table by name and metadata location with no data copy. UNREGISTER drops the catalog entry without touching files and returns the latest metadata pointer, which is meant to prevent two catalogs both claiming ownership. Availability is private preview, and tables need to sit in buckets you own.
This lowers catalog lock-in on paper, but the post itself says real migrations still mean pausing writers and repointing jobs. I’d rehearse that runbook before you need it.
That’s the lot. If you only read one, make it the OpenAPPA caveat about recovery, and skip the rest guilt-free.
Researched and drafted with AI, checked against the linked sources. How we use AI →