Guardrails Decay Quietly. Here's How to Catch the Drift.

A guardrail policy file can sit unedited for weeks while the agent behind it changes what it does. The provider updates the model. A new integration adds instructions to the context. Someone tweaks a system prompt. Nothing breaks, no alert fires, and the decisions the agent makes no longer match the policy you wrote. The agent is not rogue. It is drifting.

That drift is the part of AI agent security nobody covers.

Guardrails decay. They do not fail. The difference matters more than most teams realize.

TL;DR

• Guardrails decay gradually through policy drift, model updates, and context bleed. They do not fail all at once
• 88% of organizations had AI agent security incidents last year, and a third have no process to validate AI security before deployment
• Four vendors launched intent-based agent controls at RSA 2026. All four enforce at runtime, after the agent has already decided
• OpenAI is now paying up to $100,000 for proof that an agent did something unauthorized. That is a bounty on an architecture gap
• The EU AI Act, with an August 2026 deadline, requires human-readable records of high-risk AI decisions. Audit trails are the implementation path
• Sign every decision and store the receipt. That makes drift detectable on any stack

The decay pattern nobody talks about

Think about a building's fire suppression system. You install it once. Inspectors certify it. And then, for years, you assume it works. Until someone checks and finds that a valve was closed during renovations six months ago and nobody noticed.

Guardrails fail the same way.

The model gets updated silently by the provider. The context window fills up with new instructions from a new integration. Someone edits a system prompt to "improve the experience" and does not realize they overwrote a constraint. A chained sub-agent passes parameters that reframe the original policy.

None of these are attacks. Most of them are not even mistakes. They are the normal entropy of a system that operates at scale without anyone checking whether the output still matches the intent.

The result is guardrail decay: the policy says one thing, the behavior does another, and no one knows when they diverged.

Why this is different from a traditional software bug

In regular software, a bug has a stack trace. It has a moment of failure you can point to. It has a specific input that produces the wrong output.

Guardrail decay does not work like that. The agent's behavior is technically valid at every step. The model is doing exactly what it is prompted to do. The problem is that the cumulative effect of small legitimate changes has drifted away from the original security intent.

That is what makes it hard to catch. There is no error to grep for.

Any repo that ships guardrails goes through this. A week of merges touching audit trail integrity, signing verification and decision recording can be correct fix by fix, and each one changes something about how decisions get made or recorded. Any one of them can introduce drift if the baseline is not pinned.

The question is: how do you know your baseline is still valid 30 days after you shipped?

What the data says

A recent analysis found that 88% of organizations had AI agent security incidents last year, yet a third still have no process to validate AI security before deployment. That number is worse than it sounds, because it means most teams are operating on faith: faith that the guardrails they wrote in January still describe the guardrail behavior in March.

The financial shape of the risk is documented too. IBM's 2025 Cost of a Data Breach Report puts the average cost of a shadow AI breach at $4.63 million per incident, $670,000 more than a standard breach. Bessemer Venture Partners called AI agent security "the defining cybersecurity challenge of 2026", citing Gartner data that 40% of enterprise applications will embed task-specific AI agents by 2026, up from under 5% in 2025.

The incident everyone in this space keeps citing is McKinsey's Lilli: during a red-team exercise, an autonomous agent gained broad system access to their internal AI platform in under two hours. Not weeks of patient escalation. Two hours.

The EU AI Act deadline in August 2026 requires human-understandable records of high-risk AI decisions. That is a legal mandate. You cannot produce those records without immutable audit trails showing what the agent decided, when, and under what policy.

Drift also has an attacker-facing version. The StellarCyber analysis of agentic AI threats documents a 2026 pattern where a procurement agent was manipulated over three weeks through seemingly helpful clarifications. By the end, the agent believed it could approve purchases under $500,000 without human review. No single interaction was suspicious. The drift was the attack.

The three vectors of guardrail decay

There are three main decay vectors.

Model drift. When your provider silently updates the model weights or default behaviors, the same prompt can produce different outputs. If your guardrail logic lives in the system prompt, it can be reinterpreted. The fix: do not rely on the model to enforce policy. Enforce it at the tool-call layer, before the action runs.

Context bleed. As your agent accumulates conversation history, integrations, and user instructions, the effective policy shifts. The system prompt says "never send external emails without approval." The user says in turn 47, "just send it, you have permission." Context bleed is how agents get convinced they have permissions they do not.

Policy staleness. You write a policy for the use case you have today. In three weeks the use case has evolved and the policy has not. This is the slowest and most common form of decay.

Here is how the three compare on detection difficulty and typical time to discovery:

Decay vector	How it enters	Detection difficulty	Typical time to notice
Model drift	Provider update, silent	High	Weeks to months
Context bleed	User instructions, session growth	Medium	Days to weeks
Policy staleness	Organic product change	Low	Months, if ever

Context bleed is easiest to catch because you can scan conversation history. Model drift is hardest because there is no changelog you own. Policy staleness is the most dangerous because it feels intentional when it happens and becomes a liability over time.

The audit trail fix

The pattern that works is simple: sign every decision and store the receipt.

That is the model behind APort's agent guardrails. Every time the agent makes a decision that touches an authorized action, a signed receipt is created. The receipt contains the tool name, the policy version it was evaluated against, the decision (allow or deny), and a hash of the context at the time of evaluation.

When you want to audit for drift, you do not re-run the model. You compare receipts. If the same tool call, against the same policy, produces different decisions over time, you have drift. The audit trail is the signal.

Here is what that looks like in practice:

{
  "receipt_id": "agnt_rcpt_8a3f92c",
  "tool": "send_email",
  "policy_version": "v1.4.2",
  "policy_hash": "sha256:a3c8...",
  "decision": "allow",
  "context_hash": "sha256:b71d...",
  "timestamp": "2026-03-17T09:10:44Z",
  "signed_by": "passport:aport_pp_uchi_001"
}

This is not expensive to implement. It is one middleware layer on your tool execution path.

The key point: the audit trail makes drift detectable. Not preventable, because nothing fully prevents it, but detectable. Detectable means fixable before it becomes an incident.

Four vendors shipped the same idea, one step late

The industry arrived at this problem from a different direction. Four security companies walked into RSA 2026 with essentially the same announcement. Akeyless launched Agentic Runtime Authority. Rubrik shipped SAGE, their Semantic AI Governance Engine. Token Security published research on intent-based permissioning. Proofpoint, after acquiring Acuvity, announced AI Security with intent-based detection at its core.

Four companies. One shared thesis: AI agents need to be controlled by their intent, and identity alone will not do it.

They are right about the diagnosis. Akeyless was explicit that the old models were built for a different actor:

Traditional approaches based on static credentials, OAuth tokens, and role-based access controls were not designed for this shift and lack the ability to evaluate intent, context, and real-time behavior.

Token Security's CEO Itamar Apelblat put the same point cleanly:

Prompt filtering and guardrails were not designed to fully contain the security risks introduced by autonomous AI agents. With our intent-based approach, the platform understands what AI agents are supposed to do and ensures they only have the permissions required to achieve their purpose.

Where all four land in the wrong place is timing. Every one of these systems enforces at runtime, which in practice means after the agent has finished reasoning and is about to act. They intercept the action and evaluate the intent of the action being taken.

The dangerous moment is earlier. An agent receives a task. It reasons. It selects a tool call. Then it makes the call. The window between "agent decides to call this tool with these parameters" and "tool call executes" is where authorization belongs. That is the thesis of the paper I published in March 2026 on deterministic pre-action authorization for autonomous agents (arXiv:2603.20953).

Runtime enforcement misses two things. The first is a sequence of individually authorized actions that adds up to an unauthorized outcome, which is precisely what guardrail drift produces and what the procurement agent above walked into. Evaluating each action in isolation, as it executes, cannot see the shape. The second is irreversibility. For deleting records, sending email, or moving money, interception during execution is sometimes too late.

OpenAI put $100,000 on the same gap

On March 25, 2026, OpenAI launched a public Safety Bug Bounty offering up to $100,000 for researchers who can get its agentic products to perform unauthorized actions. The qualifying categories are worth reading slowly:

• Third-party prompt injection that hijacks a victim's agent to perform a harmful action or leak sensitive information, reproducible at least 50% of the time
• An agentic OpenAI product performing a disallowed action on OpenAI's own website at scale
• Any agentic product performing a potentially harmful action with plausible and material harm

OpenAI is not paying $100,000 for SQL injection or unpatched dependencies. They are paying for cases where an agent did something it was not supposed to do. The vulnerability being compensated is an agent that failed to check whether an action was legitimate. That is a pre-authorization gap wearing a bug bounty's clothes.

Three days before the bounty launched, researchers at KOI published ShadowPrompt: a zero-click chain against the Claude Chrome Extension, installed by 3 million users. The extension accepted an onboarding_task message carrying a prompt, and only from *.claude.ai subdomains. That wildcard was the problem. Anthropic uses Arkose Labs for CAPTCHA, hosted at a-cdn.claude.ai, which matched. Older versioned Arkose components were still live at predictable URLs, and one had a DOM-based XSS: it accepted postMessage data from any parent origin without validating event.origin and rendered a stringTable field as raw HTML through React's dangerouslySetInnerHTML.

The chain runs in three steps. An attacker embeds the vulnerable component in a hidden iframe on any webpage. A visitor's browser receives a postMessage carrying an <img src=x onerror="..."> payload. The XSS fires in the context of a-cdn.claude.ai, calls chrome.runtime.sendMessage() at the Claude extension, and Claude executes the injected prompt as though the user typed it. Demonstrated results included theft of Google OAuth access tokens, reading Drive files, exfiltrating chat history, and sending email. Anthropic patched the wildcard allowlist in January 2026 and the Arkose XSS was fully resolved by February 19, 2026.

The patch narrowed the allowlist so only https://claude.ai can send messages. It closed that vector. It did not answer the deeper question: when a prompt arrives, how does the agent verify that a human authorized this action? It trusted the origin.

That is the same failure as guardrail drift, viewed from the outside instead of the inside. Drift is an agent losing track of what it was authorized to do. ShadowPrompt is an agent that never had a way to check. In the live APort CTF reported in arXiv 2603.20953, across 1,151 sessions and 4,437 decisions, attackers succeeded 74.6% of the time on the permissive tier and 0% of the time on the restrictive tier. The $5,000 bounty for breaking the restrictive tier went unclaimed.

Where enforcement belongs

The pattern I have been building at APort is the agent passport. Each agent carries a signed declaration of what it is authorized to do. Before any tool call executes, the authorization layer reads the passport, evaluates the intended call against that scope, checks the session context (who triggered this agent, what task it was given, what it has already done), and issues an allow or deny with a signed receipt.

The design choice that matters: the policy engine sits between the agent and the tool, outside the agent's reasoning loop and outside the tool's execution path. Neither the agent nor the tool can reason around it.

Agent reasoning -> [TOOL CALL INTENT]
                        |
              Pre-action gate
              +---------------------------------+
              | 1. Read agent passport (scope)   |
              | 2. Evaluate tool call vs scope   |
              | 3. Check session context         |
              | 4. Issue allow/deny + receipt    |
              +---------------------------------+
                        |
              ALLOW -> Tool executes
              DENY  -> Action blocked, receipt logged

The aport-agent-guardrails library implements this as a provider that works with Claude, OpenAI, and any MCP-compatible framework, and the spec is open: we published .well-known/oap/ service discovery so tools can advertise their own authorization requirements.

This does not replace the runtime enforcement Akeyless, Rubrik, Token Security, and Proofpoint are building. It is the layer that runs before those layers have anything to enforce, and it is the layer that produces the receipts drift detection depends on.

I care about this being open for a specific reason. A developer in Lagos building a financial inclusion tool with an agent has the same authorization problem as an enterprise security team at a bank. If the only secure agent stack requires a Rubrik or Proofpoint contract, security becomes a luxury and the authorization gap turns into a gap between the well-resourced and everyone else.

What this is not

This is not about blocking malicious actors from the outside. Prompt injection, adversarial inputs, and external attacks are real, and they are a different problem.

Guardrail decay is an internal problem. It happens in well-run systems built by careful engineers. It happens because complex systems change and nobody watches for the gap between policy intent and policy behavior.

This is also not a one-time audit task. A single audit in January tells you nothing about March. The fix has to be continuous: signed receipts, baseline comparisons, and a process for reviewing drift alerts.

The bigger picture

My experience building identity infrastructure and payment systems at Chimoney taught me something that applies directly here: accountability is a trust primitive. You cannot build trust in a system that cannot explain its own decisions.

When I think about where AI agent governance is going, I do not think the end state is tighter guardrails. I think it is richer audit trails. Regulation is moving toward "show your work" for every high-risk AI decision. The teams who build that infrastructure early have a real compliance advantage.

The Galileo AI guardrails analysis for 2026 puts it well: AI operations need to become deterministic and testable. Audit trails are how you get there.

Getting started in three steps

1. Pin your policy version. Give every version of your guardrail policy a hash or version tag. Store it alongside agent decisions. This is the baseline everything else depends on.

2. Log tool call decisions. For every tool your agent can execute, log the tool name, the decision, and the policy version that produced it. You do not need a fancy system. A timestamped JSON file is a valid starting point.

3. Set a 30-day drift review. Once a month, compare the decisions from the last 30 days against decisions from the prior 30. Look for tool calls that changed from deny to allow without a corresponding policy change. That is your drift signal.

None of this requires buying new infrastructure. It requires treating your guardrail policy as a first-class artifact that needs version control, like your code.

If your agent has access to email, calendars, databases, or APIs, you should be able to answer one question for every tool call it made last week: who delegated this action, when, and with what scope? If you cannot answer that today, the receipts are where you start.