--- name: sidecar-auth-context description: "Working on resolver plugins, the fixed access plugin contract, mapping resolver outputs into ExecutionContext, or protected-node filtering. Primary task is tasks/0006-sidecar-auth-context.md." generated: true source: .ai/skills/sidecar-auth-context.md --- # Skill: Plugin Context & Access ## When to use this skill Use this when working on resolver plugins, the fixed access plugin contract, mapping resolver outputs into `ExecutionContext`, or protected-node filtering. Primary task: `tasks/0006-sidecar-auth-context.md`. ## Files to read first - `AGENTS.md` - `docs/SIDECAR_CONTEXT_AUTH.md` - `docs/ARCHITECTURE.md` - `docs/PROMPT_RENDERING.md` ## Architecture rules - The runtime contains no customer-specific auth/business logic. - Resolver plugins fill prompt variables before a node runs. - Tool plugins are separate and run during LLM execution. - Protected nodes are hidden from routers unless the access plugin allows them. - Access failures fail closed. - Secrets are redacted in traces. ## Implementation rules - Implement plugin integration in `src/agentplatform/context`. - Build `ctx` from request headers and request data. - Call resolver plugin methods declared in top-level `resolvers`. - If any node has `protected: true`, require `plugins/access.py` with `AccessResolver.can_access(ctx, node_id) -> bool`. - Keep plugin instances shared where appropriate; keep request data on `ExecutionContext`. ## Validation checklist - [ ] No customer-specific logic in the runtime. - [ ] Resolver outputs are request-scoped. - [ ] Protected nodes are filtered before routing. - [ ] Deny/error cases fail closed and are traced. - [ ] Secrets redacted in traces. - [ ] Tests use fake plugins covering allow/deny/error. - [ ] `make check` passes. ## Common mistakes to avoid - Implementing auth/tenant/business rules inside the engine. - Failing open when access plugin raises. - Exposing resolver plugins to the LLM as tools. - Logging raw tokens/secrets in the trace.