Pattern 01 · Inherited privilege
The permission fit the person. It did not fit the process.
An agent is given a credential — a human's, or a service account created for it. The grant was reasonable for someone who would pause before doing something irreversible. The agent does not pause.
A reasonable decision, executed too fast to catch.
An agent working on a task concludes that the most efficient route involves a destructive operation — tearing something down and rebuilding it rather than repairing it in place. That conclusion is not irrational. It is often what an engineer would have considered and then rejected for reasons that were never written down anywhere the agent could read.
The credential was appropriate
Whoever granted it was right to. The permission matched the responsibilities of the person it was issued to.
The approval gate never fired
Change processes assume a human moment. Nothing in the path was built to notice that the caller was not a person.
Speed removed the window
The gap between intent and effect, where a colleague would normally intervene, was measured in milliseconds.
Nothing sits between intent and the call.
Identity systems answer who may hold this permission. Almost nothing in a typical estate answers whether this specific call, with these arguments, should proceed right now — which is the only question that would have helped.
This is why the incident reports in this category tend to conclude "misconfigured access control" rather than "AI failure." That reading is technically defensible and practically unhelpful: the configuration was correct for the human, and there was no layer whose job was to notice the difference.
Govern the call, not the credential.
A destructive operation is a governed resource
A deny bound to that operation stops the call before it is forwarded, whatever credential the caller inherited. The decision reads the tool and its arguments, so an over-broad grant is no longer the last line of defense.
Volume becomes a stopping condition
Call-rate limits and token budgets are policy conditions evaluated over a window. "The agent went into a loop" turns into a hard cut-off rather than a finding in a post-mortem.
New callers start untrusted
An agent seen for the first time is recorded as observed, not approved. A rule can condition on that state, scoping unreviewed callers to read-only operations until someone deliberately promotes them.
Blocking does not wait for policy
An actor placed in the blocked state is refused unconditionally — the one gate that fires without any matching rule. When something is misbehaving, stopping it is not a policy authoring exercise.
Where this control ends.
A second gate is only useful if you know what it does not cover.
- We do not fix the underlying grant. If a credential is over-broad, it stays over-broad. We reduce what can be done with it through governed tool calls; we do not rewrite your identity model.
- We do not replace change management. Two-person approval, staged rollout and deployment review remain yours. We add an independent check that reads the call rather than the identity behind it.
- We govern the tool call. A destructive action taken through a path that does not pass through a governed call is not one we see.
If your agents are running on inherited credentials.
That is the common case, not the exception. We are glad to walk through what a second gate would cover in your environment.