Policy-first capability filtering before agent execution

[SAURAV SINGLA (sauravsingla)]

I’m exploring a production-oriented pattern for large agent/tool catalogs:

catalog
→ authorization / policy scope
→ optional task-aware routing
→ selected capabilities
→ normal agent execution

The key principle is that dynamic routing should not be mandatory.

If identity, role, tenant, permissions, or policy already reduce the catalog sufficiently, deterministic filtering should be preferred.

Only when the remaining action space is still large or heterogeneous should task-aware routing be added.

I’ve implemented this experimentally in AgentWeave with explicit routing provenance and runtime recovery.

I’d value feedback from Semantic Kernel users on where this responsibility should live:

planner, middleware, orchestration layer, or application code?

Repo: https://github.com/sauravsingla/agentweave

[René Zander (renezander030)]

Every stage in that chain narrows what can be invoked, and the provenance you record is of the selection rather than of what the selection then did.

The case that decides the layer is the one after execution: a permitted capability ran and wrote the wrong thing, and reversing it needs the tenant and policy scope that middleware still holds and application code has already dropped.

Where does the reversal live in AgentWeave today, given routing provenance stops at the selection?

[Ama Senevirathne (amasen02)]

In Semantic Kernel (.NET and Python), spreading capability filtering across ad-hoc application code quickly creates security leaks and token bloat. The cleanest architectural split aligns with how SK structures its execution pipeline:

1. Hard Scope / RBAC at the DI & Kernel Boundary (Orchestration Layer)

Deterministic filtering (tenant isolation, user identity, IAM roles, license tiers) should happen before tools ever touch the KernelPluginCollection.
If a user or tenant cannot invoke an administrative or privileged function, that function must not be registered into the Kernel or included in the function choice behavior.

Why this must never be deferred to prompts or middleware:

• Token cost & Context Pollution: Exposing 50+ tool schemas to the model burns prompt tokens on every turn and dilutes tool-selection accuracy.
• Security & Prompt Injection: If a function declaration is visible in the system prompt, prompt injection attacks can attempt to hallucinate parameters or bypass application checks.

In .NET SK, we handle this by creating scoped Kernels per request or filtering plugins during service resolution:

// Only register plugins permitted for the active tenant/role
var kernel = new Kernel(serviceProvider);
var allowedPlugins = pluginCatalogService.GetAuthorizedPlugins(userContext);
foreach (var plugin in allowedPlugins)
{
    kernel.Plugins.Add(plugin);
}

2. Runtime Invocations & Safeguards (Middleware Layer: IFunctionInvocationFilter / IAutoFunctionInvocationFilter)

Middleware is the right home for runtime context checks that depend on parameters, dynamic quotas, or approvals:

• Verifying parameter boundaries (e.g. ensuring a transfer_amount doesn't exceed the user's per-transaction limit).
• Rate-limiting tool calls per session or tenant.
• Audit logging & telemetry provenance.
• Human-in-the-loop (HITL) approval gates before mutating external state.

SK's IAutoFunctionInvocationFilter lets you inspect context.Function, context.Arguments, and even short-circuit execution:

public sealed class PolicyEnforcementFilter : IAutoFunctionInvocationFilter
{
    public async Task OnAutoFunctionInvocationAsync(AutoFunctionInvocationContext context, Func<AutoFunctionInvocationContext, Task> next)
    {
        // Enforce runtime policy
        if (!PolicyEngine.IsExecutionAllowed(context.Function, context.Arguments))
        {
            context.Result = new FunctionResult(context.Function, "PolicyViolation: Tool invocation blocked by policy engine.");
            context.Terminate = true; // Halts further automatic tool calls
            return;
        }

        await next(context);
    }
}

3. Dynamic Task-Aware Routing (Planner / Function Choice Layer)

Once deterministic RBAC has narrowed the catalog to the authorized subset, if you still have a wide variety of domain tools (e.g., 20+ specialized plugins), task-aware routing belongs in the FunctionChoiceBehavior / Planner:

• Use vector embedding or semantic router over plugin descriptions to dynamically select the top-$k$ candidate functions relevant to the current user intent.
• Pass only those top-$k$ functions via FunctionChoiceBehavior.Auto(functions: topKFunctions).

4. What about Compensation & Reversals?

To René Zander (@renezander030)'s point on reversals: compensation should never live in application prompt code or ephemeral LLM state.
In production systems, whenever a state-mutating tool runs, the IFunctionInvocationFilter should emit a durable Execution Receipt (containing the CorrelationId, Timestamp, ToolName, InputArguments, and an UndoPayload or saga compensator). If subsequent steps fail or policy triggers a rollback, a dedicated Saga Orchestrator executes the compensating transactions using the durable ledger.

Keeping deterministic authorization at Kernel creation, runtime validation in SK filters, and dynamic narrowing in FunctionChoiceBehavior gives you rock-solid security without sacrificing agent flexibility.