chore(deps): bump the dependencies group across 1 directory with 2 updates

[dependabot]

Updates the requirements on fastapi-guard and guard-core to permit the latest version.
Updates fastapi-guard to 8.0.2

Release notes

Sourced from fastapi-guard's releases.

v8.0.2 (2026-09-26)

Community fixes and exempt_ips lockstep: trailing-slash route config, block response Content-Type, live-smoke exempt_ips scenario; guard-core 4.1.0 tracking (v8.0.2)

• Fixed - Route decorator config now resolves through Starlette's trailing-slash redirect (#142): when the request path matches no route but toggling the trailing slash does, the middleware reads the config of the route Starlette would 307-redirect to, so a route override registered on /path now governs a request to /path/ (and vice versa) instead of silently falling through to the global defaults. Each router decides with its own redirect_slashes (mounted apps for their paths, the including app for an included router's routes), the root path and directly matched requests are untouched.
• Fixed - Block responses now declare Content-Type: text/plain (#144): the Starlette response factory left Starlette's media type unset, so middleware-generated 403/429/400 pages went out without a content type and clients were left guessing. The factory now passes media_type="text/plain", matching the engine's reference response factory.
• Tests - New live-smoke scenario tests/live_smoke/scenarios/exempt_ips.py (#145) covering the guard-core exempt_ips skip-list end to end through the live stack: an exempt IP exceeding rate_limit keeps getting 200 across the crossing while no rate-limit bucket is written for it at all (smoke:rate_limit:rate:<ip> stays absent in Redis, pinning that the exempt skip sits ahead of the limiter), a penetration-detection payload from the exempt IP still gets 400 (exemption is not immunity), the identical sequence without exempt_ips throttles at the crossing with 429 and leaves exactly the bucket the exempt run never wrote, and an IP that is both exempt and blacklisted gets 403 (blacklist beats exemption). The scenario merged red against PyPI guard-core (< 4.1.0) by design, the documented lockstep hold; with this release it runs green against the published 4.1.0 engine in CI.
• Compatibility - The guard-core floor rises from >=4.0.0 to >=4.1.0 and this release tracks the guard-core 4.1.0 engine (the exempt_ips skip-list, the recon leading-separator gate, the raw-view recon scan, the cross-engine interop harness). Both fixed behaviors are adapter-side; no guard-core API fastapi-guard uses changed shape.

Changelog

Sourced from fastapi-guard's changelog.

v8.0.2 (2026-09-26)

Community fixes and exempt_ips lockstep: trailing-slash route config, block response Content-Type, live-smoke exempt_ips scenario; guard-core 4.1.0 tracking (v8.0.2)

• Fixed - Route decorator config now resolves through Starlette's trailing-slash redirect (#142): when the request path matches no route but toggling the trailing slash does, the middleware reads the config of the route Starlette would 307-redirect to, so a route override registered on /path now governs a request to /path/ (and vice versa) instead of silently falling through to the global defaults. Each router decides with its own redirect_slashes (mounted apps for their paths, the including app for an included router's routes), the root path and directly matched requests are untouched.
• Fixed - Block responses now declare Content-Type: text/plain (#144): the Starlette response factory left Starlette's media type unset, so middleware-generated 403/429/400 pages went out without a content type and clients were left guessing. The factory now passes media_type="text/plain", matching the engine's reference response factory.
• Tests - New live-smoke scenario tests/live_smoke/scenarios/exempt_ips.py (#145) covering the guard-core exempt_ips skip-list end to end through the live stack: an exempt IP exceeding rate_limit keeps getting 200 across the crossing while no rate-limit bucket is written for it at all (smoke:rate_limit:rate:<ip> stays absent in Redis, pinning that the exempt skip sits ahead of the limiter), a penetration-detection payload from the exempt IP still gets 400 (exemption is not immunity), the identical sequence without exempt_ips throttles at the crossing with 429 and leaves exactly the bucket the exempt run never wrote, and an IP that is both exempt and blacklisted gets 403 (blacklist beats exemption). The scenario merged red against PyPI guard-core (< 4.1.0) by design, the documented lockstep hold; with this release it runs green against the published 4.1.0 engine in CI.
• Compatibility - The guard-core floor rises from >=4.0.0 to >=4.1.0 and this release tracks the guard-core 4.1.0 engine (the exempt_ips skip-list, the recon leading-separator gate, the raw-view recon scan, the cross-engine interop harness). Both fixed behaviors are adapter-side; no guard-core API fastapi-guard uses changed shape.

v8.0.1 (2026-09-23)

CI hardening, live smoke suite, agent docs; guard-core 4.0.4 tracking (v8.0.1)

• CI - Added a DockSec container scan with SARIF upload to the pipeline (#138) and removed the Slack notification steps from all workflows.
• CI - New live smoke suite (tests/live_smoke/): a Docker Compose stack (nginx, gunicorn, Redis) running the full example app is exercised against PRs, and a nightly upstream drift gate builds the suite against guard-core master so engine-side regressions surface before a release instead of after (#134).
• Fixed (tests) - test_cloud_ip_blocking_with_logging (tests/test_middleware/test_security_middleware.py) now awaits the scheduled background cloud-IP refresh before asserting instead of relying on a stale Redis handler left behind by another test to suspend the dispatch (#136).
• Documentation - Added AGENTS.md/CLAUDE.md agent guidance and extended the fastapi-guard package skill.
• Compatibility - No production code changed: the delta since 8.0.0 is CI, tests and docs only, hence the patch bump. The guard-core>=4.0.0 floor is unchanged and this release tracks the guard-core 4.0.4 engine.

---

v8.0.0 (2026-09-04)

Lockstep with guard-core 4.0.0: log_activity assertions, timestamp serialisation, unban wiring, throttle docs, hsts None guard (v8.0.0)

• Compatibility (dependency floor, breaking for anyone pinned below 4.0.0) - guard-core floor moves from >=3.14.0 to >=4.0.0 in pyproject.toml, no upper bound. guard-core 4.0.0 carries breaking changes of its own (grammar-based secret redaction, require_headers() now enforces an exact value match for any configured value other than "required", excluded_detection_headers no longer fully silences a header) which do not require any change in this release's own code or tests, since fastapi-guard's require_headers() usage in its examples and tests only ever exercises the presence-only "required" value or sends a header value matching what is configured, and neither fastapi-guard's code nor its tests set excluded_detection_headers. See the guard-core 4.0.0 changelog for the full engine-side list.
• Requires (lockstep) - fastapi-guard 8.0.0 tracks guard-core 4.0.0. guard-core 4.0.0 is not yet published to PyPI as of this release commit; CI resolves guard-core>=4.0.0 fresh from PyPI (uv.lock is gitignored) and will fail until it is. This release is held locally, matching the pattern set by earlier lockstep releases, until guard-core 4.0.0 ships.
• Tests - test_cloud_ip_blocking_with_logging and test_passive_mode_penetration_detection (tests/test_middleware/test_security_middleware.py) pinned the full log_activity() call via assert_any_call, which broke against guard-core >=3.16.0's added on_block/sensitive_headers/sensitive_params/sensitive_body_fields keyword arguments. Both now check only the kwargs each test cares about as a subset of the actual call (assert_log_activity_called_with), tolerating any further keyword arguments guard-core adds.
• Fixed (examples) - http_exception_handler and general_exception_handler (examples/advanced_app/app/main.py) dumped ErrorResponse with model_dump(), leaving timestamp as a raw datetime that JSONResponse cannot encode, turning every error response (for example /behavior/return-monitor/404) into an unhandled 500. Both now use model_dump(mode="json").
• Fixed (examples) - /admin/unban-ip (examples/advanced_app/app/routes/admin.py) only logged the unban and never called guard-core's IP ban manager, so a banned IP stayed banned. The route now calls ip_ban_manager.unban_ip(ip).
• Documentation (examples) - action="throttle" only logs the violation; guard-core never blocks or delays the request for it. Corrected the /behavior/suspicious-frequency and /behavior/behavior-rules route descriptions and dropped the fabricated 429 response entries that promised otherwise, and corrected the matching lines in docs/tutorial/decorators/behavioral.md and docs/api/behavior-manager.md.
• Documentation (examples) - /behavior/usage-monitor's responses entry named a "block" action that does not exist in guard-core (the route uses action="log" and never returns 429); the entry is removed. alert was documented as sending a notification; it is a critical-level log call, same as any other action's telemetry event. Corrected in examples/advanced_app/app/routes/behavioral.py and docs/api/behavior-manager.md.
• Fixed - SecurityMiddleware._configure_security_headers (guard/middleware.py) called headers_config.get("hsts", {}).get("max_age"), which raised AttributeError on every request when security_headers={"hsts": None, ...} was passed explicitly, since .get("hsts", {}) returns None, not {}, for a key present with an explicit None value. Now falls back to {} the same way guard-core's own security_headers_handler treats a missing hsts block. guard-core 4.0.0 separately fixes the same class of bug on its own singleton (a stale hsts/csp/cors configuration surviving a reconfigure), so this guard is defense in depth against both the old and the fixed guard-core behavior.
• Security - guard_websocket and make_guard_websocket (guard/websocket.py) ran only the IP-ban and rate-limit checks on a WebSocket handshake; an attack riding in the handshake's headers, cookies, query string or path was never detected and never logged. The handshake is now scanned the same way an HTTP request is scanned, through guard-core's own SuspiciousActivityCheck, honouring enable_penetration_detection, passive_mode, exclude_paths and the whitelist and auto-ban rules already in place; a detected attack in active mode closes the connection before accept() with the new WS_CLOSE_SUSPICIOUS_ACTIVITY close reason (code 1008, collected in WS_CLOSE_REASONS), logs and emits the same event and on_block payload the HTTP pipeline emits, and redacts sensitive header, query and cookie values exactly as the HTTP pipeline does; passive mode logs and emits without closing the connection.

---

v7.8.2 (2026-08-27)

Route-relative path resolution under root_path and mounts, Starlette and FastAPI floors (v7.8.2)

• Fixed - StarletteGuardRequest.url_path and the WebSocket adapter's _WebSocketGuardRequest.url_path returned request.url.path / websocket.url.path, which under an ASGI root_path (uvicorn --root-path, or a mounted sub-app) includes the mount prefix. guard-core matches that value against SecurityConfig.exclude_paths and endpoint_rate_limits (an exact dict-key match) and passes it to custom_request_check hooks, so a key such as /api/vault/login never matched a request actually served at /mounted/api/vault/login and every path-keyed control silently stopped applying under a mount. Both adapters now return Starlette's own get_route_path(scope), the same route-relative path Starlette's router already matches routes against.

... (truncated)

Commits

• d520c94 Merge pull request #146 from rennf93/release/8.0.2
• 1494368 release(8.0.2): community fixes (#142, #144), exempt_ips live smoke; guard-co...
• 8a9ce52 Merge pull request #145 from rennf93/feat/exempt-ips-live-smoke
• 1c05fa7 test(live-smoke): cover the exempt_ips skip-list end to end ahead of the guar...
• 4beb62e Merge pull request #144 from HardMax71/fix/block-response-content-type
• ca340d2 Merge pull request #142 from HardMax71/fix/trailing-slash-route-config
• 389c9c3 fix(middleware): read redirect_slashes from the mounted app behind mount midd...
• 4059fbe fix(adapters): block responses are text/plain
• e10c423 Merge branch 'master' into fix/trailing-slash-route-config
• c3a46ed test(live-smoke): cover detection_binary_min_run_length
• Additional commits viewable in compare view

Updates guard-core to 4.3.1

Release notes

Sourced from guard-core's releases.

v4.3.1 (2026-10-06)

The route-id ownership release: factory-built endpoints get their own route ids and behavioral counters, and the cost-parity corpus joins the CI-enforced parity contract (v4.3.1)

Fixed

• Endpoints built by one decorator factory share one RouteConfig, last one wins (guard-core #140, #141, @​HardMax71). The route id was module.qualname, so endpoints built by one decorator factory shared a single RouteConfig and the last decorator call silently won. _get_route_id now reuses a function's _guard_route_id when present, otherwise dedups with [#2](https://github.com/Guard-Core/guard-core/issues/2), [#3](https://github.com/Guard-Core/guard-core/issues/3) and so on, and _ensure_route_config stamps the id on the function right away so the next decorator in a stack finds it. functools.wraps wrappers join the config of the function they wrap.
• Route-id ownership validation (guard-core #142). A stamped _guard_route_id is honored only within the decorator instance that bound it, or for wrappers of the same route via the __wrapped__ chain - a colliding id stamped by a different decorator instance on a same-qualname sibling can no longer select that sibling's config.
• Behavioral counters are per-function for factory-built endpoints (guard-core #142). BehavioralProcessor.get_endpoint_id now prefers state.guard_route_id over the legacy module.qualname guard_endpoint_id, so the usage/return counters and pattern state stop mixing across same-qualname siblings on all four adapters (the adapters already stamp guard_route_id; no adapter changes needed). Decorated endpoints' hashed Redis counter keys change shape, so pre-existing counters age out through their TTLs.

Added

• The cost-parity corpus: the 9-case cost_bodies suite with self-relative scan-cost ceilings - large-body verdict parity across the truncation cap plus self-relative scan-cost ceilings, CI-enforced on every engine. The family's verdict-and-cost parity contract is now machine-checked on every push (guard-core #142, and the engine/lane PRs in the four sibling repos).

Test

• The lazy-init timing assertion carries load headroom (a saturated runner measured 0.538s against the old 0.5s bound; rerun green), and run_fixtures.py no longer drops pattern_safety suites into the detect checker.

Changelog

Sourced from guard-core's changelog.

v4.3.1 (2026-10-06)

The route-id ownership release: factory-built endpoints get their own route ids and behavioral counters, and the cost-parity corpus joins the CI-enforced parity contract (v4.3.1)

Fixed

• Endpoints built by one decorator factory share one RouteConfig, last one wins (guard-core #140, #141, @​HardMax71). The route id was module.qualname, so endpoints built by one decorator factory shared a single RouteConfig and the last decorator call silently won. _get_route_id now reuses a function's _guard_route_id when present, otherwise dedups with [#2](https://github.com/Guard-Core/guard-core/issues/2), [#3](https://github.com/Guard-Core/guard-core/issues/3) and so on, and _ensure_route_config stamps the id on the function right away so the next decorator in a stack finds it. functools.wraps wrappers join the config of the function they wrap.
• Route-id ownership validation (guard-core #142). A stamped _guard_route_id is honored only within the decorator instance that bound it, or for wrappers of the same route via the __wrapped__ chain - a colliding id stamped by a different decorator instance on a same-qualname sibling can no longer select that sibling's config.
• Behavioral counters are per-function for factory-built endpoints (guard-core #142). BehavioralProcessor.get_endpoint_id now prefers state.guard_route_id over the legacy module.qualname guard_endpoint_id, so the usage/return counters and pattern state stop mixing across same-qualname siblings on all four adapters (the adapters already stamp guard_route_id; no adapter changes needed). Decorated endpoints' hashed Redis counter keys change shape, so pre-existing counters age out through their TTLs.

Added

• The cost-parity corpus: the 9-case cost_bodies suite with self-relative scan-cost ceilings - large-body verdict parity across the truncation cap plus self-relative scan-cost ceilings, CI-enforced on every engine. The family's verdict-and-cost parity contract is now machine-checked on every push (guard-core #142, and the engine/lane PRs in the four sibling repos).

Test

• The lazy-init timing assertion carries load headroom (a saturated runner measured 0.538s against the old 0.5s bound; rerun green), and run_fixtures.py no longer drops pattern_safety suites into the detect checker.

v4.3.0 (2026-10-01)

The safety-corpus release: the pattern-safety chain, the event stream and the Redis interop surface are pinned by the corpus, and boot validation can be cached (v4.3.0)

Added

• The corpus is now the full safety-and-surface parity suite: 327 cases across 20 suites (guard-core #132, #134). specs/fixtures/cases/ grows from 219 cases in 17 suites to 327 cases in 20 with three new kinds, every expected value produced by executing the reference engine and kept only when decisive and stable across repeated oracle runs. safety_gates.json (kind pattern_safety, 94 cases, #132) pins PatternCompiler.validate_pattern_safety across nine decision classes in both modes: the three dangerous backtracking constructs, compile failures, all five structural detectors (nested unbounded, adjacent broad, unreachable terminator, literal absorb, ambiguous optional tail), pure over-budget extrapolation, and the safe verdict; cases pin safe plus a stable reason_class token and never the host-measured numeric reason text, and the probe-timeout class is excluded by design because it is host-speed dependent. event_stream.json (kind events, 39 cases, #134) pins all 39 event types' full envelopes through a capturing agent handler with the volatile fields (idempotency_key, timestamp, response/execution timings) dropped recursively per the index comparison contract, plus one honest xfail (decoding_error guards stdlib decoders that never raise on str). redis_interop.json (kind redis_interop, 14 cases, #134) pins the byte-level Redis surface of section 08 per key family: exact keys with the sha256 composition, exact static values, zset member/score shapes, canonicalized JSON blobs, and TTL presence plus value. specs/fixtures/tools/generate_safety_gates.py ships the bounded generator (harvested pool via the fast test-strings mode, curated per-class triggers via both modes, eight workers, a 90 second per-call alarm) alongside the existing pipeline generator; both new generators replay byte-identical.
• detection_pattern_validation_cache_path: an opt-in disk cache for the pattern-validation cost verdict (guard-core #135, #136). When set, PatternValidationCache persists validate_pattern_safety's empirical cost-verdict outcome (probe synthesis plus timed subprocess probes) keyed by pattern, flags, and engine version, so a process boot reuses prior certifications instead of re-timing every custom pattern; the cheap deterministic layers (dangerous constructs, compile check, structural detectors) always re-run, explicit test_strings validation bypasses the cache, entries produced by a different engine version are ignored and overwritten, writes are atomic (tempfile plus os.replace), and a corrupt or unreadable cache starts empty with a warning instead of failing the boot. Wired through PatternCompiler(validation_cache=...), the suspatterns detection state builder and the dynamic-rule application paths. Left unset (the default) every validation stays fully empirical. The motivating incident: on a host with degraded subprocess spawn latency, startup validation of ~100 patterns turned into minutes of killable-subprocess timeouts and wholesale fail-closed rejection.

Fixed

• The corpus tool harnesses pass full-workspace mypy (guard-core #137). The events and redis-interop generators' duck-typed doubles (GuardRequest-shaped pipeline stubs, monkeypatched handler attributes, the aiohttp ClientSession replacement, lambdas assigned onto manager seams) carry the narrow ignore codes mypy requests, and the hex-escape attack-indicator regex parity was re-verified against the reference's two-character escaped-backslash form.
• specs/ tooling is ruff-format stable under the pinned hook versions (guard-core #138): the safety-gates generator's 10 line-normalization diffs are landed so pre-commit's ruff-format hook stops failing every open PR.

---

v4.2.0 (2026-09-27)

The parity release: the conformance corpus tracks the engine release (v4.2.0)

Added

• The conformance corpus is the 4.2.0 parity surface (guard-core #124, #125). specs/fixtures/ now carries the full corpus inside the reference repo: 219 cases across 17 suites at spec 4.1.0. The 12 detect suites (184 cases) regenerate byte-identical against the vendored expectations (zero detect drift) and five new kind=pipeline suites (35 cases) pin the pipeline-level parity surface through the real SecurityCheckPipeline over a redis-free middleware stub: ip control (whitelist/blacklist/exempt_ips precedence, blacklist beats exemption, geo country block and allowlist, route ip/UA restrictions), rate limits (global 429 with Retry-After, endpoint tier independence, route tiers, exempt skip, passive mode), detection response (the 400 contract body, custom error responses, logged_only events, on_block payloads, route detection exclusions), headers and CORS (default/custom/disabled security headers on error responses, origin echo, wildcard plus credentials block) and behavioral rules (global return_pattern rules driving the in-memory behavior ban with passive-mode suppression). run_fixtures.py replays both suite kinds and the generator records kind and consumers per suite so the rust detect-only runner and the go/php/ts pipeline runners load the right files; the corpus engine_version stamp now tracks this release, so 219 cases match engine 4.2.0 is a truthful statement about the shipping engine.

---

... (truncated)

Commits

• f2dd787 release(4.3.1): route-id ownership, per-route behavioral counters, cost-parit...
• de4a687 test(handler-init): give the lazy-init timing assertion load headroom (#143)
• 6549d86 fix(decorators): route-id ownership validation and per-route behavioral count...
• 61167a9 fix(decorators): give each decorated function its own route id (#141)
• eff6c6f docs: correct engine stats in How Detection Works (16 decode iterations, 157 ...
• 5e74884 docs(changelog): restore the v4.2.0 section header consumed by the v4.3.0 insert
• 02c3d44 release(4.3.0): the safety-corpus release (#139)
• 5ba7405 feat(detection): opt-in disk cache for the pattern-validation cost verdict (#...
• e964a62 style(specs): ruff-format the safety gates generator (#138)
• 91c81fd fix(specs): repair mypy errors in the corpus tool harnesses (#137)
• Additional commits viewable in compare view

[github-actions]

Thanks for opening your first pull request on RoboCo!

Quick checklist before review (most of these are enforced by CI, but worth a glance):

• make quality — ruff format check, ruff check, mypy, pytest (≥80% coverage), and the rest of the gate
• Panel changes pass pnpm lint and pnpm exec tsc --noEmit (run from panel/)
• No # noqa / # type: ignore shortcuts; pre-existing violations in touched files are fixed
• Added an entry under ## [Unreleased] in CHANGELOG.md
• Signed the CLA (the bot will prompt you on this PR)
• Signed your commits — master requires verified signatures (SSH signing setup)
• Updated any affected docs under docs/

See CONTRIBUTING.md for the full workflow and the Code of Conduct for the community standards we follow.

Welcome aboard — a maintainer will review shortly.

[rennf93]

@dependabot rebase

[rennf93]

@dependabot update

[dependabot]

Looks like this PR is already up-to-date with master! If you'd still like to recreate it from scratch, overwriting any edits, you can request @dependabot recreate.

[rennf93]

@dependabot recreate. fastapi-guard is at 8.1.0

[rennf93]

Summary

External PR #1129 bumps two security-critical dependencies in pyproject.toml: fastapi-guard 8.0.0→8.0.2 (patch) and guard-core[redis] 4.0.3→4.3.1 (minor +3 versions). The guard-core minor bump of +3 versions with no corresponding code changes to adapt to potential API changes is a supply-chain/compatibility risk for a security-critical library. The PR also introduces a typo in the guard-core comment ('dector' vs 'decorator'). The CEO directive 'security lib: floor tracks latest' does not mean blind version bumps without compatibility verification.

Findings

File	Line	Severity	Expected → Actual
pyproject.toml (supply-chain/compatibility)	1	blocker	guard-core[redis] version bump verified compatible with existing code or accompanied by code changes adapting to API changes → guard-core[redis] bumped from 4.0.3 to 4.3.1 (minor +3 versions) with no code changes to adapt to potential API changes
pyproject.toml (code-quality)	1	minor	Comment spelling correct: 'decorator' → Comment reads 'SecurityConfig/dector models + protocols' (typo: 'dector' instead of 'decorator')
pyproject.toml (supply-chain)	1	minor	fastapi-guard patch bump 8.0.0→8.0.2 verified compatible → fastapi-guard bumped from 8.0.0 to 8.0.2 with no compatibility verification noted

Verdict

changes requested