Architectural Evaluation: Why We Re-Engineered AI Safety From Text Guardrails to Infrastructure Control Planes

The open-source AI safety ecosystem already contains tools for tasks like structured-output validation, conversational guardrails, sensitive-data detection, and prompt or response filtering. Companies like Guardrails AI, LLM Guard, and NVIDIA NeMo Guardrails address key aspects of this problem. However, with autonomous AI systems, the security landscape changes.

These agents are capable of making more than just text; they can choose models, pull in untrusted context, invoke Model Context Protocol (MCP) servers, query databases, alter files, generate pull requests, deploy applications, and trigger external business processes.

Validating the safety of text is no longer sufficient in these scenarios. The system needs to decide: Does this identity have permission to perform this action through this connector, against this resource, with these arguments, within this tenant and region, and does this action require approval? This is the responsibility of an AI infrastructure control plane.

The article explains why PolicyAware was developed, focusing on policy enforcement, MCP tool governance, risk classification, model routing, evaluation, and audit evidence rather than simply acting as an additional text-validation layer.

Guardrails and control planes perform different functions. Guardrails primarily focus on validating prompts, responses, conversation flows, or output structures, while PolicyAware's control plane governs requests, identities, models, tools, side effects, evaluations, and provides evidence for decisions. PolicyAware accepts various inputs, including prompts and model outputs, and returns decisions such as pass, fail, retry, repair, or filter, or it can require approval, allow, conditional allow, or transform a tool's operation.

PolicyAware's control plane allows for tool governance, connector/action policies, MCP proxying, and protocol awareness. It inspects MCP JSON-RPC tools/call requests before forwarding them, enabling model routing based on risk, region, provider, cost, and availability, as well as generating audit evidence like decisions, reason codes, matched policies, evaluations, and trace IDs.

Autonomous agents require action-level governance. For instance, an agent connected to a filesystem MCP server can have rules for reading, writing, or deleting files. While a language model might see these as tool calls, security concerns dictate that each action has different risk levels, require different permissions, and need to be logged with identities and trace IDs.

Guardrails cannot reliably enforce such rules through conversation text alone; they must occur at the tool boundary before the MCP server receives the request. PolicyAware implements this using a deny-by-default policy, where every request is evaluated against deterministic rules based on the connector, action, identity, and request context.

PolicyAware operates through a layered architecture that separates governance into replaceable components. The request lifecycle includes data-protection checks, risk classification, policy determination, and ultimately, allowing or denying the request. Denied or approval-gated requests stop before execution. Allowed requests proceed to a model router or tool-policy engine.

A key feature is that transformations, such as redaction rules, do not grant access; they only modify requests when they would otherwise be allowed. Finally, PolicyAware includes an MCP policy proxy that evaluates JSON-RPC traffic before reaching the MCP server, enabling identity, role, tenant, and agent context inspection, sensitive information detection, unauthorized action denial, approval requisition for high-impact operations, and redaction of potentially sensitive information.