ComplianceAI MissionsEnterprise SecurityupgradedEnterprise Autonomy

An AI Mission for Compliance: Continuous, Auditable Controls

PG
Patrick Gilberg · Head of Accounts
May 27, 2025

A control tested once a quarter is a control you are guessing about for eighty-nine days at a time. The interval was never a judgement about risk — it was a judgement about what looking cost.

A week before the quarterly test, a control owner opens the privileged-access list for the first time in three months. Two of the accounts belong to people who left the company — one in the first weeks after the last review, one more recently — and a third belongs to a contractor whose engagement ended somewhere in between. None of this is surprising and none of it is scandalous; it is the ordinary residue of an organisation where people join teams, change roles, and leave, and where the systems that record those events do not talk to the systems that grant access. The accounts are removed, the tickets are written, the owner notes the remediation honestly, and when the test runs four days later against a list pulled that morning, it comes back clean. Nothing improper has happened. The accounts genuinely should not have existed, and now genuinely do not.

What the record captures, though, is the state of the system on one prepared morning. It does not capture the eleven weeks in which those accounts sat there with live credentials, because nothing was looking during those eleven weeks and nothing was designed to. And the quietly remarkable thing about this scene — the thing that makes it worth dwelling on rather than fixing with a stern memo — is that everybody involved understands it perfectly well. The control owner knows the list had not been examined since the last cycle. The tester knows the extract is same-day. Management knows that "reviewed quarterly" describes a rhythm of inspection rather than a state of the world. Nobody is being deceived, which is precisely why the arrangement is so stable: it is not a lie, it is a convention, and conventions survive because everyone has adapted to them.

Ninety days was a price, not a finding

It is worth asking where the quarter actually came from, because it did not come from anyone studying how quickly access drifts, or how long a misconfiguration typically survives, or how much exposure accumulates in a month versus three. It came from what it cost to look. A test of this kind has historically meant a person pulling an extract, reconciling it by hand against a second system that stores names differently, chasing managers for explanations of the entries that do not reconcile, waiting on replies, and writing the whole thing up in a form that will survive scrutiny later. That labour is the real determinant of the cadence. A quarter is roughly the shortest interval at which an exercise of that weight can be repeated without consuming the function performing it, and the pattern holds across the whole control environment: the expensive tests are annual, the cheap ones are monthly, and the middle is quarterly. The frequency tracks the effort of testing far more faithfully than it tracks the volatility of the thing being tested.

Once that is said plainly it becomes difficult to unsee, because risks do not have a quarterly rhythm. An offboarding failure exists from the hour the person walks out, not from the date of the next review. A permission granted for a one-week project is wrong on the eighth day. A rule that was changed in a hurry is wrong the moment it takes effect. The exposure is continuous and the measurement is periodic, and the periodicity was set by a labour budget that most organisations have long since stopped questioning — in many cases stopped remembering they ever set. This is why moving the test dates around so rarely changes anything real. Shifting a review from March to February redistributes the guessing without reducing it, and adding a second annual cycle halves an interval that was arbitrary to begin with.

What the interval was doing for everyone

The interval does more than hide problems, and this is the part that explains why continuous testing meets resistance from people who are neither lazy nor acting in bad faith. The interval distributes a kind of comfort. For the control owner, it creates a window in which the state of the system is not anybody's stated knowledge, and the difference between "I did not know" and "I knew and had not yet acted" is the entire difference between an operational gap and a decision someone made. Periodic testing keeps most of the year in the first category. For the people who describe the control upward, the interval permits the present tense — access is reviewed, changes are approved — a grammar that describes a design rather than the last ninety days of behaviour. For the function that runs the programme, it makes the workload finite and schedulable, which is the only reason the work fits in the calendar at all.

So when someone proposes making a test continuous, the instinct that this is a bigger change than it sounds is entirely correct. Continuous testing does not make an organisation more compliant on the day it is switched on; the same accounts are open, the same approvals are missing, the same rule is misconfigured. What it does is make the organisation informed, and information carries obligations that ignorance does not. A gap that used to exist unobserved now exists observed — timestamped, attributable, and durable in a way that a remediated finding never was. The first cycle after the change almost always produces more findings than the last cycle before it, and the temptation in that moment is to treat the increase as a fault in the instrument rather than as the first accurate picture anyone has had. It is not a fault in the instrument. The gaps were always there; what changed is that something was in the room while they happened. It hardly needs saying, but it is worth saying anyway: the answer to that discomfort is never to shape the record so that a control appears to have operated during a period when it did not. The entire value of continuous testing is that the record finally describes what actually occurred, and an organisation that trades that away has bought the cost of the change without the only benefit it offers.

Continuous is a mission, not a dashboard

The practical obstacle has always been that "test it continuously" is easy to say and expensive to mean. A dashboard does not solve it, because a dashboard relocates the labour rather than removing it — it produces a screen that someone must be looking at, which reintroduces the same human-availability constraint that set the quarterly cadence in the first place, only now at higher frequency and with more noise. What the work actually requires is something that pulls the population from the system of record itself rather than waiting for an extract, evaluates each item against what the control was written to ensure, distinguishes an entry that looks anomalous but is explained by a documented exception from one that is genuinely unaccounted for, gathers the surrounding context before anyone is asked a question, and escalates the residue to the person accountable for it with the reasoning attached.

That shape — a standing objective rather than a scheduled task — is what an AI Mission is for. Instead of a control test that begins on a date and ends in a report, a mission runs against the environment continuously, with specialist agents covering the domains a programme actually spans, connected through Model Context Protocol to the identity, ticketing, and configuration systems that hold the truth, accumulating observations that make a control's behaviour legible over time rather than at a point. The judgement does not go anywhere: whether an exception is legitimate, whether a compensating control is adequate, whether an account belonging to a senior executive gets disabled at four in the afternoon — these remain human-in-the-loop decisions, and they should. What stops being rationed is the looking. This is the same reallocation of connective labour that the publications tracking the shift toward the autonomous enterprise have been describing across operations and engineering, arriving in a domain that has been paying for it in ninety-day increments longer than most.

The mental model worth carrying out of this is that a control is not a thing that passes or fails. A control is a thing that runs, and anything that runs has an uptime — periods when it was operating as intended, and periods when it was not, each with a beginning, an end, and a duration. Quarterly testing could only ever answer a yes-or-no question about a single prepared morning, and the honest translation of a clean result was always "we looked once and it was fine when we looked." Continuous testing answers a different question entirely: for what proportion of the period was this actually true, where were the gaps, and how long did each one last. That number was always real; every organisation has had it, and none of them could afford to know it. What changes when the looking becomes cheap is not that the number improves but that it becomes sayable — and an organisation that can say it has traded a comfortable ambiguity for something considerably less comfortable and considerably more useful, which is a measurement with a shape, arriving where an assumption used to live.

Discussion

No comments yet — start the conversation.

Join the discussion

See StudioX run.

Put autonomous AI workers to work on your own systems and knowledge.