11 Commits

Author	SHA1	Message	Date
hataa	3e5bd081db	feat(authz): construction-enforced async decision batches (ActivationDecisions) (#6508) ... * feat(authz): construction-enforced async decision batches (ActivationDecisions) The follow-up promised in the #4541 review threads. Four review rounds traced four instances of one failure family: an async execution path whose decision-map miss silently fell back to the synchronous authorize() from a worker thread — the wrong API for loop-affine providers, and under fail_closed:false a provider error there flips a denial into an allow. The carrier was a plain dict|None held together by caller discipline. ActivationDecisions (deerflow/authz/activation_decisions.py) makes the contract construction-enforced: - a covered name returns the batched decision (unchanged semantics); - a MISS resolves per the configured provider-error policy (fail-closed denies, fail-open allows) with a loud WARNING — a miss is a prepass/consumer divergence, a construction bug, not a policy question — and never touches a provider; - None remains the sync-chain signal (synchronous authorize() is correct there); - an empty candidate set still yields an empty BATCH, not None, so an unexpected consumer name fails per policy instead of silently taking the sync path; - get_or_none lets publishers distinguish 'uncovered' from False; - fail_closed travels with the batch from the resolved authorization context. Both middlewares (_activation_allowed in SkillActivationMiddleware and SkillToolPolicyMiddleware) migrate to the type; their collectors return batches; the render-decision publisher adapts. Tests 65->70+5: type unit tests (covered/miss both directions with loud-log assertions/ get_or_none/container), middleware-level miss semantics (fail-open allows with provider.sync_calls == [], production-default fail-closed denies, None sync chain still synchronous), and mutation M18 (restoring the miss's sync fallback) verified red. 252 tests green on the affected surface. * docs(authz): sync every decision-batch contract description to the new miss semantics Review round 1 on #6508 — all documentation-level: the docstrings still described the miss-as-synchronous-fallback contract this PR removes. - _activation_allowed (both middlewares): a covered name returns the batched decision; a miss resolves per the carried provider-error policy with a WARNING and never touches a provider; None (sync chain / disabled) is the only synchronous case. - _collect_activation_decisions / _resolve_policy_registry / _active_skills_for_paths: the reason not to diverge is now a policy-resolved miss (denied under the production fail-closed default; allowed without any provider consult under fail-open; logged loudly), not a silent sync fallback. - The two _REGISTRY_LOAD_FAILED sentinel comments, same rewording. - Drop unused tmp_path/monkeypatch fixtures from the two new miss tests. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-09 16:09:17 +08:00
hataa	1cd3eb742b	feat(authz): enforce skill authorization at assembly and slash-activation (#4063 Phase 3) (#4541) ... * feat(authz): enforce skill authorization at assembly and slash-activation (#4063 Phase 3) Phase 3 / Skills — the second of three resource-type PRs (Models, Skills, Sandbox). The RBAC provider already maps "skill" → config key "skills" (rbac.py _RESOURCE_POLICY_KEYS), so no schema change is needed. Layer 1 (assembly-time, mirrors Phase 1B): - filter_available_skills_by_authorization() in skill_filter.py filters the skill-name allowlist (set[str] | None) by the provider's "skill" policy. In lead agent, runs after _available_skill_names() so the catalog (describe_skill) and SkillActivationMiddleware share one filtered set. In subagent executor _load_skills(), filters config.skills before disk load. - filter_resources_by_authorization() in enforcement.py — generic version of filter_tools_by_authorization for any resource with a name attribute. Layer 2 (slash-activation): - No new middleware code needed. SkillActivationMiddleware._resolve_activation already checks "reference.name not in self._available_skills". Since Layer 1 filters the allowlist, denied skills cannot be slash-activated. authorization.enabled: false is a complete no-op. available_skills=None (no agent allowlist) + enabled: resolves all skill names from config and filters. 12 new tests + 243 existing authz/skills tests pass. * test(subagents): wait on the chained future instead of polling done() in caller-loop teardown test * feat(authz): enforce action-scoped skill:activate at runtime and reuse the catalog loader for filter candidates * feat(authz): arm skill:activate on the subagent chain, unify the client skill-surface user, and record the Layer 2 reversal in the design notes * chore(authz): align the subagent filter's fallback user with the chain's bucket convention * feat(authz): gate autonomous skill loading on skill:activate, close the bootstrap assembly leak, and reuse one provider per subagent assembly Review round 4 (willem-bd, CHANGES_REQUESTED): - [P1] Autonomous load path: describe_skill filters its match set on the action-scoped skill:activate decision (all-denied is indistinguishable from "no match"), and ToolErrorHandlingMiddleware stamps skill_context entries only when the action allows it — a denied SKILL.md read gets a skill_context_denied marker instead, so durable context, allowed-tools policy, and autonomous secret bindings never activate a denied skill. File visibility itself stays Layer 1 (sandbox-projection semantics). - [P1] Bootstrap assembly: build_middlewares/apply_prompt_template now receive the authorization-filtered set instead of the raw _BOOTSTRAP_SKILL_NAMES, and an empty skill_names index is preserved when deferred discovery is on rather than round-tripping through None into the legacy full-metadata prompt that re-advertises a denied skill (deferred-off keeps the legacy rendering; the filtered empty allowlist blanks it on denial). - [P2] SubagentExecutor resolves ResolvedSkillAuthorization once per assembly (_resolve_skill_authorization, memoized per executor) and shares it across the Layer 1 filter (authorization=), the activation middleware, and both new gates — uncached provider factories can no longer hand the layers different instances/policy snapshots. All gates share one helper (skill_filter.skill_activation_allowed) so slash, describe, and skill-file-load cannot drift; provider errors keep the configured fail-closed/fail-open policy. skill_authorization is threaded through _build_runtime_middlewares into both runtime builders. Tests: describe gating (deny/fail-closed/fail-open/disabled), read stamping (denied marker vs entry) + extract_skills skip without warning, bootstrap three-way param (allow/deny x deferred on/off), lead + subagent chain wiring for the stamp gate, and the distinct-instance provider factory repro. Each fix is mutation-verified (reverting it fails its test). Full A/B suite run: no new failures vs HEAD. * feat(authz): re-authorize persisted skill_context before reuse and route async paths through aauthorize Review round 5 (willem-bd): - [P1] Persisted entries: skill_context survives across runs, so both consumers now re-check the action-scoped skill:activate decision before reuse. SkillToolPolicyMiddleware._active_skills_for_paths skips a denied skill (same skip as a disabled/unallowlisted one; all-denied keeps the existing fail-closed-to-builtins semantics) and _in_context_secret_sources binds no secrets for a denied entry. skill_authorization is threaded into SkillToolPolicyMiddleware on both chains. - [P2] Async provider API: skill_activation_allowed_async mirrors the sync helper through await provider.aauthorize() (same pattern as authorize_sandbox_execution_async). Async hooks precompute an activation_decisions map on the event loop (slash target + persisted entry names, one batch of awaits) and hand it to the worker-thread handler, which consults the map instead of the sync API: SkillActivationMiddleware.awrap_model_call (activation + secret binding), ToolErrorHandlingMiddleware.awrap_tool_call (_amaybe_stamp awaits the decision before stamping), and SkillToolPolicyMiddleware's awrap_model_call/awrap_tool_call (entry names + slash source name). describe_skill becomes a StructuredTool with both a sync function (invoke -> authorize) and a coroutine (ainvoke -> aauthorize), so async agent execution never routes a loop-affine provider through the sync API while sync callers keep their semantics. Tests: allow-read-then-deny-next-run regressions for secret binding and allowed-tools (partial deny does not poison, all-denied fails closed to builtins), and an _AsyncOnlyProvider (sync authorize always fails, aauthorize works) driving four async-path assertions (activation, stamp allow/deny, describe, tool policy). All six fixes are mutation-verified; full A/B suite run against HEAD shows no new failures. * fix(authz): authorize skill activation by declared Skill.name, not directory basename ShenAC-SAC's P2: bundled skills may declare a name that differs from their directory (skills/public/vercel-deploy-claimable declares name: vercel-deploy), but the runtime gates derived authorization targets from the container path. - New deerflow/skills/container_registry.py: build_container_path_registry() + canonical_skill_name() — the one path-to-Skill.name resolution shared by the activation, tool-policy, and read-stamping middlewares. - ToolErrorHandlingMiddleware resolves the read path through the (user-scoped, via new user_id kwarg threaded from both runtime builders) registry before the skill:activate decision, sync and async (registry lookup in a worker thread, aauthorize() on the loop). RBAC allow by the declared name now activates; allow by the directory name does not. - SkillToolPolicyMiddleware async hooks canonicalize the policy paths first (three-phase: thread registry -> loop aauthorize -> thread filter reusing the registry; the cached per-model-step decision still short-circuits), so the decision map is keyed by the names _active_skills_for_paths checks — no more map miss falling back to the sync provider API from the thread. _entry_names removed: persisted entry["name"] is path-derived by construction; entries are resolved by path instead. - SkillActivationMiddleware collects slash names (already canonical) plus persisted entry *paths*, canonicalized off-loop via _canonical_names_for_paths(). Regressions (test_skills_authorization.py 45->50): sync stamp target, RBAC allow declared-name/deny directory-name both directions, async stamp via _AsyncOnlyProvider, composed async slash -> tool-policy keeps the skill's tools with zero sync fallback, persisted-entry secret binding survives the name mismatch. All three mutations (stamp target, policy map key, entry canonicalization) fail their tests. * fix(authz): close the sync-fallback class on skill activation paths willem-bd's two P2s on the canonical-name fix, plus a fourth instance of the same class found while sweeping the membership: - SkillToolPolicyMiddleware: a transient prepass registry failure is now preserved (_REGISTRY_LOAD_FAILED marker) — the worker-side filter applies its own fail-closed treatment instead of silently retrying storage, which recovered skills absent from the decision map and fell back to the synchronous provider API from the thread (fail-open retaining a denied skill's allowed-tools). - SkillActivationMiddleware: an empty entry-path list no longer pays a full skill-tree scan on ordinary authorization-enabled async model steps (previously a passive path with zero registry I/O). - 4th instance (reproduced with the PR fixtures, then fixed): the entry prepass failure on the secret-binding path let the consumer-side _load_skill_registry_by_path silently recover and resolve entry names outside the decision map — the same sync fallback, fail-open binding the aauthorize-denied skill's declared secret. The fix goes one step further than failure propagation: the prepass hands down the registry *snapshot* the decision map was keyed by, and entry sources resolve against that snapshot, so a map miss is impossible by construction (this also closes the narrower window where both loads succeed but disagree because storage changed mid-step). The slash source is deliberately unaffected: it does not consult the decision map (validated once at activation) and keeps its fresh per-call load. - Class membership swept: skill_activation_allowed() sync call sites are exactly four (stamping sync path and describe's sync implementation are legitimately sync); the only two async-reachable fallback points (the _activation_allowed helpers) are both construction-guarded now. Structural hardening (typed async-batch decision object where a map miss is fail-closed by construction) recorded in the plan notes as a follow-up, anchored at those two helpers. - _RegistryArg type alias replaces the degenerate dict|object|None union in the policy middleware signatures. Tests (test_skills_authorization.py 50->54): transient prepass failure -> builtins-only with exactly one storage attempt and zero provider calls; ordinary async step -> zero registry scans; two-call scenario -> entry binding zeroed while the slash binding survives; entries resolve against the prepass snapshot under a mid-step rename. Mutations verified red: marker reverted to None, over-broad slash kill, snapshot bypass. * fix(authz): correct secret-binding reference points and gate the rendered skill reminder Review round 9 (willem-bd) plus construction-audit follow-ups on the same class — every async divergence between two loads of the same data now has an explicit, pinned reference point: - Slash secret source resolves from a FRESH post-activation registry: the prepass snapshot is taken before the aauthorize awaits, so binding the slash source from it would activate NEW_KEY content while injecting OLD_KEY when a skill's declared secrets change in that window. The 'one scan per step' bonus that motivated sharing the snapshot is withdrawn — consistency wins. The two secret sources resolve independently: a transient fresh-load failure zeroes only the slash binding; entries keep binding from their own snapshot. - Same-skill dominance: when a skill is both the slash source (fresh) and a persisted entry (snapshot), only the activation-era declaration binds — unioning both eras injected a secret the skill no longer declares. Aligns with the tool-policy rule (slash activation dominates for the run); different-skill entries still stack additively. - The rendered 'Active skills' reminder (DurableContextMiddleware) no longer advertises skills the provider denies — surface consistency with describe_skill. Publication/consumption split: the activation middleware publishes per-step path-keyed skill:activate decisions into the run context (async: reused from the prepass snapshot, zero extra I/O; sync: one scan + authorize() only when entries exist — passive steps stay scan-free), the renderer consumes them and filters its render copy (state untouched; unpublished = permissive, matching the other run-context carriers). New carrier key listed in REDACTED_CONTEXT_KEYS with a redaction regression. - Wiring regressions on both chains for everything added above (user_id to the stamp gate, skill_authorization + token pairing + activation- before-durable ordering to the durable renderer): each mutation verified red (M4-M13 across this change set). - Tests 54->65: slash post-activation lookup, source independence, dominance, sync-chain sync-API path, render filter (async/sync/ disabled with load-count assertions), chain wiring x2, redaction listing. Plan notes record rounds 9-2..6 including the reference-point post-mortem and the audit axes exhausted. * fix(authz): anchor same-skill dominance on the slash identity, not binding results Review round 10 (willem-bd) plus a self-audit extension the new checklist items caught in the first fix itself: - R10 (P2): the same-skill exclusion was derived from successfully BOUND slash sources. When the prepass snapshots required-secrets [OLD_KEY] and the operator strips the declaration during the await window, the slash source binds nothing (required_secrets gate) — the exclusion set stayed empty and the stale entry view kept injecting OLD_KEY for a skill that now declares no secrets. The exclusion now derives from the AUTHENTICATED slash activation identity (run-context source path, owner-token checked): the identity's declared name resolves from the fresh registry first, then the entry snapshot, and joins the exclusion set regardless of binding success. - Self-audit (value->gate->downstream on the fix itself): the declared name can also change mid-run (same path, foo->bar). A name-anchored exclusion then holds only the new name while the snapshot entry resolves the same path to the old one — both eras bound again. The PATH is the stable identity shared by the activation and every earlier read: entries at the slash identity's path are now excluded before registry resolution (exclude_paths), independent of what either version calls the skill; the name-based set remains for cross-path same-name shadowing. Tests 65->67: no-secrets-era dominance (ACTIVE secrets None under the OLD_KEY-to-empty interleaving), path-anchored dominance across a mid-run rename (only the activation-era key binds). Mutations verified red: identity-derived exclusion disabled (M14), path exclusion disabled (M16). * test(authz): pass explicit config to lead middleware wiring test --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-09-30 19:45:07 +08:00
Zeren Wang	82671596f3	feat(authz): add plugin resource targets, provenance, action and management enforcement (#5842) ... * feat(authz): add plugin resource targets, provenance, action and management enforcement PR1 of the extension-tool-authorization series (docs/plans/2026-09-24-extension-tool-authorization-spec.md): plugin authorization plumbing, no new author-facing declaration. - `authz/plugin_targets.py` is the single encoder/validator for composite targets (`namespace/part`), with one validating composer behind three kind-checked constructors; invalid input raises instead of degrading. - `authz/plugin_authz.py` is the harness decision layer (`plugin_action`, `plugin_management`, plus the batch filters the page slice will consume): disabled is a no-op, an explicit deny raises, and provider errors follow `fail_closed` like the sandbox gate. - `POST /api/plugins/{ns}/actions/{name}` decides `plugin_action:invoke` after the action resolves and before the body is streamed. - `deerflow_extension_api.auth` publishes `require_plugin_management` / `arequire_plugin_management` with two `app.state` resolver keys; the Gateway installs both. Contract version 0.2.3 -> 0.2.4. - `tools/tool_provenance.py` records host-written plugin provenance for display (assembly descriptor, Layer-2 context later); no decision reads a label. - Plugin providers use a `(config signature, loop key)` cache so a loop-affine provider is never handed to another loop or to a sync caller. - RBAC gains `plugin_actions` / `plugin_management` aliases; `config_version` 47 -> 48 across the three mirrors. Tests: new plugin target/provenance/action/management suites plus a blocking-IO anchor whose offloads were reverted to prove red->green. * fix(authz): decide plugin resources from the request's config snapshot Review round 1 on PR #5842 (willem-bd). P1 — the decision layer no longer reloads the configuration. The six `authz/plugin_authz.py` functions take a required `app_config` snapshot (the same request-scoped config the Gateway used to resolve the provider), and `resolve_/aresolve_plugin_authorization` return it as a third element, so `enabled`/`fail_closed` can never come from a second read that drifted from the one that produced the provider. A snapshot the caller could not read at all is *unavailable*, not disabled: it fails closed as `authz.config_unavailable`. The Gateway's `_plugin_app_config` now separates an absent `config.yaml` (no gate, today's behavior) from a config that exists but cannot be read or validated (deny) instead of swallowing both through `safe_app_config`. P2 — `_validated_decision` requires `type(decision.allow) is bool` on both the sync `authorize` and async `aauthorize` paths, so a provider returning `AuthzDecision(allow="false")` is a malformed verdict that follows `fail_closed` instead of being read as an allow. Both fixes are covered by regression tests that were verified red against the pre-fix behavior (P1: 200 vs 403 and resolver True vs False; P2: 12 cases across fail_closed/fail_open and sync/async), plus tests pinning that an absent config and `authorization.enabled: false` keep today's behavior. * fix(authz): treat a request-time config absence as unavailable Review round 2 on PR #5842 (willem-bd). P1 — `_plugin_app_config[_async]` no longer maps a missing `config.yaml` to `None` ("no gate"). A Gateway cannot have started without a readable config (`app/gateway/app.py` reads it through this same accessor in `lifespan`), so absence *during a request* means the configuration this process was running on became unavailable — a hot reload, an atomic replace, a ConfigMap remount. It is unavailable, not disabled: the error propagates, `resolve_/aresolve_plugin_authorization` raise `_PluginAuthorizationUnavailable(fail_closed=True)`, the action dispatcher returns 403 and the management resolvers answer `False`. The dead `(None, None, None)` allow path is gone, the resolvers return a non-optional `AppConfig` as their third element, and callers key "authorization disabled" on `provider is None` alone. This matches the rule the decision layer already documented (`authz.config_unavailable`) and the public docs. P2 — `_deny_reason_code` is total: a `reasons` that is not iterable degrades the code to `authz.denied` instead of raising `TypeError` outside the guarded provider path, which turned a denial into an unhandled error. It is deliberately not folded into `_validated_decision`: `allow` was a real `bool`, so the verdict is a valid denial, and treating it as malformed would flip it to an allow under `fail_closed: false`. Both fixes are covered by regression tests verified red against the pre-fix behavior (P1: resolver True vs False, async `PermissionError` not raised, route 200 vs 403; P2: `TypeError: 'NoneType' object is not iterable` at `plugin_authz.py:113`). The action-route tests in `tests/test_plugin_contributions.py` now install a readable `authorization.enabled: false` config instead of relying on a config-less process, and `docs/full-stack-plugins.md` plus the PR1 decision log record the new rule. * fix(authz): apply the running policy when the plugin config is unreadable Follow-up to f03d2ea9 (review round 2 on PR #5842, willem-bd). The first attempt read the P1 finding as "absence is never disabled" and failed every config read closed unconditionally. That is too broad for this repo: a config-less host is deliberately treated as having no policy to apply (`_get_route_authorization_config` falls back to a disabled config, `sandbox_authz.safe_app_config` documents the same no-op for "CI runners and direct-call tests"), and the rule turned the config-less e2e plugin host (`extension_test_fixtures.bookmark_plugin_gateway`) into a 403 — the three `bookmark-plugin.spec.ts` cases lost the save action. Reproduced locally: `POST /api/plugins/community.bookmarks/actions/save` against that fixture host returned 403 before, 200 after this change. The rule is now "has this process loaded a configuration?", not "was the last read successful?": - No loaded config (`peek_loaded_app_config()`, new read-only accessor on `deerflow.config.app_config`) and no `config.yaml`: no policy to apply, so the gate stays a no-op — unchanged for CI runners, direct-call tests and hosts that mount only the plugins router. - A loaded config whose file disappears or cannot be read: *unavailable*, never *disabled*. The resolvers raise `_PluginAuthorizationUnavailable` carrying the failure flag of the configuration this process runs on (authorization disabled there -> no gate; enabled -> that policy's `fail_closed`, `True` by default), so an enabled Gateway answers 403/False in the window instead of letting protected plugin actions and management routes through. - A config file that exists but cannot be read or validated right now: fail closed when nothing is loaded (round 1's rule), otherwise the loaded policy decides. `peek_loaded_app_config()` is preferred over a Gateway-side startup snapshot: it reflects the last successfully loaded config, so a hot-reloaded policy is what applies during the window, and there is no lifecycle hook to keep in sync. Evidence: the three no-config/lost-config branches in `tests/test_plugin_management_guard.py` and `tests/test_plugin_action_authorization.py`, round 1's unreadable-config tests unchanged, `test_peek_loaded_app_config_survives_a_missing_file` in `tests/test_app_config_reload.py`, and the fixture-host probe above. Docs (`docs/full-stack-plugins.md`, `reference.mdx` en/zh) and the PR1 decision log state the final rule; the log records the superseded variant. * fix(authz): keep a denial whose reasons raise while being read * fix(authz): intersect plugin batch filters with the candidates The plugin_page/plugin_management batch helpers returned the provider's `filter_resources` answer verbatim, so a custom provider could hand the projections a target that was never asked about ("*", another namespace, a phantom page). Every other filter call site re-projects from its own candidate list; do the same here, state the intersection on the provider contract, and pin it with a regression test that fails on the old pass-through. * docs(plugins): map a management denial to 403 in the route example The contributed-route example called `arequire_plugin_management` and let the documented `PermissionError` escape. The Gateway installs no `PermissionError` handler, so a route copied from the example answered 500 on a normal policy denial instead of 403. Both example routes now translate the denial, and the surrounding bullets say why the translation is the route's job. * docs(extensions): point the 0.2.4 contract row at the PR that ships it Every other row in the version-history table links the pull request that shipped the version; 0.2.4 linked the authorization tracking issue instead. Both the English and Chinese tables now link this PR.	2026-09-25 14:46:12 +08:00
hataa	d811143b52	feat(authz): filter per-caller skill visibility on the skill listing surfaces (#4063 Phase 4) (#5489) ... * feat(authz): filter per-caller skill visibility on the listing surfaces (#4063 Phase 4) GET /api/skills, GET /api/skills/custom, and GET /api/skills/{name} now filter the user-scoped catalog through filter_resources(principal, "skill", ...) — mirroring list_models. Anonymous callers are unfiltered; provider errors follow authorization.fail_closed (fail-closed -> empty listing / 404, fail-open -> full listing). An invisible skill on the detail surface returns the standard 404 so the endpoint cannot become an existence oracle the filtered list closed. Management endpoints stay require_admin_user-gated; runtime activation is #4541's layer. resolve_skill_authorization joins resolve_model_authorization as a thin sibling over a shared _resolve_route_scoped_authorization core. * docs(authz): reflect per-caller skill visibility in OpenAPI metadata and implementation notes (#5489) Address the two non-blocking review findings on #5489: - The three user-facing GET routes (/skills, /skills/custom, /skills/{name}) now say in their /docs-visible descriptions that authorization filters the response (hidden skills 404 on detail). - Add the dated Phase 4 decision-log entry to the authorization implementation notes, per the convention of every prior merged authz PR: listing-visibility semantics, the 404-vs-403 existence-oracle rationale, anonymous-caller behavior, and the #4541 rebase reconciliation points (config.example.yaml roles comment + this file's decision log). * docs(authz): move route guidance into Gateway module guide --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-09-18 08:02:52 +08:00
PeaceMaker-best	137a3cb60d	fix(authz): recheck policy before sandbox reuse (#5006) ... * fix(authz): recheck policy before sandbox reuse * fix(authz): avoid duplicate async sandbox checks * fix(authz): scope sandbox decision across middleware * fix(authz): construct async providers on the event loop * test(authz): avoid cold imports under Blockbuster --------- Co-authored-by: 嗜鵼 <hy2010hy2010@qq.com> Co-authored-by: PeaceMaker-best <221849497+PeaceMaker-best@users.noreply.github.com> Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-08-30 15:29:51 +08:00
hataa	cc6a2657e7	feat(authz): enforce sandbox:execute authorization at sandbox acquisition (#4063 Phase 3) (#4911) ... Sandbox is an execution environment, not a named resource: multiple tools (bash, read_file, write_file, glob, grep, ...) depend on it, all funneled through ensure_sandbox_initialized / ensure_sandbox_initialized_async. Gate the single acquisition entry point (single source of truth) instead of maintaining a sandbox-tool-name set in middleware: - authorize_sandbox_execution helper (authz/sandbox_authz.py) checks authorize("sandbox", "execute", target="*") — a binary judgment (can this role use the sandbox at all); RBAC allow:"*"/true permits, allow:[]/false denies. - lazy path: ensure_sandbox_initialized (+ async) calls the gate before provider.acquire. - eager path: SandboxMiddleware.before_agent / abefore_agent call the gate before _acquire_sandbox. - deny raises SandboxAuthorizationError (SandboxError subclass) which propagates through tool execution as a friendly ToolMessage (RFC §9: 'not a crash'). - authorization.enabled: false is a no-op everywhere; provider errors follow fail_closed (deny) / fail_open (allow). 12 tests in tests/test_sandbox_authorization.py cover disabled/allow/deny/ deny-via-bool/no-policy-unrestricted/provider-error-fail-closed/open/ internal-caller + ensure_sandbox_initialized deny (never acquires) and allow (acquires) integration paths.	2026-08-24 16:32:06 +08:00
hataa	540940bac1	feat(authz): enforce model authorization at Gateway routes and runtime (#4063 Phase 3) (#4540) ... * feat(authz): enforce model authorization at Gateway routes and runtime (#4063 Phase 3) Phase 3 / Models — the first of three resource-type PRs (Models, Skills, Sandbox). The RBAC provider already maps "model" → config key "models" (rbac.py _RESOURCE_POLICY_KEYS), so no schema change is needed. Gateway route layer (mirrors Phase 2A): - resolve_model_authorization() in authz.py returns (provider, principal), reusing _get_cached_route_provider and build_principal_from_context, including the INTERNAL_SYSTEM_ROLE → None pop for internal callers. - list_models filters via provider.filter_resources(principal, "model", names). - get_model checks provider.authorize("model", "use"). Deny → 403 (not 404, since the model exists but the role lacks permission). Runtime resolution layer (mirrors Phase 1B): - _authorize_model_name() in agent.py runs after _resolve_model_name. On deny, falls back to the first allowed model (RFC §9: graceful, not crash). All models denied + fail_closed → ValueError (matches existing contract). authorization.enabled: false is a complete no-op on both layers. Anonymous requests (user=None) bypass filtering. 18 new tests + 314 existing tests pass. * fix(authz): enforce model:use on the embedded DeerFlowClient path (Phase 3 follow-up) Round 4 review (willem-bd): _authorize_model_name only covered the Gateway runtime path (_make_lead_agent). The parallel lead-agent construction path DeerFlowClient._ensure_agent (client.py) filtered tools but not the model, so a library/embedded consumer with role-scoped model policies could run a model the role is denied model:use for. - Insert _authorize_model_name in _ensure_agent, mirroring _make_lead_agent. - Resolve None default to the first configured model before the gate so the implicit default (create_chat_model(name=None)) is also authorized. - Update test_authorization_filters_framework_tools_and_reuses_provider: the stub provider now returns an allow decision for model:use (checked during assembly) and patches resolve_authorization_provider in the agent namespace. - Add 3 DeerFlowClient._ensure_agent path tests (real-path fallback, None-default resolution, disabled no-op); 24 tests total. * docs(authz): document get_model provider-unavailable fail-open path + test zhfeng review (round 5): get_model's docstring only mentioned the deny→403 path, not the provider-resolution-error + fail-open path (which allows the request, mirroring list_models's documented fail-open semantics). The behavior itself is correct and symmetric with list_models, but it was undocumented and the _AuthorizationUnavailable path had no test coverage. - Extend get_model docstring to state the provider-error fail-closed/fail-open outcome, matching list_models's wording. - Add test_get_model_provider_unavailable_fail_closed_vs_open exercising the _AuthorizationUnavailable path (provider cannot be resolved at all), pinning fail-closed→403 / fail-open→200. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-08-01 22:34:11 +08:00
hataa	6091ce7576	feat(authz): derive Gateway route permissions from AuthorizationProvider (#4439) ... * feat(authz): derive Gateway route permissions from AuthorizationProvider (Phase 2A, #4063) Phase 2A: replace legacy _ALL_PERMISSIONS with provider-derived route permissions. When authorization.enabled, each threads:*/runs:* permission is evaluated independently via provider.aauthorize(resource='route'). Disabled mode preserves legacy behavior. owner_check and require_admin_user remain unchanged. 10 new tests: disabled/enabled/RBAC policy/fail-closed/fail-open/ authenticate integration/middleware integration. * fix(authz): move AuthorizationConfig import to runtime for fallback in _get_route_authorization_config	2026-07-27 14:19:04 +08:00
hataa	7857fa0cce	feat(authz): enforce tool authorization at assembly and runtime (#4370) ... * feat(authz): enforce tool authorization at assembly and runtime * fix(middleware): guard deferred tool setup lookup (#4370) --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-07-23 22:51:35 +08:00
hataa	92c8f2f03b	feat(authz): add built-in RBAC provider and provider factory (#4260) ... * feat(authz): add built-in RBAC provider and provider factory (Phase 1A-2, #4063) Phase 1A-2: RBAC provider + provider factory. No runtime behavior change. New authz/rbac.py — RbacAuthorizationProvider: - allow: '*' / True / list / [] / missing → deny-wins semantics - deny always overrides all allow forms - resource name explicit mapping (tool→tools, model→models, etc.) - unknown/missing role raises ValueError (never silent allow) - config compiled to immutable frozensets at construction - filter_resources preserves order, no mutation, consistent with authorize - sync == async decisions New authz/runtime.py — resolve_authorization_provider: - disabled → None (no import attempted) - enabled + no provider → ValueError - invalid class path / construction failure → ValueError with path - isinstance Protocol check post-construction - no caching, no fail_closed/default_role injection 48 tests (37 RBAC + 11 factory). No config schema change, no config_version bump. Per RFC #4063 Phase 1A-2. Layer 1/Layer 2 wiring deferred to Phase 1B. * fix(authz): reject unknown RBAC provider config Fail fast on misspelled top-level RBAC settings, cover factory error propagation, and record Phase 1B policy and audit caveats. * fix(authz): reject unreachable resource aliases Fail fast when RBAC config uses reserved request-side aliases, preserve same-name and custom resources, and add regression coverage for every mapped alias. * fix(authz): validate RBAC request identifiers	2026-07-21 09:23:14 +08:00
hataa	10890e10a8	feat(authz): propagate trusted authorization principal context (#4203)	2026-07-17 14:49:51 +08:00