Flock v0.5.500: Enterprise Security for Agentic AI

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?

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.

Keyless Authentication with Azure Entra ID and Managed Identity

The Problem with API Keys

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’ machines. It needs to be rotated, audited, and kept out of source control. In practice, that rarely happens.

In Azure-native workloads, there is a better way: Managed Identity. 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.

Flock 0.5.500 makes this the default path for Azure deployments. Authentication works across Azure OpenAI and Azure AI Foundry.

How It Works

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

The result is clean, keyless configuration:

from flock.engines import DSPyEngine
from flock.engines.auth.azure import get_default_azure_token_provider

token_provider = get_default_azure_token_provider()

engine = DSPyEngine(lm_kwargs={
    "api_base": "https://.openai.azure.com/",
    "api_version": "2024-12-01-preview",
    "azure_ad_token_provider": token_provider,
})

DefaultAzureCredential resolves the correct credential automatically: Managed Identity when running on Azure, az login during local development. No code changes are required between environments.

For workloads using a user-assigned Managed Identity, pass the client ID:

token_provider = get_default_azure_token_provider(
    managed_identity_client_id=""
)

The Azure AI Foundry Agents API requires a different token scope. That is covered as well:

from flock.engines.auth.azure import (
    get_default_azure_token_provider,
    AZURE_AI_FOUNDRY_SCOPE,
)

token_provider = get_default_azure_token_provider(scopes=AZURE_AI_FOUNDRY_SCOPE)

Getting Started

Azure identity support ships as an optional dependency to keep the core package lean. It pulls in azure-identity, Microsoft’s official Python credential library:

uv add "flock[azure]"

That’s it. No secrets. No rotation. No exposure.

GuardComponent: Pluggable Input and Output Protection

The Prompt Injection Problem

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 consistently ranks as one of the top risks in production LLM applications.

Without explicit protection, there is no reliable way to detect these attacks before they influence what an agent does.

Flock 0.5.500 introduces a guard framework that makes protection composable and configurable, rather than bolted on as an afterthought.

How It Works

GuardComponent is an abstract base class that integrates into Flock’s existing agent lifecycle. Guards execute during on_pre_evaluate (before the model sees the input) and on_post_evaluate (after the model produces output). No new architectural patterns are needed: guards are simply components with a well-defined interface.

Each guard returns a GuardVerdict with four fields: safe, reason, details, and provider. This provides full auditability: every decision is traceable.

Three actions can be configured per phase:

• block: raises GuardBlockedError and halts execution
• warn: logs the finding and continues
• annotate: attaches the verdict to the agent’s context

Guards compose naturally. Assign priorities to control execution order. A block in any guard stops subsequent components and the engine run.

Azure Prompt Shield: The First Built-in Guard

The first built-in implementation calls the Azure AI Content Safety Prompt Shields API. It detects two classes of attacks: direct jailbreak attempts in user prompts, and indirect prompt injection embedded in context documents.

Both Managed Identity and API key authentication are supported. Document content is extracted automatically from Flock’s artifact types, with configurable truncation for large documents.

from flock.components.agent.azure_prompt_shield import (
    AzurePromptShieldGuard,
    AzurePromptShieldConfig,
)
from flock.core import Agent
from flock.engines import DSPyEngine

agent = Agent(
    name="support_agent",
    engine=DSPyEngine(model="azure/gpt-4.1"),
    components=[
        AzurePromptShieldGuard(
            priority=-10,  # run before all other components
            config=AzurePromptShieldConfig(
                endpoint="https://.cognitiveservices.azure.com",
                on_input_flagged="block",
                scan_context_artifacts=True,  # scan documents passed as context
            ),
        ),
    ],
)

Setting priority=-10 ensures the guard runs before any other component. If the input is flagged, a GuardBlockedError is raised immediately, and the model never sees the malicious content.

Building Custom Guards

The framework is designed to be extended. Implement scan_input and optionally scan_output, and the base class handles the rest: lifecycle wiring, artifact extraction, verdict routing, and action dispatch.

from flock.components.agent.guard import GuardComponent, GuardVerdict

class MyCustomGuard(GuardComponent):
    async def scan_input(self, text: str, documents: list[str]) -> GuardVerdict:
        flagged = await my_policy_check(text)
        return GuardVerdict(
            safe=not flagged,
            reason="Custom policy violation" if flagged else None,
            provider="my-guard",
        )

Multiple guards with different backends can run on the same agent. Combine Azure Prompt Shield with a domain-specific policy check, for example. Priority ordering guarantees a deterministic execution sequence.

The GuardComponent interface is also a natural integration point for broader policy enforcement tooling. Microsoft’s Agent Governance Toolkit covers policy enforcement, zero-trust identity, and audit logging across the full OWASP Agentic Top 10. A custom guard wrapping its PolicyEvaluator can bring those deterministic controls directly into the Flock agent lifecycle, putting content safety (Prompt Shield) and tool-call governance in the same execution pipeline with no changes to the agent itself.