The next question for agent trust may be less "what setting did I pick?" and more "who supplied the setting I am running under?"
That question matters for builders, operators, and enterprise reviewers because agent behavior now sits on several layers at once: local config, project config, managed policy, requirements, account claims, and tool subscriptions. A user may see one menu or one setup wizard, but the runtime still has to know which layer made a rule true.
Yesterday's edition followed tool menus becoming runtime contracts. Today's evidence moves one step upstream. The menu is not the beginning of the story. It is downstream of delivered policy and entitlement checks.
Codex adds the bundle pipe
OpenAI Codex commit e93dc98a adds the transport types for a cloud config bundle endpoint. The patch wires generated backend models and a client method for both /api/codex/config/bundle and /wham/config/bundle.
The commit is careful about scope: it describes itself as transport-only plumbing and says there are no runtime config behavior changes in that PR. That caveat is important. The evidence does not show a finished remote policy system. It shows the backend surface where cloud-delivered config and requirements can travel together.
For a reviewer, that is already a meaningful line. Once config and requirements arrive through a bundle endpoint, the runtime needs to preserve more than values. It needs to preserve provenance: which source supplied which rule, and what should happen when layers disagree.
Requirements become ordered layers
The next Codex commit, 20debf74, builds that composition machinery. It adds a requirements-layer engine where lower-priority layers provide defaults and higher-priority layers win conflicts, matching the broader config layering model.
The interesting part is that Codex does not treat every field as plain TOML replacement. The new code gives domain-specific behavior to fields that would be risky or misleading if merged mechanically. Filesystem deny_read patterns become an additive high-priority-first union. Hook events append in priority order. Managed hook directory conflicts for the active platform fail closed. Provenance points to the exact source when one layer owns a value and becomes composite when a table is assembled from several layers.
That is policy becoming a data structure. The question is not only whether an agent can load requirements. It is whether it can explain how several requirement sources combined into the active rule set.
Cloud config gets a name tag
Codex commit 8a556296 makes the provenance layer more explicit. It adds enterprise-managed cloud config as a first-class config layer source with a backend-supplied id and display name.
The patch preserves that identity through config loading, diagnostics, debug output, hook attribution, and app-server protocol surfaces. It also resolves relative paths from a stored config base so cloud-delivered config keeps semantics similar to existing managed config behavior.
Again, the commit sets a boundary: this is pull-based and snapshot-oriented, not dynamic reload behavior. That makes the grounded claim stronger, not weaker. Codex is adding the receipt layer before claiming live remote control. If a cloud-delivered config fragment fails to parse or supplies a hook, the runtime can identify the managed layer by name instead of pretending it came from an invisible file.
Hermes makes tool access visible before it is granted
NousResearch Hermes Agent shows the same upstream pressure from the setup side. Commit 1fc7bdc5 changes the hermes tools picker so Nous-managed Tool Gateway backends are always listed, even when the user is logged out or not yet entitled.
That does not mean the tools simply turn on. Selecting one runs inline Nous Portal device-code OAuth and an entitlement check. The commit says the row only activates the gateway once access is confirmed, and it avoids switching the user's inference provider or prompting to enable every other tool.
This is a different implementation from Codex, but the trust problem rhymes. The visible choice is not the same as active capability. A setup surface can advertise a managed tool path, but the runtime still needs a gate that says whether this account, this tool, and this moment are allowed to use it.
The entitlement is not one switch
A second Hermes commit, e1c7a9aa, makes that gate more granular. Hermes reads Portal tool_access claims into a tool-access structure, treats managed Tool Gateway entitlement as paid access or a live tool pool, and then narrows availability by category.
The commit's own example is useful: the pool funds web, image, TTS, and browser coverage, but not video. Setup now renders a per-tool checklist when the pool is enabled and filters eligible tools from the entitlement snapshot.
That detail prevents the story from becoming a vague subscription narrative. The point is not "subscription equals tools." The point is that tool access is turning into structured policy: coarse entitlement first, category entitlement next, setup choices after that.
The control plane needs receipts
These commits do not prove a shared standard. They do not prove Codex and Hermes are coordinating. They do not prove every enterprise policy or managed tool path is live for every user.
They do show the same practical pressure in two agent projects. Codex is creating bundle transport, requirements composition, and named cloud-managed config layers. Hermes is making managed tool choices visible while tying activation to login, entitlement, and per-category coverage.
That is why agent policy is moving into delivered layers. The settings screen is becoming only one witness. The more important receipt is the chain behind it: which service delivered the config, which layer won the merge, which requirement added the deny rule, which account claim unlocked the tool, and which category stayed blocked.
The next thing to watch is whether agent tools expose those receipts to the people supervising them. A serious runtime should not only say "web search is available" or "this sandbox is enforced." It should be able to answer the follow-up: available because of which layer, enforced by which source, and inspectable by whom?