Link copied
BlogDisposition the Fleet, Not the Alert
AI Governance

Disposition the Fleet, Not the Alert

KG
Teh Kim GuanACMA · CGMA
2026-06-26 · 6 min read
Disposition the Fleet, Not the Alert

Premise: A security scan that hands you eighty-five "high" findings has not reduced your risk. It has converted one big unknown into eighty-five small decisions, and if you treat each one as a fresh investigation you will never finish. The work is not finding the risks. The work is dispositioning them in a single sitting.

I run a growing fleet of autonomous agents. Scheduled jobs, skills with file-write permission, agents that touch live config and external services. Sometime this month the honest question stopped being "is each one safe" and became "do I even know how many there are and what they can reach." So I built a register: every agentic asset, what it can do, where it runs, and a risk tier. The first pass found four hundred and sixty-six assets. Eighty-five came back rated high.

Eighty-five high-risk findings is the moment most governance efforts die. Here is what I did instead, and why the method matters more than the scan.

The alert is the start of the work, not the end

A scanner's job ends when it produces a list. Yours begins there, and the failure mode is universal: you open finding number one, start investigating it properly, go deep, resolve it well, and look up to find eighty-four still waiting and your afternoon gone. At that rate the register is stale before it is reviewed. Worse, an un-dispositioned high-risk list is its own liability. You now have written proof that you knew about eighty-five risks and acted on none, which is a strictly worse position than not having scanned at all.

A risk register you have read but not dispositioned is a documented backlog of known, unaddressed exposure. Scanning without dispositioning manufactures liability.

Anyone who has sat through an internal audit closing meeting knows this shape. The audit report with forty findings does not reduce the firm's exposure. The management responses, each finding assigned a fix, an owner, or a written acceptance, are what reduce it. The scan is the fieldwork. The disposition is the closing meeting.

So the discipline I hold is: a high-risk list gets fully dispositioned in the same session it is produced. Not fully fixed. Fully decided. Every item leaves the session with a verdict, even if the verdict is "accept and move on."

Four verdicts, not one investigation

Diagram showing 85 findings sorted into four verdict buckets: remediate, accept, route, and accept as class.

The trick that makes same-session disposition possible is refusing to investigate. You do not need to study an item to decide what kind of thing it is. Eighty-five findings do not need eighty-five investigations, they need eighty-five sortings into four buckets:

A. Remediate. This is genuinely wrong and I will fix it. Goes to a work queue with an owner.

B. Accept. This is flagged but correct for my context. The risk is real, understood, and I am choosing to carry it. Recorded as an explicit decision, not an oversight.

C. Route. This is real but belongs to someone or something else: a different owner, a different layer, a scheduled hardening pass. Hand it off cleanly.

D. Accept as class. A whole category of findings that are all the same shape and all acceptable for the same reason. Disposition the category once, not each member.

Bucket D is what turns an impossible afternoon into a one-hour one. Of my eighty-five high findings, sixty were the same class: a particular kind of skill that the scanner rates high by default because of what it could do, all acceptable for the same single reason. I did not make sixty decisions. I made one decision about sixty things. That is the difference between a method that scales and a method that drowns.

The arithmetic of my actual session: nineteen to remediate, three accepted outright, three routed to a dedicated hardening pass, sixty accepted as a class. Eighty-five findings, four real decisions, one sitting.

Accept is a verdict, and it must be written down

The bucket people skip is B, accept. It feels like doing nothing, so it gets left as an open item, which means it shows up again on the next scan, gets re-investigated, and re-consumes the time you thought you saved. An accepted risk that is not recorded as accepted is indistinguishable from a risk you missed.

So acceptance is a first-class verdict with a written reason. "This server is flagged for running unpinned, accepted because it is internal, single-tenant, and on a trusted host, revisit if it gains external exposure." That sentence does three jobs: it closes the item, it survives the next scan as a known decision rather than a new alert, and if the context changes (it gains external exposure) it carries its own re-open trigger. An accept with a trigger is not negligence. It is a decision with an expiry.

The opposite of remediate is not ignore. It is accept, in writing, with the reason and the condition that would reverse it. Anything less leaves the item to be rediscovered as if new.

Remediate in a batch, with a rollback, same session

For the nineteen genuine fixes I did not open nineteen tickets to handle next week. Where the remediation was mechanical and uniform (the same kind of repointing across nineteen agents), I did it as one batch operation in the same session: snapshot the current state for rollback, apply the change across all nineteen, read it back to confirm, then re-run the register to verify the count of high findings dropped by exactly nineteen. The verification is the part people skip and the part that matters: a remediation you have not re-scanned is a remediation you are taking on faith.

Batching only works when the fix is uniform. Nineteen identical repoints, yes. Nineteen different bespoke fixes, no, those become a real work queue with real owners. Part of dispositioning is recognising which of your remediate-bucket items are a batch and which are a backlog. Mixing them is how a one-hour session turns into a one-week one.

The shape of the rule

This is not really about agents or security scanning. It is about what to do the moment any system hands you a long list of things that each look like they need your attention. If you run a fleet of autonomous loops, as I have described in what running fifty-odd agents taught me about the verifier, this moment arrives on a schedule.

  1. Disposition in one sitting. Decide, do not investigate. A verdict per item, where the verdict can be "accept." The list does not get to span days.
  2. Sort into kinds before you act. Most long lists collapse into a few classes. Find the class, disposition the class once. Eighty-five findings, four decisions.
  3. Acceptance is written, with a reason and a reversal condition. An unrecorded accept is a rediscovered alert. A recorded one survives the next scan and carries its own trip-wire.
  4. Batch the uniform fixes now, queue the bespoke ones with owners. Snapshot, apply, read back, re-scan to confirm the number moved. Know which of your fixes is a batch and which is a backlog.

The scan that found eighty-five high-risk assets did not lower my risk by one point. The hour I spent dispositioning all eighty-five, nineteen fixed and verified, sixty-six accepted in writing with reasons, is what lowered it. The list was the easy part. A machine made the list. The verdicts are the work, and the verdicts are the part that does not scale unless you refuse, item by item, to investigate when all you needed to do was decide.

Part of the Operating Principles series from KG Consultancy.

About the Author
KG
Teh Kim Guan
Product Consultant · General Manager, PEPS Ventures

Strategy and technology are the same decision. Over 15 years in fintech (CTOS, D&B), prop-tech (PropertyGuru DataSense), and digital startups, I have built frameworks that help founders and executives make both moves at once. Based in Kuala Lumpur.

More from the blog
AI Governance
Silence Is Not Consent
An AI agent asked permission, got no answer, and invented the approval it needed. The governance fix: build the gate so silence blocks, for agents and for people.
2026-07-10 · 6 min read
AI Workflow
AI Gives You Plausible Defaults, Not Correct Answers
Capable AI fails by producing fluent, confident output that is wrong against your specific data. The verification layer is not overhead. It is the job.
2026-06-28 · 6 min read
AI Workflow
Loop Engineering: What Running Fifty-Odd Agents Taught Me About the Verifier
I ran fifty-odd autonomous agents before I had a name for it. The hard part was never the work. It was the verifier, and finance solved it a century ago.
2026-06-24 · 10 min read
Work with KG

Working on a 0→1 product?

I help founders and operators go from idea to validated product. Let's talk about yours.

Get in touch →