ACD Maturity Model Self-Assessment: ACD 0 to ACD 5, Where Does Your Program Stand?

Ryan Rowcliffe

11 minutes ago

10 min read

Most maturity models are designed to make you feel good. They usually have five levels, everyone typically lands at three, the recommendation is a journey toward four, and the model is quietly constructed so that nobody reads their result and feels alarmed.

SACR's Agentic Control Depth scale is not built that way, and that is the reason to use it. It has six levels and a stated pass mark. ACD 4, inline intervention before the action completes, is named as the minimum operational threshold for agents touching sensitive data or critical workflows.

A pass mark changes what a model is for. You are no longer plotting a journey. You are finding out whether you are above or below a line, and most programs running production agents today are below it.

That should not be read as an indictment. It should be read as arithmetic, because almost everything the scale measures is something the industry has known it should do for fifteen years and chose not to fund. The assessment below will surface your ACD level. It will also surface the list of fundamentals you already knew about, and in my experience the second list is the more useful output.

Compare yourself to the below model. A flattering score here costs you nothing today and quite a lot later.

The six levels, described honestly

Level	SACR definition	What it looks like in a real estate
ACD 0	Ungoverned execution, no visibility	Agents running that nobody registered. Usually discovered during an incident or an audit.
ACD 1	Static discovery and inventory	A spreadsheet or registry listing agents. Accurate on the day it was written.
ACD 2	Post-event telemetry and alerting	Dashboards populate, alerts fire, metrics improve. Nothing touches the action.
ACD 3	Perimeter and deterministic guardrails	Static rules block enumerated bad paths. Catches the obvious and the careless.
ACD 4	Inline intervention before completion	Something in the decision path can say no while the action is happening.
ACD 5	Autonomous self-healing governance	Policy adjusts itself without human approval. Nobody has operationalized this.

Three things worth saying about that table that the levels alone do not convey.

ACD 0 and ACD 1 are closer together than they look. An inventory that is not continuously rebuilt from observed activity decays into ACD 0 within a quarter. In our customer environments roughly 65% of AI and automation identities we surface are unmanaged, and about half were absent from the customer's own inventory before we looked. Those customers were not at ACD 0 on paper. They had registries.

ACD 2 is the comfortable trap. It generates artifacts, which means it survives budget review. Dashboards, alert volumes, quarterly improvement. Against an adversary whose fastest observed breakout is 27 seconds, post-event telemetry is a very well-instrumented way to learn what happened to you.

The ACD 3 to ACD 4 boundary is the only one that changes your risk position. Everything below it changes how well you can describe your risk position afterward. Static guardrails at ACD 3 assume you enumerated the bad paths in advance, which is precisely the assumption agentic systems exist to violate. An agent's value comes from composing steps nobody scripted. Your rules cover the compositions you imagined.

One caution on ACD 5, because I will not oversell a level nobody is running. Autonomous policy adjustment means a system changing your controls without a human approving the change. The audit and rollback story has to exist before the automation does. Treat it as a direction, not a Q4 objective, and ask any vendor selling it what happens when it adjusts the wrong policy at 3 a.m.

Four rules that stop you flattering yourself

Maturity assessments fail for predictable reasons. These four rules prevent most of them, and they are the difference between a number you can act on and a number you can present.

Score production. Not the pilot. The pilot has an engaged team, a clean scope, and someone watching. Production has neither the attention nor the guardrails. If your answer to a question is true of the pilot and not of the estate, the answer is no.

Score per workload, not as one number. A single organizational ACD score averages away the thing you need to know. The finance agent and the internal documentation bot do not belong in the same figure. Score each significant agent workload separately and rank them by what the agent can reach.

Score the weakest link in the chain. ACD is not an average across capabilities, it is a depth measurement. A program with excellent discovery, excellent behavioral analytics, and no inline enforcement is ACD 2. Not ACD 3.5. Depth is determined by how far into the action your controls actually reach, and the answer is set by the last control in the path.

Every yes needs evidence. Not a vendor datasheet, not a configuration that exists, not an intention. A log, a test result, a timestamp. The single most common scoring error I see is a team crediting themselves for a capability that is licensed and deployed but never validated. If you have not seen it work in your environment in the last ninety days, it is a no.

One more that is not a rule but a warning. Do this with the people who run the systems in the room, not just the security team. The security team's mental model of what production does is frequently a quarter out of date, and the honest answer to several of these questions lives with a platform engineer who was not invited.

The assessment

Work through this per agent workload. Each gate must pass completely before you claim the level above it. Stop at the first gate you fail; that is your score.

Gate 1: are you above ACD 0?

You can name every agent with production credentials, including ones deployed by teams outside IT
You know which credential each one presents and what identity it resolves to
Someone owns each agent, by name, and that person still works here

Evidence: a list, generated in the last 30 days, that a platform engineer agrees is complete.

If your list came from a registry rather than from observed activity, discount it. Registries record what was declared. In our customer environments about half the AI and automation identities we surface were not on the inventory at all before we looked.

Gate 2: are you above ACD 1?

Agent activity is continuously collected, not sampled or periodically reviewed
You can reconstruct what a specific agent did over a specific hour, across cloud, SaaS, and on-premises
Tool and API calls are captured, not just authentication events
The inventory rebuilds itself from observed activity rather than from declarations

Evidence: pull a real agent's activity for a random hour last week. Time how long it takes.

That last check is the honest one. If reconstructing one hour takes three consoles and an analyst who knows the joins, your correlation is manual, which means it does not exist at machine speed.

Gate 3: are you above ACD 2?

Deterministic policy constrains what each agent may do, enforced rather than documented
Credentials are scoped to purpose, and you can show an agent being denied something outside its scope
Tool and MCP access is allowlisted per agent
Delegation is explicit: you can state whose authority each agent acts under

Evidence: attempt a prohibited action with a test agent. Watch it fail.

Gate 4: are you above ACD 3? (the pass mark)

A control sits in the decision path and the action waits on its answer
You have measured p99 intervention latency, in milliseconds, under production load
Failure mode is decided and documented per action class: fail-open or fail-closed
Revocation propagates in seconds, not at token expiry
Verbs beyond allow and block work in your environment: redact, scope reduction, step-up, human routing
Behavioral context drives intervention, so enforcement is selective rather than blunt
Multi-hop delegation chains are evaluated at decision time, not reconstructed afterward

Evidence: block a real action in a live environment and read the audit record it produced.

The revocation item fails more assessments than any other, and it is the cheapest to test. Revoke a non-production agent's credential and time how long until it can no longer act. Not until the revocation appears in a log. Until the action fails. If the answer is tens of minutes because you are waiting out a token lifetime, you are at ACD 3 regardless of what else is true.

Gate 5: are you at ACD 5?

You are not. If you believe you are, the questions are whether policy changes autonomously without human approval, whether every autonomous change is auditable and revertible, and what happened the last time it adjusted the wrong policy. Three honest answers usually resolve this.

Reading your score

ACD 0. You have agents you cannot name. This is more common than anyone admits, particularly where business units deployed copilots without going through IT. Do not buy anything yet. Run discovery from observed activity rather than from surveys, because surveys return what people remember deploying. Expect the result to change the conversation, and expect that conversation to reach further up than the security org.

ACD 1. You have a list. Your next move is continuous observation, and specifically correlation across identity types. A real agent chain crosses from a human's delegated authority to an agent to a service account to an assumed cloud role. If those live in separate consoles, you have four partial views and no chain.

ACD 2. You are where most well-run programs sit, and the danger is that it feels like progress because the artifacts are good. Your gap is deterministic policy that is enforced rather than documented. Start with credential scope: take your highest-reach agent and tighten its entitlements to what it has ever actually done. That is an observability output, not a procurement one.

ACD 3. You are one boundary from the pass mark and the boundary is a real engineering commitment, not a license. Pick one high-value action class, put a gate in front of it, measure the latency, document the failure mode. Six weeks of that teaches your organization more than a year of evaluations, and gives you a defensible number for the budget conversation.

ACD 4. Good. Now check three things people at ACD 4 routinely miss. Is coverage uniform, or does one uninstrumented path bypass the gate entirely? Has anyone tested behavior when the policy engine is unreachable? And has an operations team quietly disabled enforcement on a workload after an incident? That last one is a phone call, not a dashboard query.

One pattern worth flagging, because it is the most common result I see. Teams score ACD 2 for human-facing applications and ACD 0 for the agent population nobody registered. Both numbers are correct. The second one is your actual exposure, and averaging them produces a number that describes nothing.

The second list, which matters more

Run this assessment honestly and you will produce two outputs. One is an ACD score. The other is a list of things you already knew, and that list is the more valuable document.

It looks roughly like this every time.

Static secrets sitting in process environments, usually including the service that parses untrusted input. Service accounts with entitlements nobody can justify, because tightening them meant breaking something on a Friday. A shared credential bound to cluster-admin across environments. Signing keys in the same vault as ordinary secrets, when a leaked credential is an incident and a leaked issuer key is a compromised authentication system. Unauthenticated endpoints that execute code, accept uploads, or proxy requests. An NHI population that was never fully enumerated.

None of those are agentic findings. Every one of them is a fundamental that was correct fifteen years ago, is correct now, and has been carrying an accepted-risk sign-off for most of that time.

Here is the part worth being clear-eyed about. Those risk acceptances were not unreasonable given what we could see. They were signed against a compensating control, and the compensating control, whether or not anyone wrote it down, was that exploitation required a human working at human speed and a human at human speed leaves time to notice.

That was always a worse bet than it looked, because the noticing half depended on detection quality we knew was uneven. Agents did not invalidate the fundamentals. They repriced the acceptance, and the new price is 22 seconds from initial access to hand-off and one second to cluster admin.

So when you take the ACD score upstairs, take the second list with it, and frame it accurately. This is not new work created by AI. It is deferred maintenance whose compensating control just expired. That framing tends to survive a budget conversation better than the alternative, because it is true and because the people in the room have been carrying the same list.

And one structural point underneath all of it. The reason the deferred maintenance stayed invisible long enough to feel acceptable is that we never built correlated observability of identity, human and non-human, across the domains identities actually operate in. You cannot price a risk you cannot see, so we priced it at zero. The ACD scale is, read one way, just a measurement of how much of that we finally went and built.

What the score is for

A maturity score is not a grade. It is a shared vocabulary for a conversation you need to have with people outside security.

The conversation is about latency and interruptibility, and it is not a security decision made alone. Every inline control taxes legitimate work. Deciding which action classes run free, which get gated, and which always pause for a human is a business tradeoff, and the business owners need to be in the room when it is made. Doing it at 2 a.m. during an incident produces a policy you will reverse within a week.

So take three artifacts to that meeting. Your ACD score per workload, not averaged. Your deferred maintenance list, framed as an expired compensating control rather than as an AI problem. And one measured number: how long it currently takes, end to end, from an agent's first observable action to anything in your environment stopping it. That third number persuades people the other two cannot reach.

Then pick one action class and put a gate in front of it. Not the estate. One class, measured latency, documented failure mode, six weeks.

AuthMind builds for this problem and I am obviously not neutral about it, so use the assessment without us. Nothing above requires a product to run, and any vendor who needs you to be at ACD 0 to make their case is not a vendor you want.

The question at the end is the same one from the beginning of this series, and it does not need a framework to answer.

When an agent in your environment does something it should not, does anything you own get a vote while it is happening? You already know. The assessment just makes it writable.