Build 1 publisher2 min readPublished September 6, 2026 at 5:49 AM PDT

Private struct fields move an agent's write check from every caller to one Rust module

A dev.to write-up rebuilds an agent's memory-write guardrail as a Rust type whose fields nothing outside the custody module can fill, which is a firm guarantee about ordering and a much weaker one about the policy itself.

The Engineer · Build desk

Illustration accompanying Private struct fields move an agent's write check from every caller to one Rust module

What happened

A dev.to write-up on agent safety asks why the dangerous function accepts an unchecked action at all, instead of asking which runtime guardrail belongs in front of it.
In the starting version, validate returns a bool and persist takes the proposed write, so a caller added six months later can call persist on its own and still compile cleanly.
The rewrite splits one struct into ProposedWrite, whose authority is a String, and AdmittedWrite, whose authority is an Authority, and persistence accepts only the admitted type.
AdmittedWrite is declared inside a custody module whose single public entry point, evaluate, takes a proposed write and returns either an admitted write or a rejection.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

constraint The discipline buys sequencing, while judgement stays with validate_authority itself, so a validate_authority that approves too much passes review by the compiler and ships intact.
cost Adoption is a signature migration billed at build time, and it is paid by whoever owns every layer that currently hands a proposed write to persistence.
capability Proving that an unadmitted write cannot reach storage becomes a matter of reading one module's export list, rather than tracing every path that ends in persistence.
exposure The custody module becomes the trust boundary itself, so any helper later added inside it can mint an admitted write without evaluating anything.

The interesting detail is which items carry `pub`. The `custody` module exports the type `AdmittedWrite` with private fields, three read-only accessors, and one function that returns the type ^[5]^[6]. Four public items exist. Only one of them can produce an admitted write ^[1].

In Rust a struct literal requires every field to be visible at the site where you write it, and the post is right that this one distinction carries the whole boundary ^[7]. Field privacy is what makes it hold. The set of code that can name the type is everyone; the set that can construct it is the code that can see the private fields ^[2]. `evaluate` sits in that second set, runs `validate_authority`, and builds the struct only after that call returns successfully ^[6].

Reading survives in a useful shape. Downstream code that used to reach into `write.key` goes through `key()` and `value()`, which hand back references ^[5]. The persistence layer only reads an admitted write, since assembly happens inside the custody module.

The compiler enforces ordering here; authorization is a separate, runtime decision. `validate_authority` still runs at runtime inside `evaluate` ^[6], so a policy that says yes too often compiles and ships exactly as it did before ^[4]. The type system's opinion of your authority policy is that it exists.

The post names the pattern typestate and calls it the type-level cousin of Alexis King's "parse, don't validate" ^[8]. It also corrects itself in public: an earlier version leaned on the phrase "provided we control how that type is constructed" without delivering that control, and the module rewrite is what closes the gap ^[9]. That was the right thing to fix, because the phrase was the load-bearing part.

For this to transfer to a running agent service, one thing has to be true in your own tree: no other item inside the custody module, and no trait implementation on the type, can produce an `AdmittedWrite` without going through `evaluate`. The version of the post available to us breaks off mid-sentence just after the struct-literal rule ^[11], and the complete runnable example sits on GitHub ^[10], so that wider construction surface is something to check locally rather than something the argument settles. What the work buys is a review that fits inside one module, and a policy review that is exactly where it was.

What to watch

Whether the GitHub example puts a derive, builder, or deserialization path onto AdmittedWrite, which would reopen construction outside evaluate.
Whether the finished post covers the case where custody and the persistence layer live in different crates.
Whether the pattern is shown against a real tool boundary, where the proposed write arrives as model-generated JSON.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
The dev.to post frames its question as why the dangerous function accepts an unchecked action in the first place, rather than which runtime guardrail to place in front of the dangerous operation; the author says the usual answer is to put a guardrail in front and that he has built examples that work that way.
ReportedSupportedView cited source
[2]
The starting example has struct ProposedWrite { key: String, value: String, authority: String }, a function fn persist(write: ProposedWrite), a validator fn validate(&ProposedWrite) -> bool, and application code of the form: if validate(&write) { persist(write); }
ReportedView cited source
[3]
The post states that persist() will happily accept a ProposedWrite that has never been validated, that the design relies on every caller remembering the protocol, and that if somebody adds a bare persist(write); six months later the compiler sees nothing wrong because the type is correct while the application is wrong.
ReportedView cited source
[4]
The rewrite splits the value into two types: ProposedWrite with authority: String, and AdmittedWrite with authority: Authority. Persistence is then declared as fn persist(write: AdmittedWrite), accepting only the second type.
ReportedView cited source
[5]
In the revised code AdmittedWrite is declared pub inside mod custody, its fields key, value and authority are not marked pub, and the module provides pub accessor methods key(), value() and authority() that return references. The post notes the struct is public so other modules can name the type and accept it in signatures, while its fields are private.
ReportedView cited source
[6]
mod custody exposes pub fn evaluate(write: ProposedWrite) -> Result<AdmittedWrite, Rejection>, which calls validate_authority(&write.authority)? and then constructs AdmittedWrite with a struct literal using the returned authority. Authority, Rejection and validate_authority are defined in that module.
ReportedView cited source
[7]
The post states that in Rust a struct literal such as custody::AdmittedWrite { key, value, authority } requires every field to be visible at the construction site, and that this distinction is the whole boundary.
ReportedView cited source
[8]
The post names the technique the typestate pattern, encoding a value's state in its type so only valid transitions type-check, and calls it the type-level cousin of the principle Alexis King named 'parse, don't validate': instead of checking a value and handing the same type onward, you transform it into a new type whose existence proves the check already happened.
ReportedSource: dev.to post, crediting Alexis King for 'parse, don't validate'View cited source
[9]
The author writes that the phrase 'provided we control how that type is constructed' was doing all the work in the previous section, that this is where the earlier version of the article was too loose, and that the module-with-private-fields code is where the control is actually delivered.
ReportedSource: the dev.to post's author, on his own earlier draftView cited source
[10]
The post says the complete runnable example is on GitHub.
ReportedView cited source
[11]
The available text of the post ends mid-sentence immediately after stating that a struct literal requires every field to be visible at the construction site.
ReportedView cited source
[d1]
The custody module as shown exposes four public items tied to AdmittedWrite - the type itself, three read-only accessors, and evaluate - of which only evaluate returns a constructed AdmittedWrite.
Derived
[d2]
Because the fields are private and a struct literal needs every field visible where it is written, the set of code that can construct an AdmittedWrite is the code inside mod custody, while any module can still name the type in a signature.
Derived
[d3]
After the change, any existing call site that passes a ProposedWrite to persist fails to compile, because persist accepts only the distinct AdmittedWrite type.
Derived
[d4]
The compiler enforces only that evaluate ran before persist; the authority decision itself is ordinary runtime code inside evaluate, so an over-permissive validate_authority still compiles and ships.
Derived
[d5]
The review question changes from checking that every caller of persist validated first to reading what one module exports.
Derived

Sources

Publishers with included, body-backed reporting in this cluster.

dev.to
1 article · September 6, 2026
Can Rust Make Unsafe AI Agent Actions Unrepresentable?

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Superseded by the complete assessment submitted alongside this call.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

EvidenceInsufficient: Superseded
This duplicate call is withdrawn; the complete assessment accompanies it.
AdoptionInsufficient: Superseded
This duplicate call is withdrawn; the complete assessment accompanies it.
Hype gapInsufficient: Superseded
This duplicate call is withdrawn; the complete assessment accompanies it.
IncentivesInsufficient: Superseded
This duplicate call is withdrawn; the complete assessment accompanies it.
ConfidenceInsufficient: Superseded
This duplicate call is withdrawn; the complete assessment accompanies it.

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Claim ledger

Let Clarity write the post for you.

Perspective Coverage

Reality

Sources