mirror of
https://github.com/netbirdio/netbird.git
synced 2026-07-28 00:32:36 -04:00
bab5572a74
## Describe your changes The model-allowlist guardrail was merged into one account-wide union and enforced flat on every request, ignoring which policy/group/provider authorised it. With multiple policies — especially a mix of guardrailed and un-guardrailed ones — this caused: - **false-allow**: a model allowlisted for one group/provider leaked to any caller; and - **false-deny**: an un-guardrailed policy (intended unrestricted) was blocked by another policy's allowlist. Enforcement is now policy/group-aware, mirroring `llm_limit_check`: - **Management (`SelectPolicyForRequest`) is authoritative.** It uses the request model (already carried in `CheckLLMPolicyLimitsRequest.model`, previously ignored) to keep only applicable policies whose guardrails permit the model; no allowlist-enabled guardrail = unrestricted. Denies `llm_policy.model_blocked` when policies govern the (provider, groups) but none permits the model. - **Proxy `llm_guardrail` becomes a per-provider fail-closed backstop.** The synthesiser emits an allowlist only for providers every authorising policy restricts; the middleware keys off the resolved provider id and keeps unknown-model fail-closed.
Agent Networks — architecture documentation
A self-contained set of documents describing the agent-networks feature: an LLM-aware reverse-proxy middleware system plus account-level controls (budget rules, log collection toggles, PII redaction). The management server synthesises a per-peer middleware chain that the proxy executes on every LLM request.
What to read first
- 00-overview.md — the single entry point. Feature scope, the module map, and the cross-cutting topics worth keeping in mind, with links to every per-module guide.
- 01-end-to-end-flows.md — three high-level mermaid diagrams: config-to-runtime synth/delivery, per-request lifecycle through the LLM chain, and the budget-rule feedback loop.
- Per-module guides under
modules/— one file per package. Each describes the module boundary, the file-level layout, its own flow diagrams, the public contracts, the invariants it relies on, and the areas worth the closest attention.
Directory layout
docs/agent-networks/
├── README.md # you are here
├── 00-overview.md # feature summary + module map
├── 01-end-to-end-flows.md # cross-module mermaid diagrams
└── modules/
├── 10-shared-api.md # proto + OpenAPI wire contracts
├── 20-management-store.md # SQL persistence layer
├── 21-management-agentnetwork.md # domain layer + synthesizer (largest)
├── 22-management-handlers-wiring.md # HTTP API + gRPC delivery
├── 30-proxy-middleware-framework.md # generic plugin system
├── 31-proxy-middleware-builtin.md # 8 LLM-aware middlewares
├── 32-proxy-llm-parsers.md # OpenAI/Anthropic/Bedrock SDKs + pricing
├── 33-proxy-runtime.md # translate + serve + access-log
├── 40-dashboard.md # UI for everything above (lives in the dashboard repo)
└── 50-path-routed-providers.md # Vertex AI + Bedrock (path-routed, keyfile:: creds, /bedrock prefix)
The 40-dashboard.md module documents code that lives in the dashboard
repo, not in this repo. The guide is co-located here so backend readers
see the full picture in one place.
How the per-module guides are structured
Every modules/*.md follows the same template so the docs are easy to
scan:
- Module boundary — what this package owns; where it sits in the stack.
- Files — path / role.
- Architecture & flow — one or more mermaid diagrams.
- Public contracts — function signatures, gRPC messages, JSON shapes.
- Invariants — semantic guarantees the module relies on or enforces.
- Things to scrutinize — split by correctness / security / concurrency / backward-compat / performance / observability.
- Test coverage — the test files that lock down behaviour in this module.
- Known limitations / non-goals — what is intentionally out of scope.
- Cross-references — upstream/downstream module links + the end-to-end flow + the overview.
See 00-overview.md for the module map and the cross-cutting topics.