Semantic Kernel Security Patterns: Governing What Your Kernel Sends to the Model

A Semantic Kernel application is orchestration code that runs in your process. You register plugins as functions, wire up a planner that decides which functions to call, attach memory, and build a kernel that ties them together. When a step needs the model, the kernel hands the assembled prompt to an AI service connector, and that connector makes an HTTP call to an LLM endpoint on Azure OpenAI, OpenAI, or another provider. The Microsoft Learn documentation describes the connector as the component that talks to the model service.

That connector call is where network security patterns for Semantic Kernel attach. The planning, the function invocation, the memory reads, and the plugin logic all run inside your runtime, and securing them is an application-security job. The traffic that leaves your environment is the connector's HTTP request to the model, and that is the part a gateway governs.

Separate the in-process kernel from the model call

Before writing controls, draw the line, because the kernel does a great deal that never touches the network.

Inside a gateway's boundary:

• The connector's HTTP call to the LLM endpoint, carrying the prompt the kernel assembled.
• A plugin that reaches an external API over HTTP, when that traffic is routed through the gateway.

Outside it:

• The planner's decision about which functions to run. That logic executes in-process.
• A native function that runs code on the host. Local execution never reaches a network gateway.
• Memory reads and writes to a local store.

A gateway governs the connector traffic and any HTTP plugin traffic routed through it. It does not sandbox a native function that runs arbitrary code, and it does not arbitrate the planner. Keep the gateway focused on what crosses the network to a model, and treat the local plugin surface as a separate control problem.

Bind the connector to a per-identity credential

The common Semantic Kernel pattern gives the kernel one API key for its connector. Every function call that reaches the model authenticates as that single credential, so an audit of model traffic cannot distinguish a low-risk summarization function from a function that assembled a prompt full of customer records.

Point the connector at the gateway and give it an identity the gateway can bind to:

The gateway verifies the token, evaluates policy against that identity, and holds the real provider key so the kernel cannot address the model directly. The audit trail now names the orchestrator identity behind each call. This is the same agent identity discipline that per-agent frameworks need.

Classify the prompt the kernel assembles, not the template you reviewed

A Semantic Kernel prompt is built at runtime from a function template, the arguments passed in, memory recalled from a store, and the output of a prior function in the plan. The developer reviewed the template once. The content that actually leaves for the model is composed on each run, and a recalled memory or an upstream function result can carry data the kernel should not be sending. The gateway classifies the real outbound prompt against regulated data types and applies policy on the data class, which is the control that survives a planner assembling context nobody wrote by hand. The reasoning mirrors LangChain security patterns: inspect the request, do not trust the design.

Constrain egress so a connector cannot bypass the gateway

A per-identity connector credential is meaningless if the process can still open a direct connection to the provider. Restrict egress from the application tier so the only route to any model endpoint runs through the gateway:

With egress locked, a misconfigured connector or an injected instruction that tries to reach the provider directly fails at the network, and the gateway stays the single path every model call travels. Combined with the identity binding above, this is what makes per-identity policy enforceable rather than advisory.

Record what the kernel asked the model

Every connector call produces a decision record: the kernel identity, the data class in the assembled prompt, the pass-or-block outcome, and the policy version. When a planner chains several functions and each makes its own model call, that sequence of records is what lets a later review reconstruct which step sent which class of data to the model. Each record commits before the response returns, on a write path the application never controls, which is what separates it from a log the same process could edit or lose.

DeepInspect

This is exactly what DeepInspect does. A Semantic Kernel connector makes model calls over HTTP, and DeepInspect sits at that boundary between your kernel and the LLM endpoints it calls.

For every connector request, DeepInspect binds the call to the identity the application supplies, classifies the prompt the kernel assembled against regulated data types, applies the per-identity and per-route policy, and makes a deterministic, fail-closed decision before the request reaches the model. Every decision commits a signed, identity-bound audit record before the response returns, on a write path the kernel never controls. DeepInspect governs the connector traffic and any HTTP plugin traffic routed through it, and it does not claim to sandbox the native functions a kernel runs, which stay an application-security problem. If you are running Semantic Kernel on a shared connector key and cannot say which function sent what to the model, book a demo today.