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
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
Most LLM frameworks require an API key to communicate with Azure OpenAI. That key ends up in environment variables, CI\/CD pipelines, container specs, and developers\u2019 machines. It needs to be rotated, audited, and kept out of source control. In practice, that rarely happens. <\/p>\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 Flock 0.5.500 makes this the default path for Azure deployments. Authentication works across Azure OpenAI and Azure AI Foundry. <\/p>\n A new The result is clean, keyless configuration:<\/p>\n For workloads using a user-assigned Managed Identity, pass the client ID:<\/p>\n The Azure AI Foundry Agents API requires a different token scope. That is covered as well: <\/p>\n Azure identity support ships as an optional dependency to keep the core package lean. It pulls in That\u2019s it. No secrets. No rotation. No exposure. <\/p>\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 Without explicit protection, there is no reliable way to detect these attacks before they influence what an agent does.<\/p>\n Flock 0.5.500 introduces a guard framework that makes protection composable and configurable, rather than bolted on as an afterthought.<\/p>\n Each guard returns a Three actions can be configured per phase:<\/p>\n Guards compose naturally. Assign priorities to control execution order. A block in any guard stops subsequent components and the engine run. <\/p>\nHow It Works<\/h3>\n
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>\nfrom 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:\/\/DefaultAzureCredential<\/code> resolves the correct credential automatically: Managed Identity when running on Azure, az login<\/code> during local development. No code changes are required between environments. <\/p>\ntoken_provider = get_default_azure_token_provider(\n managed_identity_client_id=\"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>\nGetting Started<\/h3>\n
azure-identity<\/code><\/a>, Microsoft\u2019s official Python credential library:<\/p>\nuv add \"flock[azure]\"<\/code><\/pre>\nGuardComponent: Pluggable Input and Output Protection<\/h2>\n
The Prompt Injection Problem<\/h3>\n
How It Works<\/h3>\n
GuardComponent<\/code> is an abstract base class that integrates into Flock\u2019s 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 simply components with a well-defined interface. <\/p>\nGuardVerdict<\/code> with four fields: safe<\/code>, reason<\/code>, details<\/code>, and provider<\/code>. This provides full auditability: every decision is traceable. <\/p>\n\n
block<\/code>: raises GuardBlockedError<\/code> and halts execution<\/li>\nwarn<\/code>: logs the finding and continues<\/li>\nannotate<\/code>: attaches the verdict to the agent\u2019s context<\/li>\n<\/ul>\nAzure Prompt Shield: The First Built-in Guard<\/h3>\n