Part two of two. Part one covered why agent authority is a graph problem.
Self-healing infrastructure has been one of the genuine wins of the last decade. A configuration drifts, a detector notices, the platform restores the known-good state, and a human reads about it the next morning. It works, it is well understood, and by now most large estates run some version of it.
It also has a blind spot that agents make expensive, and it is easiest to see by asking what “healed” means.
A misconfigured storage bucket is made private again. Good. But for the eleven hours it was public, an agent with read access to that bucket was operating with an authority nobody intended it to have. Restoring the bucket does not restore the authority boundary — it fixes the state, and leaves the permissions exactly as they were.
What self-healing repairs
Configuration drift. Bad deployments. Missing patches. Resource state. Anything with a known-good version to restore to.
What it leaves untouched
Who — or what — could reach the thing while it was broken, what they could combine it with, and whether that authority is still live right now.
Remediation without authority containment closes the door and leaves the keys in it.
The second problem: who is doing the healing?
Here is the part that tends to stop a conversation.
Automated remediation increasingly means an agent performs the fix. That agent needs substantial authority to do its job — it must read configuration across systems, modify production state, restart services, sometimes commit code. It is, by design, one of the most privileged principals in your estate.
And it is triggered by detections. Which means anyone who can influence a detection can influence what your most privileged agent does next.
If an attacker can cause a detector to fire — by corrupting an input, by poisoning a log, by prompt injection into something the agent reads — they are not attacking your systems directly. They are attacking the thing you built to defend them, and it has more authority than they do.
This is not a hypothetical class. It is the natural consequence of giving an automated system privileged write access and an event-driven trigger. The usual answer is to require human approval for remediation, which is honest but gives up most of the value: if a person has to approve every action, you have automated the detection and not the response.
What the two halves look like joined
The mechanisms in the first article — computing safe authority at issuance, and mutating credentials when the threat picture changes — are not a competing approach to self-healing. They are the missing half of the loop. Put together, a detection drives two responses rather than one.
Detect
A compiled, machine-readable detector fires. Deterministic — the same input produces the same verdict, which matters because the next steps are automatic.
Contain the authority — first, and immediately
Every live credential holding the implicated capability is contracted. Not just on the agent where the detection fired: across the fleet, pre-emptively. This happens before any repair is attempted, because the exposure is open while the repair runs.
Remediate the state — but only if the repair is provably an improvement
Restore the configuration, roll back the deployment, apply the fix. The part that is not familiar is what has to be true before the change is written: it must measurably reduce exposure on every regulatory position rather than on average, it must not worsen the attack picture while improving the compliance one, and where the fix was generated rather than drawn from a playbook, something that did not author it must first replay the attack and confirm it fails.
Constrain the remediator itself
The agent performing the repair holds a credential computed the same way as any other — least authority for this specific task, with the non-interference property verified before issuance. It cannot combine its repair capabilities into a path it was never meant to have, even if something influences what it decides to do.
Verify, then restore authority
Confirm the fix held. Only then are the contracted capabilities reissued — and reissued through the same safety computation, not simply handed back as they were.
Attest
Every event in the sequence — detection, contraction, immunisation, repair, verification, reissue — lands in a tamper-evident hash-chained ledger anchored in a transparency log.
Ordering is the whole argument. Repairs take time — a rollback takes minutes, a patch may take hours, a code fix may take days. Contracting authority takes under a second. Doing the fast containment first means the exposure window is bounded by propagation speed rather than by repair time, and those two numbers differ by orders of magnitude.
The same scenario, both halves running
Return to the mid-sized retail bank from the first article. Same three agents: complaints, regulator queries, payments reconciliation.
A configuration change to an internal document store removes an access restriction. The change was legitimate — an engineer widening access for a migration — and it was approved. It also makes a set of files readable that the complaints agent can reach through a capability it already holds.
With self-healing alone. Drift is detected against the known-good configuration. The platform restores the restriction. Elapsed time: around forty minutes, most of it the detection interval. The incident closes as remediated.
The question the ticket does not answer: during those forty minutes, did an agent read any of it? The agent had the capability the whole time and was operating normally. There is no anomaly to find, because nothing anomalous happened — it used an authorised capability against a resource that had become readable.
With both halves. The detection fires the same way. The difference is what happens in the first second: the capability that now reaches newly-exposed data is contracted out of the complaints agent's live credential, and out of every sibling credential that holds it. The agent continues working on everything else.
The configuration is then repaired on the same timeline as before — forty minutes, no faster. But the exposure window is not forty minutes. It is the propagation time of the contraction, and the difference between those two numbers is the entire point.
When the repair is verified, the capability is reissued — through the same safety computation, so if the migration left the store in a state where that capability now creates a path to an external sink, it is not silently handed back.
Six decisions in one night
All of the above is mechanism. What follows is the same bank on an ordinary Tuesday, and it is a better test. Three agents work through the night. Six decisions get made about what those agents are allowed to do — and in five of the six the answer is less than was asked for. That ratio is the point. Anything can grant. A control earns its place by what it declines, and by how little it takes away when it declines.
The last two decisions are about repair rather than about an agent. They are here because the first four do not hold without them.
1. The credential that was not issued as requested
The complaints agent starts its shift and asks for nine capabilities. Individually every one is justified and every one has an approver. Taken together they assemble a route: a read that can pull account identifiers into the agent’s working context, and a write into a workspace shared with an outsourced vendor.
The credential is not issued as asked — and it is also not refused. The smallest withholding that removes the route is computed, and it turns out to be one capability of the nine: the workspace write. The agent gets the other eight and works normally all night. The one that would have opened the path goes to a human with the actual reason attached.
Refusing is easy and refusing broadly is why controls get switched off. A system that had withheld four capabilities to be safe would have produced an agent not worth running, and the team would have applied for an exception within the quarter. Minimality is a commercial property, not a mathematical one.
2. The question asked again, about what it now carries
Ninety minutes in, the agent has done real work and read genuinely sensitive material. Its permissions have not changed. What it is holding has.
So the safety question is re-asked against the agent’s current state rather than against the grant it was issued with. An agent that has read restricted material is treated as restricted for the rest of that session — it can no longer write outward through a channel that was perfectly legitimate for it an hour earlier. Permissions describe what an agent may reach. After an hour of work, the more useful question is what it is carrying.
3. One detection, forty credentials narrowed
At 02:40 a detector identifies a weakness in a summarisation service that several agents call. Nothing has been exploited. The weakness is simply now known, and every credential minted before this moment was minted without that knowledge.
Inside the same session — not at the next token refresh, not after a change ticket — the affected capability is contracted out of the complaints agent’s live credential. And out of every sibling credential across the estate that holds it, pre-emptively, without waiting for each to be attacked in turn. The payments agent never held that capability and is not touched at all, which matters more than it sounds: a control that disturbs everything on every signal is a control nobody keeps.
4. The task that finished anyway
The reflexive response to a detection is to kill the agent, and that is what most agent-monitoring tools do — interrupt, suspend, terminate. It is also why controls on automation have short lives. Anything that halts a business process on every signal has an exception written for it by the end of the quarter.
So the response is graduated. The complaint in flight completes under reduced authority, without the summarisation step, and the customer never learns that anything happened. Killing the session is available and is the third tier, not the first. The authority the agent should no longer hold is gone either way — the difference is whether the work survives.
5. Where healing comes in — the repair that would have re-opened it
Contracting authority buys time. It does not fix the summarisation weakness, and an agent permanently running with reduced capability is a problem deferred rather than solved. So the underlying flaw goes into automated repair, and this is where the second half earns its place.
The first proposed fix closes the weakness and, as a side effect nobody writing it noticed, widens who can read a customer table — re-opening a route of exactly the kind decision 1 spent the night preventing. It is refused, by the same test applied to the agents: every position must improve, and better on one axis while worse on another is a trade, not a repair.
Where no pre-built remediator exists, a model writes the change and a second, deliberately different model replays the original attack against it and reports what survived. If the model that wrote the fix is the model that verified it, the result is discarded even when the replay passed. A repair agent is itself an agent holding broad authority, triggered by events an attacker may influence, and it does not get an exemption from the rules the other agents are under.
6. Where healing stops — because the evidence matters more
By morning it is clear that enough records were exposed for long enough that a disclosure threshold has been crossed. The automated repair is halted deliberately, and memory, logs and configuration are frozen as found — because a platform that keeps restoring known-good state is quietly destroying the record the notification deadline will require.
That is only an affordable decision because of what happened at 02:40. You can leave something broken for three days precisely because nothing can reach it any more. Withdrawing authority is what buys the right to stop repairing, which is the clearest statement of how the two halves depend on each other: the fast one bounds the damage, the slow one is then free to be done properly.
Each decision was recorded before the thing it authorised, and sealed so the record cannot later be adjusted to match how the night turned out. A log written afterwards is a description of events by the party with the strongest interest in how they are described. And in each case the decision, the change and the evidence succeed together or not at all — there is no outcome where authority was narrowed but nothing recorded it, or where a repair half-applied and left no trail.
Why this is a different product from the one you already own
Read those six back and notice what four of them are not about. Decisions 1 to 4 never mention a resource, a configuration or a rollback. They are decisions about what an autonomous system was permitted to do, made while it was working. No remediation platform makes those, because that is not what remediation platforms are for — and no identity platform makes them either, because identity answers the question once, at the start, and then stops asking.
What identity answers
Who is this, what role does it have, was the access approved, and by whom. Answered once, at the start of the session. All real, all necessary.
What nothing currently answers
Is this combination safe? Is it still safe now that the agent has read what it has read? A weakness was found forty minutes in — how long until every agent holding it is narrowed? And can you prove any of that to someone who does not trust you?
The second column is where the risk in agentic systems actually sits, and today it is nobody’s product. Identity stops asking after issuance. Monitoring watches and reports but cannot narrow anything. Remediation repairs the resource and never touches the reach. Each is doing its job correctly; the gap between them is structural, and it is the gap an agent lives in.
What changes for the people who run this
| Question | Self-healing alone | With authority containment |
|---|---|---|
| How long was the exposure open? | As long as the repair took | As long as propagation took |
| What could reach it during that time? | Reconstructed from logs, if at all | Recorded: which credentials held it, contracted when |
| Did the fix make anything else unsafe? | Not evaluated | Re-evaluated at reissue |
| What constrains the remediating agent? | Usually a standing privileged role | Task-scoped authority, verified before issuance |
| Can you prove the sequence to an auditor? | Application logs | Hash-chained ledger in a transparency log |
What breaks when this runs at scale
A self-healing loop that works on ten findings a week is a different system from one running against several thousand a night across an estate nobody fully owns. Most automated remediation programmes are not abandoned because they failed. They are abandoned because they succeeded loudly enough, often enough, in the wrong places, that somebody eventually turned them off. Three things cause that, and all three are scale problems rather than technology problems.
Severity is the wrong queue. Rank four thousand findings by severity and you get a list ordered by how bad each one is in isolation. Nothing in that ordering knows which of them an attacker could actually use to reach something that matters. Working the list top-down means spending the automation budget on criticals that lead nowhere while the medium sitting on the only route to the customer database waits its turn. Ranking by reachability instead — what does closing this actually cut off — usually reduces the urgent set by two orders of magnitude, and the surviving items are the ones you would have chosen by hand if you had had time to look.
Individually reasonable trades accumulate. Over a year of thousands of automated changes, a system that accepts any fix improving security will eventually accept a great many that quietly cost something elsewhere — a data-protection position, an evidence trail, a retention guarantee. Nobody ever decides to get worse. Estates get worse by accepting defensible exchanges one at a time. The only thing that prevents it is a rule that posture may move in one direction only, enforced on every change rather than reviewed quarterly.
Nobody can prove the automation was right. This is the one that actually kills programmes. After the second or third occasion on which an automated repair coincided with an outage, someone senior asks what the system has been doing, and the honest answer is assembled from application logs after the fact. At that point the automation is switched to advisory mode “until we have confidence”, and it never comes back. A record written before each change, sealed so it cannot be revised to match the outcome, is what keeps the automation running in year three.
The scale test worth applying to any remediation platform, including ours. Not “how many findings can it close” — that number is easy and it is the wrong number. Ask instead: of the last thousand changes it made, how many did it decline to make, and can it tell you why for each one? A platform that never refuses is not being careful at scale. It is being lucky at scale.
You revoked it. Did anything actually stop?
Revocation is usually local. You remove the permission in one system and consider the matter closed. Meanwhile a session already open somewhere else carries on until it happens to expire, because nothing told it to stop.
Most organisations discover this during an incident, at the worst moment, when someone asks how long the agent kept working after access was pulled and the honest answer is “until the token ran out”.
When authority is contracted here, a signal goes out across the trust boundary to the identity provider and to the other systems that issued sessions off the back of it, so termination is coordinated rather than hoped for.
After you revoke an agent’s access, how long until every system agrees it is revoked? If the answer is “at the next token refresh”, that interval is your real exposure window — and it is probably measured in hours, not seconds.
When one agent hands work to another
Agents delegate. A coordinating agent breaks a task into parts and hands them to others, each of which may hand work on again. This is how the useful ones are built, and it creates a problem that single-agent thinking misses entirely.
Pull authority from the coordinator and the work it has already delegated carries on. You have revoked the manager and left the subcontractors running — with authority the manager gave them, on a task the manager is no longer permitted to pursue.
Authority granted downward has to be withdrawn downward. Revoking at the top collapses the whole chain beneath it, rather than leaving orphaned workers holding permissions nobody is now accountable for.
Proving it to someone who does not trust you
Eventually somebody outside your organisation asks you to demonstrate this rather than describe it. A customer’s security team. A regulator. A partner whose data you are processing. An acquirer’s diligence team.
The usual difficulty is that a real answer means exposing things you would rather not: your threat model, your data classification scheme, the internal structure of your controls. Most organisations end up sending a completed questionnaire and a policy document, which is an assertion rather than evidence.
The alternative is a claim the counterparty can check independently — verifying that the authority granted satisfied the safety condition, without being shown the classification scheme or the threat model that produced it. They get proof; you keep your internals.
For anyone who has spent a quarter answering a large customer’s security review, that distinction has a very direct commercial value.
The system missing from your AI register
Most organisations now maintain an inventory of AI systems, because a regulator or a board asked for one. Look down it and you will find the customer-facing assistants, the document classifiers, the fraud models, the forecasting tools. Each has an owner, an approved use, a monitoring regime.
The remediation agent is almost never on that list.
It was built by the platform team, it was procured as infrastructure automation, and nobody thought of it as AI — even after the point at which it started using a model to decide what the fix should be. So the one automated system in the estate with standing privileged write access to production, acting without a human in the loop, on triggers an attacker may be able to influence, is governed as a piece of tooling rather than as a high-impact automated decision-maker.
Worth testing before someone external tests it for you. Take your AI inventory and your list of systems with production write access, and look at the intersection. If the remediation platform appears on the second list and not the first, the gap is not a documentation problem — it means the controls your governance function believes apply to automated decision-making are not applied to the system that makes the most consequential ones.
The regimes now arriving care about this distinction. Broadly, they ask organisations to identify automated systems whose decisions carry material consequence, to keep records adequate to reconstruct what those systems did and why, and to demonstrate that meaningful control was exercised rather than asserted. A remediation agent that changes production configuration meets the first test comfortably. Whether it meets the second and third is a question of whether the record was written before the change and sealed against revision — which is an engineering decision made long before the governance conversation happens.
The honest caveats
Same rule as the first article: a control described only by its benefits is being sold rather than explained.
Contraction can interrupt legitimate work. An agent mid-task that loses a capability may not complete as intended. Graduated tiers exist precisely to make this survivable — contract before reissue, reissue before quarantine — but there is a real trade-off between containment speed and task completion, and where you set it is a business decision, not a technical default.
It inherits the quality of your detectors. Contraction is driven by detections. A weak detector set means late contraction. A noisy one means agents losing capabilities they should have kept. Neither problem is solved by this layer; both are made more visible by it.
It is not a substitute for fixing things. Containing authority buys time. If the underlying weakness is never repaired, you have an agent permanently operating with reduced capability and a problem that is still there. The loop has step 3 in it for a reason.
Attestation proves sequence, not judgement. A hash-chained ledger proves the record was not altered. It does not prove the decision was correct. It moves the argument from “can we trust this log” to “was this the right call”, which is a better argument to be having, but it is not the same as being right.
Where this leaves the operating model
Most security programmes today treat remediation and access control as separate disciplines, run by separate teams, on separate tooling. That separation was defensible when both moved at human speed and the principals were people with stable roles.
Agents dissolve it. The principal is created for a task and destroyed after it, holds a combination of capabilities nobody reviewed as a set, acts faster than a review cycle, and — in the remediation case — is itself the most privileged thing in the estate.
Detection without the ability to contract authority produces alerts nobody can act on quickly enough. Authority control without detection produces static permissions that were correct the day they were issued. The two only work as one loop.
The practical starting point is unglamorous and costs nothing: take your last three automated remediations and ask, for each, what could reach the affected resource while it was broken, and whether that access is still live. If the answer requires an investigation rather than a query, that is the gap.