DEV Community: subaru

What I Learned Implementing noReactObjectTypeAsDefaultProp in Biome

subaru — Tue, 22 Sep 2026 09:50:26 +0000

I contributed the noReactObjectTypeAsDefaultProp lint rule to Biome.

The issue was to port eslint-plugin-react/no-object-type-as-default-prop to Biome. This post explains what the rule checks and what I learned about Rust while implementing it.

What the rule checks

The rule reports expressions such as object and array literals when they are used as default values for destructured React props.

function Component({ items = [], config = {} }) {
  return <div>{items.length}</div>;
}

JavaScript creates a new value each time it evaluates an object or array literal.

[] === []; // false
{} === {}; // false

Using one as a prop default therefore creates a different reference on every render. That can break memoization or make dependency-based logic run more often than intended.

The rule detects:

object and array literals
arrow functions and function expressions
class expressions
new expressions
JSX elements
regular-expression literals
Symbol() calls

Primitive defaults such as strings, numbers, and booleans remain valid.

Reading Rust before writing Rust

Biome's contribution guide led me to state my intention on the issue before starting. I had almost no practical Rust experience, so I first read The Rust Programming Language.

After reading the book, I could follow the syntax, but many of the rules were still separate pieces of knowledge. They started to connect only when I had to read Biome's code, fix compiler errors, and respond to review feedback.

Ownership and borrowing in practice

Every value in Rust has an owner. When the owner leaves its scope, the value is dropped. Passing a String to another function may move ownership.

fn consume(message: String) {
    println!("{message}");
}

fn main() {
    let message = String::from("hello");
    consume(message);
    println!("{message}");
}

The compiler explains exactly what happened:

error[E0382]: borrow of moved value: `message`
  |
  |     consume(message);
  |             ------- value moved here
  |
  |     println!("{message}");
  |                ^^^^^^^ value borrowed here after move

If a function only needs to read a value, it can borrow a reference instead.

fn length(message: &str) -> usize {
    message.len()
}

fn main() {
    let message = String::from("hello");
    println!("{}", length(&message));
    println!("{message}");
}

The output is:

5
hello

A mutable reference uses &mut:

fn append_world(message: &mut String) {
    message.push_str(", world");
}

fn main() {
    let mut message = String::from("hello");
    append_world(&mut message);
    println!("{message}");
}

hello, world

JavaScript and Go normally let a garbage collector reclaim unused memory. Rust uses a different approach: the compiler checks ownership and borrowing rules. A garbage collector is not unsafe; Rust simply reaches memory safety through a different design.

While traversing Biome's syntax tree, I often needed to inspect nodes without owning them. I gradually learned to ask whether a reference was enough instead of moving or cloning a value by default.

Traversing Biome's syntax tree

Biome operates on a concrete syntax tree (CST), which preserves details such as comments and whitespace. A lint rule does not search JavaScript as text. It walks typed syntax nodes.

Conceptually, this rule follows this path:

React component
  └─ function parameters
      └─ object binding pattern
          └─ each property
              └─ default-value expression

The real implementation must handle function declarations, arrow functions, function expressions, functions wrapped in memo or forwardRef, and default-exported functions. These forms use different syntax-node types. I used Biome's existing ReactComponentInfo and brought the different forms to one point where the rule could obtain the props object pattern.

When I did not know a node or method name, I searched existing rules with rg and found examples that handled similar syntax. Learning how to navigate a large codebase was as important as learning Rust syntax.

Why Option and Result fit syntax trees

A syntax tree does not always contain the node a rule is looking for. A function may not destructure its first parameter, and a file may contain incomplete syntax.

Rust represents an optional value with Option<T>: Some(T) when a value exists and None when it does not.

fn find_even(numbers: &[i32]) -> Option<i32> {
    numbers.iter().copied().find(|number| number % 2 == 0)
}

fn main() {
    println!("{:?}", find_even(&[1, 10, 3]));
    println!("{:?}", find_even(&[1, 3, 5]));
}

Some(10)
None

Result<T, E> represents success as Ok(T) and a recoverable failure as Err(E).

fn parse_port(value: &str) -> Result<u16, std::num::ParseIntError> {
    value.parse()
}

These types make absence and failure visible in a function's signature. Reading them in the Rust Book was useful, but using them to traverse syntax nodes made their purpose concrete.

Returning multiple diagnostics with Vec

One component can contain several invalid defaults:

function Component({ items = [], options = {}, render = () => null }) {
  return null;
}

Stopping after the first match would make users fix the same line repeatedly. The rule therefore returns a Vec of findings. A Vec<T> is a growable collection of values with the same type. An empty vector represents no diagnostics; three entries represent three diagnostics.

fn collect_even(numbers: &[i32]) -> Vec<i32> {
    let mut results = Vec::new();
    for number in numbers {
        if number % 2 == 0 {
            results.push(*number);
        }
    }
    results
}

Understanding what ? returns from

The ? operator unwraps a successful Result or present Option. On Err or None, it returns early from the current function or closure.

fn parse_and_double(value: &str) -> Result<u32, std::num::ParseIntError> {
    let number = value.parse::<u32>()?;
    Ok(number * 2)
}

The word current matters. The rule processes object properties with filter_map. Its closure returns an Option, so ? can skip the current property without ending the entire rule run.

let defaults = object_pattern
    .properties()
    .filter_map(|property| {
        let property = property.ok()?;
        let default_value = find_default_value(property)?;
        let kind = ForbiddenDefaultKind::from_expression(&default_value)?;
        Some(ForbiddenDefault { default_value, kind })
    })
    .collect();

This also explains why ? cannot be used directly in a function returning Vec. It is not merely shorthand; its control flow is tied to the return type.

Moving behavior closer to the type

I initially put the expression classification in a free function:

fn forbidden_default_kind(
    expression: &AnyJsExpression,
) -> Option<ForbiddenDefaultKind> {
    // classify the expression
}

After review, I moved it to ForbiddenDefaultKind:

impl ForbiddenDefaultKind {
    fn from_expression(expression: &AnyJsExpression) -> Option<Self> {
        // classify the expression
    }
}

Now the type that represents the classification also knows how to derive itself from an expression. Both versions can work, but the second location makes the call site easier to read and keeps the classification detail near the type it creates.

Moving non-React behavior into shared syntax code

I also added parameter extraction to the React component module at first. A reviewer pointed out that the operation was not React-specific. Extracting parameters from JavaScript functions can be useful to other analyses too.

I moved it to a shared extension on AnyJsFunction in biome_js_syntax:

impl AnyJsFunction {
    pub fn parenthesized_parameters(&self) -> Option<JsParameters> {
        // normalize the different function forms
    }
}

That review changed how I look at module boundaries. It is not enough to place code where the first caller happens to live. The operation should live at the layer that owns the concept.

Handling aliased defaults

Object destructuring can rename a property:

function Component({ items: localItems = [] }) {
  return <div>{localItems.length}</div>;
}

My first implementation handled only shorthand properties such as { items = [] }. The original ESLint rule also reports aliased defaults. Its property handling does not assume shorthand syntax.

Biome represents shorthand and aliased binding properties with different node types. I updated the rule to extract defaults from both JsObjectBindingPatternShorthandProperty and JsObjectBindingPatternProperty, then added a regression test for the aliased form.

Diagnostics are part of the implementation

A lint rule must do more than identify a node. Its message needs to help a user decide what to do next.

The review introduced me to three parts of a useful diagnostic:

what is wrong
why it matters
how to fix it

I also replaced unexplained wording such as “reference type” with the concrete behavior: the value is newly created on every render. A technically correct message is not automatically an actionable one.

What changed in my understanding of Rust

After reading the Rust Book, ownership, borrowing, Option, Result, Vec, and ? still felt like separate language features.

In Biome they form one flow. The rule borrows syntax nodes, represents missing nodes with Option, receives parsing failures as Result, uses ? inside a closure to skip non-matches, and collects findings into a Vec.

Rust now feels less like a language with many restrictions and more like a language that makes ownership, absence, and failure visible in the code. Reading the book gave me the vocabulary. Working in a real codebase—and receiving feedback from both the compiler and reviewers—made the vocabulary useful.

References

This article was edited with AI assistance. I checked the technical explanations against the merged implementation, tests, review discussions, and the official Rust documentation.

Who Decides the Tenant? A Small Rust Guard for AI Tool Calls

subaru — Mon, 21 Sep 2026 01:28:40 +0000

I have been thinking about a fairly ordinary failure mode in AI-enabled SaaS products.

A support agent is helping a user from tenant-a. The user asks about a contract, and the model produces a perfectly valid tool call:

get_contract("contract-b")

There is nothing obviously wrong with the call. The tool exists and the argument has the right shape. The problem is that contract-b belongs to tenant-b.

A better prompt might make this happen less often. It cannot turn the prompt into an authorization boundary.

I made TenantInvariant, a small experimental Rust crate, to explore where that boundary should live.

subaru-hello / tenant-invariant

Executable tenant-isolation invariants for AI agent tool calls, written in Rust.

TenantInvariant

What if an AI agent chooses a resource ID that belongs to another customer?

tenant-invariant is an experimental Rust library for making tenant isolation an executable invariant before an AI agent's tool call executes. The application supplies an authenticated actor and server-resolved resource ownership. The library allows same-tenant access and fails closed for cross-tenant or unknown ownership.

It does not trust tenant IDs produced by the model.

agent proposes resource ID
  -> server resolves the resource owner from a trusted source
  -> TenantInvariant compares actor and owner
  -> existing authorization and tenant-scoped data operation

Setup

You need Git and the stable Rust toolchain. If Rust is not installed, use rustup, the installer recommended by the Rust project:

# macOS, Linux, or WSL
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

On Windows, download and run rustup-init.exe from the same official installation page. Restart the terminal…

View on GitHub

The bug I had in mind

Tool calling adds a new decision-maker to an otherwise familiar request path:

user prompt
  -> model chooses a tool
  -> model supplies resource IDs
  -> application executes the tool

It is tempting to put both tenant_id and contract_id in the tool schema. That gives the model a neat, self-contained payload:

{
  "tenant_id": "tenant-a",
  "contract_id": "contract-b"
}

It also gives the model a say in something it should not control. The tenant might have come from a system prompt, a previous tool result, or text supplied by the user. None of those sources prove authority.

The rule I settled on is simple: the model can propose a resource ID, but it cannot tell the application who owns that resource.

The actor's tenant comes from the authenticated server-side context. The application resolves the owner of the proposed resource from its database or another trusted service. Only those two values are compared.

AI proposes a resource ID
        |
        v
server resolves the real owner
        |
        v
authenticated tenant == resource owner?
        | yes                         | no / unknown
        v                             v
normal authorization continues      deny

I chose to deny an unknown owner as well. If the lookup fails, there is not enough information to authorize the operation.

The crate is deliberately small

The actual comparison could be an if statement. I did not want to hide that fact behind a large abstraction.

The useful part of making it a crate is that the rule gets a name and a few types. TenantId rejects an empty identifier. ResourceOwner::Unknown makes a failed ownership lookup visible. Decision makes the caller deal with both the allowed and denied paths.

use tenant_invariant::{
    check_tenant, Actor, Decision, ResourceOwner, TenantId,
};

fn main() {
    let actor = Actor {
        // This value comes from the authenticated application context.
        tenant: TenantId::new("tenant-a")
            .expect("tenant ID must not be empty"),
    };

    // The server looked this up using the ID proposed by the model.
    let owner = ResourceOwner::Tenant(
        TenantId::new("tenant-b")
            .expect("tenant ID must not be empty"),
    );

    match check_tenant(&actor, &owner) {
        Decision::Allow => {
            // Continue with normal authorization and a scoped query.
        }
        Decision::Deny(reason) => {
            eprintln!("blocked: {reason:?}");
        }
    }
}

You can install it from crates.io:

cargo add tenant-invariant

There is also a runnable example in the repository:

$ cargo run --example contract_lookup
blocked: CrossTenant

Rust works nicely here because invalid or unresolved states can be represented directly instead of being hidden in strings and null values. That does not make the system secure by itself, but it makes the intended control flow harder to ignore.

Tests I cared about

The first tests were the obvious ones: a resource in the same tenant is allowed, a resource in another tenant is denied, and an unknown owner is denied.

I also added scenarios for a forged tenant claim in model-generated arguments and for a batch containing resources from different tenants. The batch case is easy to get wrong. Checking the first valid item must not authorize the rest of the batch.

The more interesting test is a property test. Instead of choosing a few tenant names by hand, proptest generates pairs and checks the invariant directly: if the tenant IDs differ, the decision must always be CrossTenant.

proptest! {
    #[test]
    fn different_tenants_are_always_denied(
        a in "[a-z0-9]{1,12}",
        b in "[a-z0-9]{1,12}",
    ) {
        prop_assume!(a != b);

        let actor = Actor { tenant: tenant(&a) };
        let owner = ResourceOwner::Tenant(tenant(&b));

        prop_assert_eq!(
            check_tenant(&actor, &owner),
            Decision::Deny(DenyReason::CrossTenant),
        );
    }
}

For this kind of library, the property is almost the product.

Where this sits next to OpenAI and Claude

Both OpenAI and Anthropic already have controls around agent tools, so I wanted to understand whether this crate was duplicating them.

OpenAI's Agents SDK has tool guardrails, tool filtering, and approval flows. A tool input guardrail can reject a call just before a custom function tool runs. That is a natural place to invoke a tenant check. OpenAI also notes that not every hosted tool goes through the same custom function-tool guardrail pipeline, so a remote MCP server still needs to enforce authorization itself.

Anthropic describes client-side tool use as a contract: Claude returns a structured request, while the application executes the operation. For an application-specific tool, the execution boundary remains under the developer's control. That is where ownership can be resolved and checked. Anthropic's broader agent-security guidance also recommends limiting tools, permissions, data, and execution environments rather than treating prompt-injection detection as a complete defense.

Those mechanisms answer related but different questions:

schema validation       Is the tool call well formed?
tool policy             Should this tool be available or require approval?
authentication          Who is making the request?
tenant ownership        Does this object belong to that caller's tenant?
action authorization    May the caller perform this operation?
scoped query or RLS     Will the data layer enforce the boundary as well?

OAuth can establish the caller and the scopes granted to a token. It cannot discover that contract-b belongs to another customer in my application's database. That last relationship is local business data, so the application still has to enforce it.

TenantInvariant is meant to fit into that gap. It does not compete with the controls in an agent SDK or MCP host.

The relevant documentation is here:

What it does not do

Version 0.1.0 is a small experiment, not a complete authorization system or a security guarantee.

It does not authenticate a user. It does not decide whether the user may read, update, or delete a resource. It does not add a tenant predicate to a database query. It also cannot prevent a race between an ownership lookup and a later, unscoped fetch.

The final operation still needs to be tenant-scoped. PostgreSQL Row-Level Security can be a useful backstop if application code gets this wrong. OpenFGA, Cedar, OPA, or an existing application policy layer may handle action-level authorization.

In other words, the full path should still look more like this:

authenticated context
  -> tenant ownership check
  -> action authorization
  -> tenant-scoped query / RLS

What I want to try next

The equality check is only a starting point. I am more interested in testing the entire route from a prompt to a database operation.

A useful test kit could inject cross-tenant resource IDs and mixed-tenant batches into real agent tool calls, then verify that every path is denied by the application's existing authorization stack. That would test the integration rather than only the small function shown above.

If I had to summarize the project in one sentence: it keeps model-generated resource IDs on the untrusted side of the authorization boundary.

I would be interested to hear where other multi-tenant SaaS or MCP implementations resolve resource ownership, and where this check lives in their request path.

The crate is available on crates.io. The source, example, and scenario tests are on GitHub. It is MIT licensed and experimental.