It depends on whether the rule was enforced. If the agent attempted something a bound forbids, the action is refused and filed; nothing happened. If it got through because the rule was never enforced, it is an incident: the capability stops, its depth drops, harm is put right, and the gap is closed before authority returns.
Is an attempted breach the same as a breach?
No, and treating them alike causes problems in both directions. An agent proposing an action outside its bounds, and being refused, is the system working. If every refusal were treated as a failure, people would loosen bounds to stop the alerts.
But refusals are still information. A sudden rise in refused attempts on one capability means something changed: a new kind of request, a source that now says something different, a brief that no longer fits. They should be reviewed in a routine weekly look, not ignored.
A real breach is different. It means an action that should not have happened did. That usually points to one of three gaps: the rule was never expressed as a bound, the bound read a wrong or outdated fact, or the action reached the outcome by a route nobody bound.
What happens, step by step, after a real breach?
| Stage | Who acts | What happens | What is recorded |
|---|---|---|---|
| Stop | Team lead or on-call owner | The capability is switched off; depth drops to 1 the same day | Time, person, scope of the stop |
| Contain | Process owner | Find every other case the same gap could have affected | List of cases checked |
| Put right | Process owner and customer-facing team | Reverse or correct where possible; contact affected customers | Each remedy and communication |
| Reconstruct | Risk or the agent owner | Rebuild the decision from the record: inputs, sources, bounds checked, verdict | Reconstruction note |
| Fix | Process owner and platform team | Add or correct the bound, the source, or the brief | Change log entry |
| Recertify | Risk | Re-test the capability on real cases, including the failing one | New certification result |
| Restore | Process owner, with risk's approval | Depth is raised again only on the new evidence | Approval record |
Regulatory reporting may apply as well. Financial firms in the EU, for example, have ICT incident reporting duties under DORA. Decide in advance who judges whether an agent incident is reportable.
What does this look like in practice?
Take an energy supplier's billing team. A rule says customers on a payment plan must not receive automated arrears letters. The agent sends one to a customer who agreed a plan the previous day.
The capability is stopped within the hour. Containment finds four other customers who agreed plans in the past week and were also in the arrears batch; two received letters. The team writes to all three affected customers to apologise and confirm their plans stand.
Reconstruction shows the cause. The agent checked plan status from a nightly extract, which had not yet picked up the new plans. The rule existed, but the bound read a stale fact. The fix is to check plan status from the live billing system at the moment of sending. The capability is re-tested, including cases with same-day plans, and restored a week later.
Why must the agent be able to name the rule it is applying?
Because without that, neither the refusal nor the breach can be explained. If the agent's refusal says "I cannot do that", nobody can tell whether it applied the right rule. If it says "refused: customer on an active payment plan, arrears procedure section 4", anyone can check. The argument is made in a compliance agent should cite the rule.
The same applies after a breach. A record that names which bounds were checked, and what each found, turns reconstruction from guesswork into reading.
How is this different from failing certification?
Certification failure is found in testing; a breach is found in production with real customers affected. The response to a failed run is similar but quieter: the agent keeps only the highest depth the run cleared, or drops to depth 1 that day if it cleared none, and the capability is fixed and re-tested before it returns. That path is covered in what happens when an AI agent fails certification. A breach adds containment, remedy and possibly reporting.
Where Pryme fits
In Pryme, every action passes the minimum chain at the moment of action, and the verdict names the bound that decided, so most attempted breaches end as filed refusals. When something does get through, the append-only record lets you reconstruct exactly what the agent saw. A failed Attest run cuts depth the same day: a short run keeps only the highest depth it cleared, and a run that clears no depth drops the agent to depth 1. More in our guide to agent governance.
Questions people ask
Is the agent "punished" for breaking a rule?
No. Its authority is reduced until evidence supports restoring it. The useful question is which control failed, not who to blame.
Who tells the customer?
A person, or the agent drafting a message that a person approves. An apology for an agent's error should never itself be sent unreviewed.
What if a second agent caught the breach?
Then the check worked, but treat it as a breach all the same. If the two agents disagree on whether a rule applies, a person decides; see what happens when two AI agents disagree.