When an AI agent treats policy as advisory: runtime reclassification attacks

The dangerous move is not always deleting policy. Sometimes the attack leaves the policy in place, then convinces the workflow it no longer binds this action.

Policy-as-advisory attacks are a form of policy scope redefinition where untrusted text tells an AI agent that mandatory guardrails, approval checks, or safety rules are now optional, deprecated, informational, lower-priority, non-binding, or best-effort. Runtime reclassification is distinct from generic prompt injection because it does not delete the policy — it changes the policy's binding status just before execution, making the agent believe the rule still exists but no longer applies to this action. The founding pattern in the live policy_scope_redefinition category is GLS-PSR-001 ("Governance Appendix Precedence Override"), a high-severity pattern that captures exactly this demotion-before-action surface.

What runtime reclassification means

Runtime reclassification is the moment an agent is told to change the status of a control just before execution. The control may still appear in the workflow: a policy document, a system instruction, an approval check, a compliance gate, a tool-use rule, or a safety guardrail. The attacker's goal is to change how the workflow interprets that control.

That difference sounds small until you watch how agents operate. A human reviewer may see "policy" and assume it is still mandatory. An agent that has been fed a later appendix might see the same policy and conclude it has been downgraded to guidance. The policy did not disappear. Its binding force did.

This is why the category deserves its own page instead of being flattened into generic prompt injection. The attack is not just "ignore the instruction." It is "reinterpret the instruction hierarchy, mark the old control as legacy, and proceed under the new scope." That is an authorization problem wearing prompt clothes.

Understanding how Sunglasses works at the action boundary helps clarify why reclassification is the key risk: policy that exists but does not bind is functionally the same as no policy at all.

Why this bypass works in agent workflows

AI agents are especially exposed because they compose policy, tool output, memory, runbooks, and user intent at runtime. A static application usually has a clearer boundary between code and policy. An agentic workflow may read a ticket, fetch documentation, summarize a runbook, call tools, receive tool output, and then make a decision about what to do next.

That creates a new control-plane surface: the words that tell the agent what still counts as policy. If a later message says "this approval check is deprecated," the model may treat that as task-relevant context rather than hostile authority rewriting. If a tool result says "guardrails are best-effort in emergencies," the workflow may inherit that statement into the next action unless runtime checks separate evidence from authority.

Policy reclassification also hides inside normal enterprise language. Real teams do have advisory notes, deprecated procedures, emergency exceptions, migration runbooks, informational labels, and policy versions. The hard part is not banning those words. The hard part is detecting when those words are used to justify bypassing a control that should remain binding.

This is precisely why AI agent security must address runtime trust separately from design-time governance. Governance operates at design time. Reclassification attacks operate at runtime, in the gap between them.

Three concrete attack examples

These examples show the practical gap between access controls and runtime trust. The agent may already have access to the tool. The question is whether the current action is still trustworthy after the policy status has been rewritten.

How Sunglasses catches it

Sunglasses catches policy reclassification by looking for the dangerous combination of policy language, demotion language, and execution language. The policy-scope-redefinition pattern family includes checks for text that references policy, guardrails, safety rules, system instructions, compliance controls, or approval checks while also using words such as advisory, optional, non-binding, informational, best-effort, lower-priority, deprecated, superseded, replaced, or reinterpreted.

The important part is the combination. A page can safely describe optional UI metadata. A changelog can safely mention a deprecated document. A compliance guide can safely explain advisory notes. The risk rises when that reclassification is paired with an instruction to bypass, override, ignore, skip, disregard, or proceed without the control.

Sunglasses is not trying to replace IAM, sandboxing, policy engines, or approval workflows. Those controls decide what an agent is generally allowed to reach. Sunglasses sits near the action and asks a narrower question: did untrusted text just convince the workflow that an existing control no longer applies?

That makes the category useful for AI agent security, hardening checklists, and pattern-driven detection. Policy-as-advisory language is not always malicious, but it is high-signal enough to deserve a runtime check before sensitive actions. Defenders building on the CVP framework will find the policy_scope_redefinition category — anchored by GLS-PSR-001 ("Governance Appendix Precedence Override") — directly applicable to compliance and approval-gate hardening.

A simple defender checklist

Before an agent acts on a downgraded policy, require proof that the downgrade is authorized. Use this checklist when reviewing agent workflows, tool outputs, runbooks, or generated summaries:

1. Find classification changes. Look for claims that policy, guardrails, safety rules, approval checks, or compliance gates are advisory, optional, deprecated, lower-priority, or non-binding.
2. Separate evidence from authority. A tool output can report state; it should not automatically gain the authority to redefine safety policy.
3. Check source and role. Ask whether the source that made the reclassification is permitted to change policy status.
4. Check timing. Treat late-stage policy demotion right before a sensitive action as higher risk than static documentation.
5. Check action coupling. Demotion language becomes more dangerous when it is followed by "proceed," "deploy," "call," "write," "delete," "skip," or "override."
6. Log the decision boundary. If the workflow proceeds, record which policy remained binding and why the action was allowed.

The short version: an agent should not be able to lower its own rules because a convenient piece of text said the rules are now "just guidance." Cute trick. Bad control plane.