A Blanket Policy Is a Broken Policy for AI Agents

One security policy cannot govern every AI agent, because different agents carry different risk. A customer support agent that books and refunds airline tickets, an inventory agent that reads and writes to a warehouse database, and a medical intake agent that handles patient records face different threats, touch different data, and call different tools. A policy that fits one of them leaves the other two either exposed or unable to work.

This is the part of agent governance that breaks when teams try to standardize too hard. A single blanket policy is easy to write and easy to enforce, but it either sets controls so loose that high-risk agents slip through, or so tight that low-risk agents get blocked from doing their jobs. The goal is one framework applied consistently, with the specific controls tuned per agent.

The same action means different things to different agents

Consider PII. For a medical intake agent, reading a patient's medical history is the job. The same agent reading a credit card number is a problem, because that data does not belong in a health record. For an airline support agent, the reverse: payment details are in scope, detailed medical information is not.

A single PII policy cannot express both. Block all PII and the medical agent cannot function. Allow all PII and the airline agent leaks payment data into an external model. The policy has to know what each agent is for.

The same logic applies to almost every control:

• Toxicity. A hospital intake agent discussing injuries, blood, or trauma is operating normally. A customer service agent using the same language is a brand and safety incident. The toxicity threshold is use-case specific.
• Tool access. An inventory agent needs write access to the stock database to do its job. A read-only knowledge agent with that same write access is a standing liability.
• Topic scope. A finance agent answering questions about cash flow is on task. A support agent wandering into financial advice is off the rails.

An action that is correct behavior for one agent is a policy violation for another. That is why the control has to be scoped to the agent, not applied globally.

The three ingredients that change per agent

When you look at what actually differs between a well-governed support agent and a well-governed inventory agent, three things change while the framework around them stays the same.

Guardrails are the real-time checks on what goes into and comes out of the model. An airline support agent handling payments and public traffic needs PII redaction, toxicity screening, hallucination detection, and prompt injection detection. An internal inventory agent may only need hallucination and prompt injection checks plus a custom filter for sensitive internal data. Same category of control, different configuration.

Evaluators are the checks on whether the agent is doing its job well. A support agent is judged on friendly tone, brand adherence, answer correctness, and whether it stays on approved topics. An inventory agent that generates SQL from natural language is judged on SQL correctness and whether it retrieved the right context. A medical agent is judged on clinical accuracy and factual consistency. The evaluator set is specific to what the agent is supposed to do.

Access and policy controls govern what the agent can reach. The airline agent needs scoped database access and tool restrictions. The inventory agent needs careful read/write separation on the stock database. The medical agent needs role-based access to patient data, audit logs, and compliant data retention. The access model follows the agent's risk, not a shared default.

Three agents, three different policy configurations, built from the same set of building blocks.

One framework, many policies

If every agent needs its own configuration, the risk is obvious: every team hand-rolls its own controls, nothing rolls up, and the organization ends up with fragmented governance it cannot report on or audit. Per-agent customization without a shared framework is how you get a thousand bespoke policies and no way to see across them.

The resolution is to separate the framework from the configuration. The framework is unified and consistent across the enterprise: every agent gets an owner, a risk classification, and a defined set of policy categories it must address. The configuration within each category is tuned per agent. A policy like "applications reading datasets that contain PII must enforce the PII guardrail" applies org-wide as a rule, while which agents it covers and how the guardrail is tuned depends on the agent.

This is also what keeps customization from turning into chaos. Risk tiering does the sorting: a public-facing agent that touches payment data sits in a higher tier with stricter required controls than an internal agent that only reads a product catalog. The tier sets the floor; the per-agent configuration handles the specifics. Policy-based governance for agentic AI works this way, translating a written framework into machine-checkable policies scoped per application, model, and environment, so one governance standard produces many agent-specific policies without fragmenting.

Policy that runs, not policy that sits in a document

A per-agent policy only matters if it is actually enforced on live traffic. A governance rule written in a document and checked once a quarter cannot keep up with an agent that decides what to do at runtime. The policy has to run as an enforced control: guardrails evaluating every request and response, evals scoring real interactions, access rules applied on every tool call, and an alert when any of it stops passing.

That runtime enforcement is where per-agent scoping pays off. When a policy is scoped to what a specific agent is for, a violation means something. A PII guardrail firing on the medical agent that should be reading records is noise; the same guardrail firing on an agent that has no business touching PII is a real signal. Generic policies produce generic alerts. Specific policies produce signals a team can act on.

This is the same principle that makes agent governance work in practice: governance holds when it is built into the agent's runtime, with controls scoped to the agent's actual risk surface rather than applied as a blanket default.

The short answer

You cannot apply the same security policy to every AI agent because agents carry different risk. The same action, reading PII, using strong language, writing to a database, can be correct behavior for one agent and a violation for another. What changes per agent is the configuration of guardrails, evaluators, and access controls. What stays constant is the framework around them: every agent gets an owner, a risk tier, and a defined set of policy categories, enforced on live traffic rather than filed in a document. One framework, many policies, each scoped to what its agent is actually for.

Want to see per-agent policy enforcement work across a fleet of agents? Book a demo with an AI expert.

‍