(MOT-4220) feat(harness): default dispatch to deny-only policy - #594
Draft
ytallo wants to merge 2 commits into
Draft
(MOT-4220) feat(harness): default dispatch to deny-only policy#594ytallo wants to merge 2 commits into
ytallo wants to merge 2 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
skill-check — worker0 verified, 50 skipped (no docs/).
Four for four. Nicely done. |
Make `allow` optional: a present function policy permits every function not
matched by `deny`. Ship `default_functions` as `{ "deny": [] }`, so new sends
and parentless workers receive full function access unless an operator narrows
it.
Preserve legacy explicit `allow` scopes, deny precedence, frozen turn
inheritance, reaction inheritance, and child non-escalation. Execute
structurally allowed calls immediately when no approval gate is installed;
approval hooks still hold or deny calls when present. Fail closed for missing
persisted authority, explicit `allow: []`, unknown policy fields, empty globs,
and malformed globs.
Add the INT-010 / INT-011 integration fixtures, a cross-worker compatibility
matrix in the approval-gate suite, and CI coverage for approval-gate changes.
`FunctionPolicy::default()` flips from deny-all to permissive, so eval's
`normalize()` now builds an explicit empty allow-list to keep its documented
"omitted means deny all" contract.
Fixes MOT-4220
ytallo
force-pushed
the
feat/harness-default-functions
branch
from
July 31, 2026 00:54
d571e52 to
2420290
Compare
Extract the native arm of `build_tools` into a pure `native_tools(policy, registry)` so the dispatch policy's effect on the MODEL-FACING tool list is testable without a live `Deps`. Behavior is unchanged: same order (intercepted subscription controls first, then registry order), same allocations. The empty-surface `tracing::warn!` stays in `build_tools`, which owns the `session_id` it interpolates. Five tests pin what was previously untested: a denied id is absent from the surface rather than merely uncallable; a legacy allow-list narrows the controls too, so a narrow child cannot pick up `engine::register_trigger`; an explicit empty allow-list and a missing policy both expose nothing; controls lead and never duplicate a registry id; and an unhydrated descriptor still ships a usable object schema.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
allowoptional: a present function policy permits every function not matched bydenydefault_functionsas{ "deny": [] }, so new sends and parentless workers receive full function access unless an operator narrows itallowscopes, deny precedence, frozen turn inheritance, reaction inheritance, and child non-escalationallow: [], unknown policy fields, empty globs, and malformed globsBehavior and compatibility
Without an approval gate, the harness now behaves as YOLO by default. Explicit
denyglobs remain the primary restriction. Existing callers that sendallowkeep their positive-scope behavior, anddefault_functions: nullstill restores deny-all for new turns.Ask mode continues to cap requests at the configured default policy; because the shipped default is permissive, operators that want a read-only or deny-all ask mode must configure that ceiling explicitly.
Validation
cargo test --manifest-path harness/Cargo.toml --all-featurescargo test --manifest-path harness/Cargo.toml -p harness-integrationcargo test --manifest-path approval-gate/Cargo.toml --all-featurescargo clippywith-D warningsfor harness and approval-gateFixes MOT-4220