sidecar-auth-context

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.