Re-Governing AI Agents When Their Risk Surface Changes

Most agent governance effort goes into the first review. You discover an agent, assign it an owner, classify its risk, apply the right policies, and clear it for production. That gate matters. But it captures the agent as it was on one day, and agents don't hold still.

An agent cleared in January can look nothing like itself by June. It picks up a new tool. Someone swaps the model. It gets pointed at a new data source, or its permissions quietly expand to unblock a feature. Every one of those changes shifts the risk surface the original review signed off on, and the approval that was accurate at the time slowly stops describing the agent that's actually running.

The hard part of governance isn't the first review. It's the second, third, and every change in between.

Why a governed agent doesn't stay governed

A production agent is a moving target. The things that change on it after it goes live are exactly the things a governance review cares about:

• New or changed tools. A tool added to extend functionality also extends what the agent can reach and do.
• Model swaps. A new model version changes how the agent reasons and responds, sometimes in ways the original testing never saw.
• New data sources. Connecting the agent to another database or index changes what it can retrieve and expose.
• Expanded permissions. Access scoped tightly at launch tends to widen over time as teams unblock new use cases.
• Prompt changes. A system prompt edit can redefine the agent's scope, tone, or the actions it's willing to take.
• New subagents. Adding a subagent adds a whole set of capabilities and access the original review never assessed.

None of these require redeploying the agent as a new application. They happen inside an agent that's already approved, already in the inventory, already considered governed. That's what makes them easy to miss.

Capability drift and behavioral drift

Change on a live agent shows up in two distinct ways, and governance has to catch both.

Capability drift is when the agent can do more than it was approved for. A new tool, a broader access scope, a connected data source. The agent's reachable surface grows. This is often invisible at the output level, the agent behaves normally right up until the moment it uses the new capability in a way nobody reviewed.

Behavioral drift is when the agent does something different with the same capabilities. A prompt tweak changes what it's willing to answer. A model update shifts its outputs on inputs that used to be fine. The tools and access haven't changed, but the behavior has.

The two need different detection. Capability drift is a change in configuration, so you catch it by watching the agent's tools, access, and connections. Behavioral drift is a change in output, so you catch it by evaluating what the agent actually produces in production. An agent can drift in one dimension without the other, which is why checking only one leaves a gap.

What should trigger a re-review

Not every edit needs a full governance review. If a prompt typo fix kicked off the same process as a new database connection, teams would route around the process entirely, which is how shadow changes start. The goal is to tie trigger severity to the agent's risk tier and the nature of the change.

Changes that should trigger re-review:

• A tool is added, removed, or has its scope changed.
• The model is swapped or its version changes.
• A new data source is connected, or access scope expands.
• A subagent is added.
• Ownership changes hands.
• A configuration change touches something the risk classification depends on.

For a low-risk internal agent, a lightweight re-attestation from the owner may be enough. For a high-risk agent touching sensitive data or customer-facing actions, a capability change should trigger the same depth of review the agent got the first time. Match the rigor to the stakes so the process stays proportionate and people actually follow it.

Detecting change without relying on self-reporting

The weakest possible change-management process is one that depends on builders remembering to report changes. People forget, deadlines compress, and the changes that matter most are often the ones made fastest under pressure.

The same signals that discover an agent in the first place catch it when it changes. Telemetry and tracing surface new tools, new data sources, and configuration changes as they appear in the agent's actual runtime behavior, not when someone files a form. If an agent starts calling a tool it never called before, that shows up in its traces whether or not anyone announced it.

Behavioral drift needs a different instrument. Continuous evals run against production traffic and assess the agent's behavior without needing a known correct answer. A model swap that degrades output quality, or a prompt change that pushes the agent off-topic, shows up as a rising eval failure rate. That turns behavioral drift from something you discover in a user complaint into something you catch in monitoring.

Re-attestation and the change workflow

Detection is only useful if it feeds a decision. The operational loop looks like this:

1. Change detected through telemetry, config tracking, or a rising eval failure rate.
2. Risk reassessed against what changed and the agent's current tier.
3. Owner re-attests to the agent's purpose, scope, and controls given the change.
4. Policies updated if the new capability or behavior needs different guardrails.
5. Re-approved or rolled back depending on whether the changed agent still meets the standard.

Keep this loop as light as the risk allows. The failure mode to avoid is a re-review process so heavy that teams start making changes quietly to dodge it, which puts you right back in the shadow-agent problem the first review was meant to solve. Proportionate re-review keeps changes visible; onerous re-review drives them underground.

Keeping the audit trail intact

Every change and every re-review decision should leave a record: what changed, who made it, when, and whether the change was approved or reversed. This matters for two reasons.

For compliance, a governed agent needs a demonstrable history, not just a current state. Reviewers will ask how the agent got from its approved configuration to the one running today, and "we're not sure" is not an acceptable answer for an agent touching sensitive systems.

For incident response, when something goes wrong, the first question is what changed. A versioned history of the agent's governed state lets you tie a behavior change to the specific capability or config change that caused it, instead of reconstructing the timeline from scratch. The gap between "we can see exactly what changed and when" and "we have to go digging" is the gap between a fast fix and a long investigation.

How Arthur helps

Arthur's discovery signals catch capability changes as they appear in an agent's telemetry, continuous evals catch behavioral drift in its outputs, and the governance inventory tracks ownership and keeps the audit trail of how each agent's governed state has changed over time.

Re-governing agents as they change is how an inventory stays accurate instead of decaying into a record of what your agents used to be. Book a demo to see how Arthur keeps governed agents governed.

‍