{"id":25465,"date":"2026-05-29T08:36:26","date_gmt":"2026-05-29T06:36:26","guid":{"rendered":"https:\/\/whiteduck.de\/?p=25465"},"modified":"2026-05-29T08:36:27","modified_gmt":"2026-05-29T06:36:27","slug":"flock-v0-5-500-enterprise-security-for-agentic-ai","status":"publish","type":"post","link":"https:\/\/whiteduck.de\/en\/flock-v0-5-500-enterprise-security-for-agentic-ai\/","title":{"rendered":"Flock v0.5.500: Enterprise Security for Agentic AI"},"content":{"rendered":"

<\/div>
<\/div>
<\/div><\/div><\/div>

<\/p>\n

Flock v0.5.500: Enterprise Security for Agentic AI<\/p>\n

<\/h1><\/div>

<\/div><\/p>\n\n\n

AI agents are moving into production. And with that move comes a set of questions that no one asks during a prototype: How do we authenticate without hardcoding API keys? How do we prevent prompt injection from compromising agent behavior? How do we make security a first-class concern, not an afterthought?<\/p>\n\n\n\n

Flock 0.5.500 answers all three. This release introduces two foundational security features that make it significantly easier to build and operate AI agents in enterprise environments: keyless authentication via Azure Entra ID and Managed Identity, and a pluggable guard framework to protect agents from malicious inputs.<\/p>\n\n\n\n

Keyless Authentication with Azure Entra ID and Managed Identity<\/h3>\n\n\n\n

The Problem with API Keys<\/h4>\n\n\n\n

Most LLM frameworks require an API key to talk to Azure OpenAI. That key ends up in environment variables, CI\/CD pipelines, container specs, and developer machines. It needs to be rotated, audited, and kept out of source control. In practice, that rarely happens.<\/p>\n\n\n\n

In Azure-native workloads, there is a better way: Managed Identity<\/a>. A workload running on Azure Container Apps, AKS, or Azure Functions can authenticate to Azure OpenAI directly, with no secrets involved. Azure handles the credential lifecycle. You handle the business logic.<\/p>\n\n\n\n

Flock 0.5.500 makes this the default path for Azure deployments. Authentication works across Azure OpenAI and Azure AI Foundry.<\/p>\n\n\n\n

How It Works<\/h4>\n\n\n\n

A new lm_kwargs<\/code> field on DSPyEngine<\/code> forwards arbitrary keyword arguments to the underlying LiteLLM<\/a> constructor. This is a provider-agnostic mechanism: any LiteLLM parameter can be passed through. For Azure, a dedicated helper wraps DefaultAzureCredential<\/code><\/a> into a token provider callable that LiteLLM understands.<\/p>\n\n\n\n

The result is clean, keyless configuration:<\/p>\n\n\n\n

from flock.engines import DSPyEngine\nfrom flock.engines.auth.azure import get_default_azure_token_provider\n\ntoken_provider = get_default_azure_token_provider()\n\nengine = DSPyEngine(lm_kwargs={\n    \"api_base\": \"https:\/\/<resource>.openai.azure.com\/\",\n    \"api_version\": \"2024-12-01-preview\",\n    \"azure_ad_token_provider\": token_provider,\n})<\/code><\/pre>\n\n\n\n
DefaultAzureCredential<\/code> resolves the right credential automatically: Managed Identity when running on Azure, az login<\/code> during local development. No code change required between environments.<\/p>\n\n\n\n
For workloads using a user-assigned Managed Identity, pass the client ID:<\/p>\n\n\n\n
token_provider = get_default_azure_token_provider(\n    managed_identity_client_id=\"<client-id>\"\n)<\/code><\/pre>\n\n\n\n
The Azure AI Foundry Agents API requires a different token scope. That is covered too:<\/p>\n\n\n\n
from flock.engines.auth.azure import (\n    get_default_azure_token_provider,\n    AZURE_AI_FOUNDRY_SCOPE,\n)\n\ntoken_provider = get_default_azure_token_provider(scopes=AZURE_AI_FOUNDRY_SCOPE)<\/code><\/pre>\n\n\n\n
Getting Started<\/h4>\n\n\n\n
The Azure identity support ships as an optional dependency to keep the core package lean. It pulls in azure-identity<\/code><\/a>, Microsoft’s official Python credential library:<\/p>\n\n\n\n
uv add \"flock[azure]\"<\/code><\/pre>\n\n\n\n
That’s it. No secrets. No rotation. No exposure.<\/p>\n\n\n\n
GuardComponent: Pluggable Input and Output Protection<\/h3>\n\n\n\n
The Prompt Injection Problem<\/h4>\n\n\n\n
Agentic systems are different from chatbots. They process external data (documents, web content, API responses, user inputs) and act on it. That external data is an attack surface. A malicious PDF can contain instructions that redirect agent behavior. A crafted user message can attempt to jailbreak the underlying model. Prompt injection<\/a> consistently ranks as one of the top risks in production LLM applications.<\/p>\n\n\n\n
Without explicit protection, there is no reliable way to detect these attacks before they influence what an agent does.<\/p>\n\n\n\n
Flock 0.5.500 introduces a guard framework that makes protection composable and configurable, not bolted on as an afterthought.<\/p>\n\n\n\n
How It Works<\/h4>\n\n\n\n
GuardComponent<\/code> is an abstract base class that integrates into Flock’s existing agent lifecycle. Guards execute during on_pre_evaluate<\/code> (before the model sees the input) and on_post_evaluate<\/code> (after the model produces output). No new architectural patterns are needed: guards are just components with a well-defined interface.<\/p>\n\n\n\n
Each guard returns a GuardVerdict<\/code> with four fields: safe<\/code>, reason<\/code>, details<\/code>, and provider<\/code>. This gives full auditability: every decision is traceable.<\/p>\n\n\n\n
Three actions can be configured per phase:<\/p>\n\n\n\n