Proposal: Runtime Verification Filter for Plugin Function Execution

[Correctover]

Summary

We'd like to propose integrating CCS runtime verification as a kernel-level filter in Semantic Kernel's plugin execution pipeline, and invite maintainers to evaluate feasibility.

What CCS Does

CCS intercepts and verifies every function/plugin call before execution:

• RCE detection — blocks shell injection, command chaining
• SSRF protection — validates outbound URLs against allowlists
• Credential hijack prevention — detects token/secret exfiltration
• Overhead: ~22μs per check (P50), deterministic

Integration Point

SK's FunctionInvocationFilter pattern is the ideal integration point:

# Proposed usage:
kernel = Kernel()
kernel.add_function_invocation_filter(CCSVerificationFilter())

This follows SK's existing filter architecture — no new concepts, just a new filter implementation.

How It Complements SK's Existing Architecture

Component	Scope
SK Filters (existing)	Logging, telemetry, retry, error handling
CCS Filter (proposed)	Pre-execution security verification

They're complementary — CCS adds a security dimension to the existing filter pipeline.

Background

• Published research: DOI: 10.5281/zenodo.17164296
• Active in Microsoft agent ecosystem governance (autogen .Net: Migrate remaining samples to new {Azure}OpenAI services #7353+, semantic-kernel MCP Reliability Enhancement Proposal #14152)
• 87+ CVEs/ZDI submissions across AI agent frameworks

Ask

1. Is there appetite for a security verification filter in SK?
2. Does the FunctionInvocationFilter pattern work, or is there a better integration point?
3. Any concerns about performance or compatibility?

Happy to provide a PoC filter implementation.

— Correctover team | correctover.com | Correctover = AI Reliability™

[Correctover]

For context, the CCS runtime verification layer is live and publicly instrumented at https://ops.correctover.com — out-of-process verification at ~10μs P50 with fail-closed defaults, real-time telemetry, and argument-bound action receipts.

PR #14199 from @Palo-Alto-AI-Research-Lab represents the community's first concrete in-process implementation. The architectural tradeoff (in-process convenience vs. out-of-process isolation) is worth discussing openly — both approaches have merit for different deployment scenarios.