This Week in Open Source for October 15, 2026

by Daryl Ducharme, Open Source Programs Office

This Week in Open Source for October 15, 2026

A look around the world of open source

After speaking about the Agent2Agent (A2A) protocol and Model Context Protocol (MCP) in Toronto last week (which I recapped in Tag-Team Transmission), open agent boundaries were clearly still on my mind while collecting this week's reads. As AI agents, terminal tools, and embedded micro-apps move deeper into everyday software workflows, a central tension keeps surfacing across the open source community: where do human judgment, interface trust, and maintainer sustainability fit in? Whether teams are wiring up open protocols in the Unix shell, running multimodal retrieval locally on a laptop, or stewarding decades-old kernel infrastructure, the healthiest open source architectures don't replace human agency—they give workers clearer boundaries, inspectable tools, and a genuine seat at the controls.

Upcoming Events

🗓️ October 2026

• All Things Open 2026 (October 19–20, 2026) — Raleigh, North Carolina, USA. One of the largest community-focused open source conferences on the U.S. East Coast exploring open source software, AI engineering, and maintainer sustainability—featuring Googlers Andrew Brogdon, Mark Techson, and Marc Dougherty speaking on "Where Is My Futuristic App? Generative UI and the Open Future" and Abdel Sghiouar on "Taming Agentic AI: How to Run Agents-Generated Code Safely on Kubernetes", alongside the Google Community Lounge with the Flutter team.
• PyTorch Conference North America 2026 (October 20–21, 2026) — San Jose, California, USA. Two days of open source machine learning innovation across the PyTorch ecosystem—featuring a keynote by Google's Bill Jia ("Workload Fungibility in the Age of Agents") and technical sessions from Googlers Chris Jones, Sandeep Pokkunuri, Rob Mulla, Ankita Luthra, Trinadh Kotturu, Claudio Basile, Qi Zhou, Jago Macleod, and Aleksey Vlasenko on TorchTPU, vLLM, SGLang, Ray, and Kubernetes.
• AGNTCon + MCPCon North America 2026 (October 22–23, 2026) — San Jose, California, USA. Linux Foundation and Agentic AI Foundation conference focused on building and scaling production agentic systems with open standards—featuring keynotes by Google's Sarah Drasner and Chi Wang, plus sessions from Googlers Alan Blount (on A2UI), Junjie Bu (on interoperable agent discovery), Amit Handa (on agentic commerce), Dominic Farolino (on MCP Apps + WebMCP), and Prerna Kakkar & Kurtis Van Gent (on EvalBench).
• GitHub Universe 2026 (October 28–29, 2026) — San Francisco, California, USA & Virtual. Annual global developer gathering highlighting open source workflows, collaborative security, and multi-model AI-assisted software engineering.

🗓️ November 2026

• Open Source in Finance Forum (OSFF) New York (November 4–5, 2026) — New York, New York, USA. Dedicated industry conference examining open source compliance, supply-chain security, and collaborative innovation across regulated financial institutions.
• SeaGL (Seattle GNU/Linux Conference) 2026 (November 6–7, 2026) — Seattle, Washington, USA & Virtual. Free, grassroots technical summit dedicated to spreading awareness and knowledge of free and open source software, hardware, and culture.
• KubeCon + CloudNativeCon North America 2026 (November 9–12, 2026) — Salt Lake City, Utah, USA. The Cloud Native Computing Foundation's flagship conference uniting adopters and maintainers around Kubernetes and cloud-native infrastructure—featuring over 35 sessions and keynotes from Googlers including Abdel Sghiouar, Jago Macleod, Tim Hockin, Kaslin Fields, John Belamaric, Dawn Chen, Janet Kuo, Benjamin Elder, Antonio Ojea, Lior Lieberman, Michelle Au, and Braydon Kains across Kubernetes SIGs, etcd, containerd, Gateway API, CEL admission policies, and agent sandboxes.
• SFSCON (South Tyrol Free Software Conference) 2026 (November 13–14, 2026) — Bolzano, Italy. One of Europe's longest-running Free Software conferences bringing together public-sector decision-makers and developers to advance digital sovereignty and open infrastructure.

🗓️ December 2026

• Yocto Project Virtual Summit 2026.12 (December 1–3, 2026) — Virtual. Community summit for embedded Linux engineers and maintainers building custom, reproducible Linux distributions across edge and IoT hardware.
• Open Source Summit Japan 2026 (December 7–9, 2026) — Tokyo, Japan. The Linux Foundation's premier Asia-Pacific conference connecting open source developers, kernel maintainers, and enterprise leaders across cloud, embedded Linux, and open AI, including sessions from Google engineers such as Anurag Sinha.
• OpenCompliance Summit 2026 (December 10–11, 2026) — Tokyo, Japan. Specialized gathering uniting legal, security, and OSPO practitioners around OpenChain, SPDX, software bills of materials (SBOMs), and global open source supply-chain compliance.

Open Source Reads and Links

• [Blog] Meet the A2A CLI: discover, message, and manage agents from your terminal — In Developer Relations, few things beat showing a protocol live in a terminal during a conference talk without a complex web stack in the way. The new Apache 2.0 A2A CLI lets you discover, message, and wrap any stdin/stdout script into a streaming Agent2Agent server with --exec—raising an interesting question: does meeting developers in the Unix shell matter more for open protocol adoption than heavy SDKs?
• [Blog] Talking to Agents with a2a (as a human!) — Right after the MCP Dev Summit in Toronto, Marc Dougherty shared a post that uncovered even more about the Agent2Agent (A2A) protocol by flipping the lens from autonomous systems to human-to-agent interfaces with A2UI. Building a2term so agents render interactive terminal confirmation forms before acting raises a compelling question: could open agent protocols also save humans from enterprise UI bloat?
• [Article] Dreamforce 2026 — When major enterprise platforms start telling customers they may never need to log into a web UI again because every workflow is now an API, MCP tool, or CLI command, where does the user interface go? RedMonk's Rachel Stephens examines this shift toward headless software and asks a question every open source protocol builder should ponder: when third-party agents mediate our data and workflows, how well does trust actually travel?
• [Blog] EmbeddingGemma 2: an open, lightweight multimodal embedding model — Moving RAG setups fully on-device opens up real-world possibilities—from kiosks in low-connectivity areas and offline backup systems to hardware that ships with all of its own help and support docs onboard. With Google DeepMind's Apache 2.0 release of EmbeddingGemma 2 fitting multimodal search into 567MB of RAM, what new resilient tools become possible when devices don't need an internet connection to know how they work?
• [Blog] Atproto Web Tile Embeds — Seeing AT Protocol Web Tiles in the wild sparks curiosity about what new publishing patterns become possible when open protocols move beyond text and static images. Nathan Cassell walks through embedding a live, sandboxed 3D Web Tile straight from a personal data server into a blog post—making us wonder what developers might build when interactive micro-apps can travel anywhere without phoning home.
• [Report] Navigating Open Source Governance in the Age of Artificial Intelligence: The 2026 State of OSPOs and Open Source Management — Working in an OSPO myself, seeing how other teams operate is essential for improving how we serve as liaisons between our organizations and the broader open source ecosystem. With the Linux Foundation and TODO Group's 2026 survey finding 79% of AI-involved OSPOs shaping model policy and 69% piloting agentic workflows, how can we ensure enterprise AI governance also supports upstream maintainers?
• [Report] Celebrating 35 Years of Linux: The Open Source Engine Powering Three Decades of Global Innovation and Infrastructure — It is incredible to see the success of the Linux kernel and distributions across enterprise software development—and to ponder how a project from the early 1990s has kept up with so many technological shifts. As Linux Foundation Research celebrates 35 years of Linux across billions of devices and every top-500 supercomputer, how can the community's model of continuous adaptation guide the next generation of maintainers?

Which of these stories will you be chatting about at your next meetup or conference? Let us know! Share with us on our @GoogleOSS X account or our @opensource.google Bluesky account.

How much does it cost to use open source software?

by Sophia Vargas, Google Open Source

Open source software is used pervasively, with some estimating that over 90% of codebases contain open source software. Many adopt open source software because it’s free and thus cheaper than writing a proprietary alternative. But as the community saying goes: “open source is free as in puppies, not free as in beer.” Once you or your organization has adopted an open source project, there is still effort (such as engineering time, costs, etc.) associated with ensuring that your version of an open source project is healthy and up to date.

While efforts by the research community have investigated the ongoing costs required to maintain open source software, at Google we needed to better understand the resources required to use thousands of open source software packages.

To better understand this cost, we designed a study to evaluate the effort (in software engineering hours) associated with maintaining open source software packages within Google. We focused on the following questions:

RQ1: How long does it take for an engineer (not a maintainer of the upstream project) to update an open source software package at Google?

RQ2: Can complexity metrics predict the relative effort/amount of time to update a package at Google?

Customization incurs additional cost

The majority of open source package updates (at Google) take four hours or less. However, the long tail could be days to months to fully land a package update. We needed to understand what makes the difference between hours, days, and months.

Our results suggested metrics that could be better predictors of update complexity than others. For example, local patches and customization, the number of package dependencies, and the number of upstream contributors, were better indicators of update complexity than the age of the package, or how many teams were using that package internally.

Study limitations and future work

As this study was completed at Google, we acknowledge there are bias and limitations of our findings, including the following:

• Business priority-based sampling: While rigorous, generalizable research studies thoroughly interrogate samples to minimize bias and maximize analytic potential, we designed this study to focus on existing data and minimize new data collection which could impact engineering roadmaps.
• We did not dictate tooling: We did not specify what tools (including genAI-enabled features) could or could not be used in the update process, and as such did not investigate the impact of any specific tool.
• Bias towards Go: Our collected data had significant bias towards Go. Given the lack of variety in our sample, we could not investigate the effect of language ecosystems, but other internal efforts indicated that language may significantly impact maintenance efforts. We encourage this line of investigation for future studies.
• Only active projects: This effort did not include significant data collection on stale or archived packages.

Curious about our approach and findings? Read the full research report: “How much does it cost to maintain a copy of an open source software package (at Google)?”

Adopting Pyrefly as the Python type checker at Google

by Amer Elsheikh, Python Team

Python is one of the primary languages at Google, powering everything from machine learning research to developer infrastructure and data pipelines. Across hundreds of thousands of files in our monorepo, fast and reliable static type checking is essential for maintaining code safety and developer velocity.

Today, Pyrefly—an open source type checker developed by Meta—is the Python type checker at Google.

Replacing our previous type-checking infrastructure with Pyrefly provided significant speedups for engineers and agents alike, while substantially reducing build-system compute resources.

Moving away from Pytype

For more than a decade, Google relied on Pytype, an internally developed type checker that pioneered Python type checking and collaborated with the open source community to create typeshed.

However, as Python’s typing system evolved rapidly, Pytype faced fundamental challenges. Because it operated by analyzing compiled bytecode rather than source ASTs, keeping pace with modern typing PEPs became an increasing maintenance burden due to bytecode instability across Python releases. In addition, it struggled to deliver the fast turnaround times required for modern development loops.

As detailed in the Pytype update, we decided that Python 3.12 would be the final supported version for Pytype, leading us to evaluate and adopt modern open source alternatives.

Why Pyrefly?

Pyrefly incorporates years of collective lessons from earlier tools across the Python typing ecosystem. When evaluating candidates to succeed Pytype, Pyrefly quickly stood out across three key areas:

Performance

Written in Rust, Pyrefly is designed for high throughput and lazy, parallel evaluation. In our internal benchmarks across various Google projects, it proved to be an order of magnitude faster than Pytype, while scaling smoothly across large dependency graphs.

Typing spec conformance

Pyrefly achieves strong conformance—scoring roughly 97% on the official typing conformance test suite—and is actively maintained to track new Python versions and typing PEPs. This comprehensive language support makes Python version upgrades across our monorepo smoother.

In addition to supporting new syntax, Pyrefly provides strict type safety in areas where Pytype was historically permissive. A notable example is unsound unions: Pytype allowed passing a value of a union type (such as int | None or int | str) to a function expecting a specific type (such as int), as long as at least one type in the union was compatible. However, Pyrefly enforces sound union checking, catching these mismatches:

# foo.py
def process_id(x: int) -> None:
    ...
def get_id() -> int | None:
    ...
val = get_id()
# Accepted by Pytype, but rejected by Pyrefly:
process_id(val)

Actionable error diagnostics

Pyrefly provides Rust-style compiler diagnostics, displaying the offending code snippet with inline annotations that point directly to the root cause of type mismatches, sometimes with suggested fixes. E.g., for the foo.py example above, Pyrefly produces:

ERROR Argument `int | None` is not assignable to parameter `x` with type `int` in function `process_id` [bad-argument-type]
 --> foo.py:8:12
  |
8 | process_id(val)
  |            ^^^
  |
  The declared type does not allow `None`. Consider narrowing the value with an `is not None` check.

Performance and infrastructure impact

Switching to Pyrefly brought measurable improvements across Google's developer ecosystem and infrastructure:

• Up to 98% faster incremental rebuilds: In developer edit-and-rebuild workflows (with a warm daemon during active editing cycles), Pyrefly delivered up to a 98% latency reduction across various targets. On large machine learning targets, type-checking times dropped from minutes to seconds.
• >90% critical-path reduction in clean builds: In cold-cache benchmark suites across major libraries and models, Pyrefly consistently reduced the type-checking share of the build critical path by 90% to 99%, eliminating a long-standing bottleneck in our build pipelines.
• >80% compute hardware savings: Pyrefly reduced Google’s daily peak compute occupancy for Python type checking by more than 80%, saving thousands of machine cores every day.

To illustrate this impact on developer workflows, the chart below compares total edit-and-rebuild latency between Pytype and Pyrefly across targets of varying sizes.

Developer feedback

Beyond aggregate metrics, Pyrefly improved the day-to-day development loop, allowing engineers and AI coding agents to catch bugs faster.

Here is what engineers across Google have shared about their experience:

"I haven't waited for a Pytype action to complete since our project switched [to Pyrefly]. It is doubly awesome for agentic coding. Type checking is faster than running the tests now." — Peter Hawkins, JAX Tech Lead

"I really like that Pyrefly gives super clear errors that point out exactly what's wrong." — Yotam Doron, Gemini Large Scale Pretraining

“Investing in Python tooling pays huge dividends for research velocity: Pyrefly keeps our experimental iterations fast and catches subtle bugs early with clear, actionable errors.” — Tom Ward, GDM Science

Looking forward

Adopting Pyrefly highlights the value of uniting behind shared open source developer tooling. We are deeply grateful to the Pyrefly team for their rapid turnaround and responsiveness on upstream issues throughout our rollout. We look forward to continuing our collaboration and contributing to the Python open source community.

To learn more about Pyrefly or try it in your own projects, visit the Pyrefly website and the Pyrefly GitHub repository.

This Week in Open Source for October 2, 2026

by Daryl Ducharme, Open Source Programs Office

This Week in Open Source for October 2, 2026

A look around the world of open source

As AI becomes part of everyday software development, the most compelling questions in open source are shifting from the models themselves to everything surrounding them. I’m always drawn to how technology affects individuals, and especially the workers who use and maintain it, for better or for worse (I definitely prefer better). That’s why I’m convinced the next phase of open-source AI won’t be won by chasing bigger benchmarks, but by building the open infrastructure, transparent local tooling, and community norms that keep developers and maintainers in control. This week’s reads explore what that looks like in practice.

Upcoming Events

🗓️ October 2026

• ValkeyConf 2026 (October 5, 2026) — Prague, Czechia. Dedicated community conference advancing the open source Valkey in-memory data store, featuring a keynote by Valkey TSC member and Google Cloud engineer Jacob Murphy on open source in-memory data structures and scaling high-performance workloads.
• MCP Dev Summit Toronto (October 5–6, 2026) — Toronto, Ontario, Canada. Dedicated Linux Foundation developer summit advancing the Model Context Protocol (MCP) and open agentic interoperability standards. Join Google OSPO's Daryl Ducharme (that's me!) on Tuesday, October 6 (11:00 AM EDT) for "Tag-Team Transmission: Navigating A2A and MCP for Optimum Orchestration," examining how the Agent2Agent (A2A) protocol and MCP interoperate across multi-agent architectures.
• Open Source Summit Europe (October 7–9, 2026) — Prague, Czechia. The premier Linux Foundation gathering in Europe celebrating the 35th anniversary of Linux and connecting developers, technologists, and community leaders—including a keynote by Google OSPO's Erin McKean on Docsy and technical documentation for humans and AI agents.
• Community Over Code (October 11–14, 2026) — Glasgow, Scotland. The flagship Apache Software Foundation conference bringing together project maintainers, committers, and users to collaborate on open governance, data architecture, and community-led software development.
• BazelCon 2026 (October 13–15, 2026) — Amsterdam, Netherlands. Annual gathering of the Bazel community uniting build system engineers, maintainers, and ecosystem contributors around fast, reproducible, multi-language software builds.
• All Things Open 2026 (October 19–20, 2026) — Raleigh, North Carolina, USA. One of the largest community-focused open source conferences on the U.S. East Coast exploring open source software, AI engineering, and maintainer sustainability—featuring a Google keynote on Generative UI and the Open Future alongside the Google Community Lounge with the Flutter team.
• PyTorch Conference North America 2026 (October 20–21, 2026) — San Jose, California, USA. Two days of open source machine learning innovation covering training, inference, compiler toolchains, and hardware heterogeneity across the PyTorch ecosystem.
• AGNTCon + MCPCon North America 2026 (October 22–23, 2026) — San Jose, California, USA. Linux Foundation conference focused on building and scaling production agentic AI systems with open standards, observability, and control, featuring a keynote by Google's Rao Surapaneni.
• GitHub Universe 2026 (October 28–29, 2026) — San Francisco, California, USA & Virtual. Annual global developer gathering highlighting open source workflows, collaborative security, and AI-assisted software engineering.

🗓️ November 2026

• Open Source in Finance Forum (OSFF) New York (November 4–5, 2026) — New York, New York, USA. Dedicated industry conference examining open source compliance, supply-chain security, and collaborative innovation across regulated financial institutions.
• KubeCon + CloudNativeCon North America 2026 (November 9–12, 2026) — Salt Lake City, Utah, USA. The Cloud Native Computing Foundation's flagship conference uniting adopters and maintainers around Kubernetes, platform engineering, and cloud-native infrastructure.
• SFSCON (South Tyrol Free Software Conference) 2026 (November 13–14, 2026) — Bolzano, Italy. One of Europe's longest-running Free Software conferences bringing together public-sector decision-makers and developers to advance digital sovereignty and open infrastructure.

Open Source Reads and Links

• [Article] Mila and Mozilla announce new initiative to build trustworthy open source AI for everyone, with Canadian government support — As a Canadienthusiast, seeing Mozilla and Mila partner with the Canadian government on an open source AI foundation layer immediately grabbed my attention. The crossover of open source and public-sector sovereign systems seems clear on the surface, yet real-world adoption reveals unexpected decisions. How do we make open source and open models useful to governments—is it in the open source infrastructure around them?
• [Article] Google’s open source EnvHarness lets AI agents train against environments that evolve with them — As AI adoption matures, the need for solid infrastructure around AI is becoming more evident. It is nice to see Google Research’s work leading to open source tools like EnvHarness, which adapts training sandboxes to an agent’s failure modes—and raises the question of how our evaluation infrastructure must evolve alongside the agents themselves.
• [Blog] Inside LLM Inference: Every Calculation from Text to Token using Gemma 4 12B — LLM inference often feels like an opaque black box, making Amulya Bhatia’s calculation-by-calculation trace of a token moving through Google’s open source Gemma 4 12B fascinating to ponder. Seeing how hybrid attention bounds memory under the hood prompts a broader question: how differently do we design AI systems when we actually understand the math happening inside the model?
• [Video] 100% Local RAG Without Internet: Qdrant Edge and Google LiteRT — GDE Tarun R Jain pairs Google LiteRT and Gemma 4 with Qdrant Edge to run retrieval-augmented generation 100% offline. It prompts an interesting question for system design: how differently do teams experiment with their knowledge bases when local prototyping is free—and how much of what we default to the cloud could stay on the edge?
• [Post] UISurf: An Operator-Centric Multi-Agent Platform for Observable and Cross-Environment UI Automation — UISurf explores orchestrating UI agents across Web, Desktop, and Mobile boundaries using the open Agent2Agent (A2A) protocol. Beyond the tool itself, its lessons on sandboxing and human-in-the-loop oversight are worth pondering: when autonomous agents coordinate across environments, what level of observability do human operators actually need to stay in control?
• [Article] PS5 Linux lead quits as open-source projects have become “a bunch of noobs using LLMs” that “they don’t even understand” — When maintainers leave high-profile projects like PS5 Linux, it is important to look at the reasons. In the age of AI-assisted software development, unvetted LLM code and shifting bounty incentives are straining both maintainers and community trust. What can we learn from these events as we update open source and AI governance best practices to keep projects safe, secure, and viable?

Which of these stories will you be chatting about at your next meetup or conference? Let us know! Share with us on our @GoogleOSS X account or our @opensource.google Bluesky account.

Standardizing fine-grained access control in Apache Iceberg's REST catalog

by Talat Uyarer & Sung Yun, Google Cloud

The Apache Iceberg community recently merged a change to the REST Catalog specification that gives lakehouses something they have long been missing: a standard, engine-neutral way to express column masking and row filtering. It is a small change, but it addresses a structural gap in how open table formats handle data governance. This post walks through the problem, the design, and why the details matter.

The problem: there is no server in the read path

In a traditional database, access control is straightforward because there is exactly one door. Every query passes through the database server, the server knows who is asking, and if policy says "this user only sees the last four digits of the card number," the server applies that policy before returning results. One process, one enforcement point.

Apache Iceberg deliberately removed that door. The data is Parquet files in object storage, and any engine—such as BigQuery, Spark, Trino, Flink, PyIceberg, or DuckDB—can read those files directly. This design is what makes Iceberg fast and interoperable. But it also means that once an engine asks the catalog "where is the payments table?" and receives the metadata pointer, it has full access to the files. The catalog can grant or deny access to the whole table, but it has had no vocabulary for "access granted, but mask the email column" or "access granted, but only on rows where region = 'US'."

Until now, Iceberg had no built-in answer to this. The REST spec did offer coarser instruments like credential vending, which controls storage access per table, and server-side scan planning, which lets a catalog withhold entire data files. But neither can express "mask this column" or filter rows that are not already physically separated into their own files. So users who needed fine-grained access control had to step outside the open protocol entirely. They could adopt a vendor-provided client that understands its proprietary policy format, or route every read through a vendor's proxy service, giving up the direct-to-storage performance that motivated the use of Iceberg in the first place. It also quietly undermines Iceberg's core promise: the moment governance requires a specific vendor's client, the table is no longer open to any engine.

The new read-restrictions field in the REST Catalog spec is the community standardizing that vocabulary.

The mechanism

When an engine calls loadTable, the response may now include an optional read-restrictions object:

Read restrictions are expressed in two fields:

• required-row-filter: a standard Iceberg predicate expression. Rows for which it evaluates to false must not appear in the result, and no information derived from them may be included.
• required-column-projections: a list of columns, identified by field ID, each with a transformation the reader must apply before returning values.

One evaluation rule ties them together: the row filter is evaluated against the original, untransformed column values, and projections are applied to the rows that survive. This ordering is what makes the two features composable. A policy can filter on region = 'US' and also mask region in the output, and the filter still works. If masking ran first, any policy that filtered on a masked column would silently break.

Note what the catalog is doing here. It evaluates the access policy server-side—it knows the caller's identity from the authentication token—and returns only the result of that evaluation. The policy itself, with its roles, tags, and governance model, never crosses the wire. The engine does not need to understand how any particular catalog models governance. It needs to understand nine actions and a predicate.

The whole architecture fits in one sequence:

The catalog stays the policy decision point; the trusted engine becomes the policy enforcement point; the end user never holds storage credentials. Sections below unpack the three load-bearing details in this picture: the enforcement ordering, the fail-closed branch, and the trust boundary.

The nine masking actions

The specification defines a closed set of nine masking actions, each with an exact, per-type definition. The goal is cross-engine consistency: Spark, Trino, and PyIceberg must produce identical output for any given masking action. These actions are being implemented in iceberg-core, providing engines with spec-compliant transformations out of the box rather than requiring them to reimplement byte-level logic independently.

Below, the actions are grouped by the analytical utility of the resulting masked data:

Preserve the shape, hide the value

• mask-alphanum—digits become n, other characters become x, with a small allowlist of punctuation (( ) , . - @) preserved. iceberg16112018@apache.org becomes xxxxxxxnnnnnnnn@xxxxxx.xxx—recognizably an email address, but not whose.
• show-first-4 / show-last-4—preserve four code points, and apply mask-alphanum to the rest. 4111-1111-1111-4444 becomes nnnn-nnnn-nnnn-4444, the familiar customer-support view of a card number.

Hide everything

• replace-with-null—the value becomes NULL. Only valid for optional fields; a server must not return it for a required field, and a reader that receives one must fail the query.
• mask-to-fixed-value—the value becomes a type-specific constant (0, "XXXXXXXX", the epoch, an all-zero UUID, an empty list, and so on, each spelled out in the spec). Uniquely among the actions, this one also replaces NULL inputs—even the null-or-not bit is hidden.

Reduce precision

• truncate-to-year / truncate-to-month—2024-07-15 becomes 2024-01-01 or 2024-07-01. Cohort analytics keeps working; identifying individuals gets harder.

Allow joins, hide values

• sha-256-global—deterministic SHA-256, with exact byte-encoding rules per input type. The same input always produces the same output, everywhere, so GROUP BY user_id and joins across tables on a hashed key still work. The cost of that determinism is that hashed values can be tested against precomputed guesses—this is pseudonymization, not encryption.
• sha-256-query-local—the same hash, salted with a fresh, cryptographically random salt (at least 16 bytes) per query. Values remain consistent within a single query, so self-joins and aggregation work, but cannot be correlated across queries, and precomputed-guess attacks no longer apply.

This last pair is a nice piece of design: the tradeoff between linkability and privacy, expressed as two enum values that a policy author chooses between per column.

Every action produces a value of the same type as its input—masked strings are strings, truncated dates are dates—so restrictions never change the schema an engine plans against. Queries do not need rewriting; values simply arrive transformed.

Fail-closed by design

The most consequential sentence in the specification is this one:

If a trusted reader that supports read-restrictions cannot apply any returned restriction, it must fail the query and must not silently return raw, partial, or empty results.

Consider the failure modes. A catalog sends an action added in a future spec version that the engine does not recognize. Or an expression type it cannot evaluate. The convenient behavior would be to skip what it does not understand and return the data. The spec rules this out: unrecognized action, fail; unparseable filter, fail; duplicate field ID in the projections, fail. Every ambiguity resolves to "no data" rather than "raw data." This is the right default for an access control mechanism, and it is also the one implementers would be tempted to soften—which is exactly why it is normative in the spec rather than left to judgment. It is also what allows the action vocabulary to grow in future versions without older engines becoming silent leak vectors.

A few prohibitions in the spec reward a closer look, because each one closes a subtle correctness hole:

• No projections on map keys. Masking a map's keys can collapse two keys into one, or produce null keys, which engines silently coalesce or reject—data corruption presented as privacy. The spec bans it outright.
• No projection on both a nested type and a field inside it. Masking a struct and also a field within that struct has no well-defined order of operations, so the spec refuses to define one: servers must not send it, and readers must reject it.
• Everything references field IDs, never column names. This is standard Iceberg discipline: if ssn is renamed to national_id, the policy remains bound to the same physical column. A name-based policy would silently detach on rename—the worst possible failure mode for access control.

The trust model, stated plainly

All of this is enforced by the reader. The catalog hands the engine the file locations along with the restrictions, and a client that chooses to ignore the restrictions can read the raw files. So what is this actually protecting?

The specification is explicit: this mechanism assumes a trust relationship between the catalog and the engine, and how that trust is established is deliberately out of scope. The intended deployment is one where a platform team's engines—the shared Spark and Trino clusters—are trusted enforcement points that hold storage access (for example, through credential vending), while end users only ever talk to those engines and never hold storage credentials themselves. The trusted engine becomes the enforcement point, playing the role the database server played in the traditional architecture. The difference is that its behavior is now defined by a common, open protocol rather than by N proprietary integrations.

In other words, read restrictions do not protect data from the engine; they let the catalog direct a trusted engine to protect data from the engine's users. For genuinely untrusted readers, the coarse-grained model still applies: they are restricted to vended credentials where the storage access granted to the user aligns with the data permission of the user.

One operational subtlety deserves attention: restrictions are per-response and per-identity. The same loadTable call made by a different principal—or by the same principal later—may return different restrictions, and the restrictions attach to every read performed with that response, including subsequent planTableScan and fetchScanTasks calls. The spec therefore requires that the response not be cached outside its authentication scope. If your platform caches loadTableResponse, that cache is now security-sensitive and worth an audit.

What is still missing

Read restrictions are a foundation, not the finished building. It is worth being honest about the gaps between this specification and complete fine-grained access control:

1. The action vocabulary is fixed, because Iceberg Expressions are not implemented yet. Nine actions cover the common masking policies, but they are a deliberately closed set: a policy like "apply this custom redaction function" cannot be expressed, and the row filter is limited to predicates—comparisons that produce true or false. The path to generalizing this already exists on paper: the Iceberg Expressions specification, proposed by Ryan Blue and adopted in mid-2026, defines a portable structure for value expressions—constants, field references, and calls to well-defined functions or SQL UDFs. Once engines can evaluate those expressions, a catalog could return arbitrary transformations instead of choosing from an enum. Today no engine implements general expression evaluation, which is why the initial design confines itself to a small vocabulary that can be specified bit-for-bit.
2. There is no policy definition—deliberately. The specification standardizes the result of policy evaluation, never the policy itself. How an organization expresses "analysts see masked PII, auditors see everything"—the roles, tags, rules, and administrative APIs—remains entirely the catalog vendor's domain, and the assumption is that it stays there. Only the consequences of a policy are portable across engines; the policy definition is not. Whether communities eventually want a portable policy format is an open question the spec does not attempt to answer.
3. Trusted clients are asserted, not proven. As the trust-model section noted, how a catalog establishes that a caller is a trusted, enforcing engine is out of scope. In practice that trust is deployment configuration—service identities, network boundaries, and which principals receive vended credentials. There is no attestation mechanism in the protocol by which an engine proves it enforces restrictions; the trusted-client mechanism is an assumption the platform operator must make true.

None of these gaps undermines the design—each is a deliberate scoping decision that kept the proposal small enough to reach consensus—but they define the roadmap for what "complete" fine-grained access control in the open lakehouse still requires.

Why this matters

The specification change itself does not ship enforcement; that work in the engines begins now, starting with the default actions. But the shape of the design is right in three ways:

1. It picks the honest enforcement point. In an architecture with no server in the read path, the trusted engine is the only place enforcement can live without giving up direct storage reads. The spec accepts that constraint explicitly rather than obscuring it.
2. It standardizes the narrow waist. Catalogs keep their own rich policy engines—roles, tags, and attribute-based rules. Engines implement nine actions and a predicate evaluator, once. N×M becomes N+M.
3. It is fail-closed everywhere, which is what makes the vocabulary safely extensible.

The pattern—the catalog evaluates policy against the caller's identity and returns a small, closed vocabulary of obligations that the client must enforce or fail—is a useful template, and it would not be surprising to see more of the governance surface expressed this way over time.

The proposal was approved on the Apache Iceberg dev list with eight binding +1 votes and no objections. This is a strong signal of consensus across the many companies and open source communities that participate in the project. Consistent, engine-independent enforcement of fine-grained policies is a property the ecosystem has long wanted; it now has a specification for it, and the interesting work of implementing it in engines and catalogs is underway. If you work on either, the dev list is the place to get involved.

The full schema is available in rest-catalog-open-api.yaml under ReadRestrictions. View the full vote thread.