Short answer
#Forty items and no order
After the first serious conversation about agent security, a team ends up with a list. I have seen many of these lists, and they resemble one another. There are forty items on it, from remove the shared key from the configuration to introduce behaviour monitoring for agents. Every item is marked high priority, because a low priority on a list like this looks irresponsible.
A quarter later the picture is usually this. Six items are done, and they are the six that were more interesting to do. One engineer spent a month choosing a tool gateway. The shared administrative key is still in the configuration, because replacing it is dull and touches everything. When a manager asks whether we are safer now, there is no honest answer. What was done does not add up to any state that has a name.
This is not laziness and not a shortage of people. The list has no sequence and no criterion of being finished. It is unclear what comes first, and it is unclear when you may stop.
#Why levels at all
A maturity model answers exactly those two questions. It arranges the measures in rungs so that every rung rests on the one below. And it gives every rung a name, so that you can say this is where we stand and that is where we do not need to go.
The order matters because upper-level measures do not work without the lower ones. Behaviour monitoring is useless while agents share one key: the log shows that a service deleted something and does not show which of seven agents it was. A shared gateway with policies achieves little while the tools can still be called around it with an old token. Money spent at the top over a leaky bottom buys a feeling, not protection.
Having no order is expensive, and the bill grows. Every month a new agent or a new tool is added. While the baseline is open, every new agent inherits the shared key and the missing caps. A year on there is not one agent to fix but twelve, and each already has users who are used to it being able to do anything.
#Five levels
- Maturity level
- A state of an agent system in which a defined set of protective measures acts at the moment of execution and can be shown to a reviewer on the live system.
- In plain terms A set of limits that already work by themselves, without hoping that the model and the people are careful.
-
Level 0. Experiment
The agent runs from a developer laptop or a test server on a broad key. No caps, no log, and the rules are written in the instructions to the model. For a prototype on made-up data this is a normal state.
One thing makes it dangerous: real data. Level 0 with the production database is no longer an experiment. It is an incident that has no date yet.
-
Level 1. Baseline
Every agent has its own credentials, with permissions for its own workflow only. Secrets live on the server and never reach the text given to the model. There are caps on volume and amount, an action log, and approval by a person for the irreversible.
This is the minimum for any system with real users. It needs no purchases and is closed in weeks.
-
Level 2. Managed
The agent has an identity of its own, and each of its actions can be told apart from those of people and of other agents. Policies are written down explicitly, live outside the prompt and are checked where the action is executed. Code and files from outside run in a sandbox. Outbound connections are allowed by list. Changes to tools and instructions go through review.
The move here happens when an agent starts writing to important systems, executing foreign code or working with sensitive data.
-
Level 3. Platform
A shared layer for many agents and teams: an agent registry, a catalogue of approved tools, one gateway that applies the policies, a common identity, central control of what leaves, and a kill switch.
Justified when agents number in the tens and teams have started rewriting the same thing. For one agent it is expensive excess.
-
Level 4. Measured resilience
The defence is attacked regularly by its owners: bypass tests, incident exercises, observation of agent behaviour. There are numbers somebody watches: time to detection, time to stop an agent, the share of actions that went through the gateway. An agent has a formal life cycle, from request to retirement.
Needed where agents have become critical infrastructure. Most companies do not need it, and that is fine.
Every step stands on the one before. The dashed arc is drawn the way this site draws everything not established: a jump across three levels exists only on a slide.
#What proves a level
A level cannot be declared. It can only be shown. The main rule of assessment is simple: what counts is what a limit does at the moment of execution. What is written in a procedure does not count. A document saying agents may not delete data is worth nothing while the agent holds the right to delete.
| Level | Evidence | The usual gap |
|---|---|---|
| 1. Baseline | The list of agent keys with the permissions of each. A log entry for any action taken yesterday. An attempt to exceed a cap that was refused. | The old shared key was never revoked and sits in the configuration, just in case. |
| 2. Managed | Policies in the repository, with tests. Denial records in the log. An attempt to connect to an address off the list that did not go through. | The policy is checked in one service, and the same tool is reachable from a second one with no check. |
| 3. Platform | The registry matches reality: no agent is on the network that is not in the registry. The kill switch has been tried, and the time to stop is known. | A team in a hurry connected an agent around the gateway, and three people know. |
| 4. Measured | Six months of numbers, exercise reports, closed findings with dates. | The metrics are collected, nobody looks at them and nothing is decided from them. |
Look at the right-hand column. At every level the usual gap is of one kind: a way around, left over from the level below. So an assessment starts with how could this be done past the defence, and not with which defences do we have.
#What triggers a move up
Three quantities trigger a move to the next level: the number of agents, the sensitivity of the data, and the size of the damage from one mistake. The calendar and fashion do not. While all three are small there is no reason to climb above the baseline.
An analytics agent that answers questions about a database and writes its own SQL makes a good example. At the baseline it has a separate read-only database user, and that is enough while it reads the orders table of a small shop. Then tables with personal data are opened to it. Sensitivity went up, and plain read-only stopped being enough: the right to read does not prevent exporting a whole table in one query. That is the trigger for this agent to move to level two. It gets a separate replica in place of the production database, a ceiling on rows and on query time, and prepared statements with parameters in place of concatenated strings. Schema changes and writes are forbidden in the database permissions. A sentence in the instructions will not do for that.
Is it time to build a platform layer
Two answers of yes are a reason to start designing. None means a platform would, for now, cost more than it protects.
- Are there more than ten agents, with different owners? Below that, a registry fits into one table kept by one person.
- Has token handling and logging already been written a third time, by a third team? Three copies drift apart. A shared layer is cheaper than maintaining them.
- Can you stop every agent at once within a minute? If not, and there are many agents, a kill switch pays for itself at the first incident.
- Do you know the full list of outside addresses your agents send data to? Without central control of what leaves, that list is gathered by asking around, and it is always incomplete.
- Do teams connect third-party tool servers without a shared sign-off? A catalogue of approved tools is needed at the moment one person stops knowing them all.
#A level belongs to an agent, not to a company
The most common mistake in applying the model is one target for everybody. The whole company at level three by the end of the year sounds like a plan and is not one. Agents differ in their blast radius, and their targets should differ too.
An agent that drafts posts from public material can live at the baseline for years, and that is the right decision. An agent that moves money belongs at level two from its first day, even if it is the only agent in the company. For a coding agent with access to a repository and a terminal, level two is the starting point as well: a separate environment, no production secrets, writes to a separate branch only.
In practice this is a one-page table: the agent, the worst it can break, its current level, its target level, the next step. There are usually three or four rows with a gap between current and target. That is your real list of work, and it already has an order: the rows with the most expensive worst case come first.
#A startup and an enterprise gateway
A fintech startup has one internal agent. It reads customer applications and prepares draft decisions for an employee. A new technical lead arrives from a large company and brings the familiar design: a tool gateway, a policy service, an agent registry. The estimate that comes with it is six months of work for two engineers.
An assessment by levels takes one evening and shows something else. The agent stands at level zero. It runs on an administrative token inherited from the prototype. There are no caps. The log is written to the very service the agent controls. Three things are missing for level one: a narrow token, caps and an independent log. That is three weeks of work for one person.
Six months of gateway would have solved a level-three problem for a company with level one still open. For all of those six months the agent would have kept running on an administrative token.
The opposite case is rarer and does happen. A company has fifteen agents across four teams, each honestly brought to level one, and every team has written its own token storage and its own log. Here the next step is precisely the shared layer. To go on polishing each agent separately is to pay four times for the same thing.
#How a maturity model gets spoiled
Ticks with no enforcement: the maturity sheet says policies exist because a document was written, and nothing is checked when a tool is called.
Instead Count only what can be shown as a refusal. Ask for a forbidden action to be carried out on a test stand and watch what happens. If the action went through, the level is not there, however many documents sit beside it.
A level for the sake of status: level three by the audit turns the model into a race for a line in a report.
Instead State the target as damage: no agent can export more than a thousand records in one request. The level becomes a consequence, not a goal, and the temptation to draw it in goes away.
One target for every agent: a harmless agent is dragged to level three while a dangerous one waits its turn at level zero.
Instead Set the target for each agent from its worst case. Sort the combined list by the price of a mistake, not alphabetically and not by how loud the owning team is.
#Speed of growing up, and the return
Every level has a price, and the price grows faster than the benefit. Level one costs weeks and removes the largest damage. Level two costs months and adds friction: a sandbox slows the agent down, the list of allowed addresses breaks with every new integration, reviewing instructions lengthens a release. Level three is a permanent team that maintains the platform. Level four is people whose job is to break their own defence.
So growing up faster than the risk grows does not pay. A platform built for growth serves three agents for two years and is out of date before the fourth appears. Falling behind has a price too. A company with thirty agents at level one pays it every day: in duplication, in rules that disagree, and in taking a week to answer what is actually running here.
A reasonable pace is one step up when a trigger has fired, and a stop where the next step costs more than the damage it removes. The stop is worth writing down with its reason, so that a year later it can be reviewed by the same logic.
#Where we stand on this scale
It is only fair to hold the scale against ourselves. 1ADK has one type of agent: it reads a customer system and returns structured findings with evidence. Our worst case is an agent that did something other than read on a customer machine, or brought us something it should not bring.
So the baseline is closed in full. A job is limited to reading, runs nothing, expires, and no secrets end up in the result. 1ADK does not require access to your repository and does not require you to upload source code to the service. From level two we took what answers our worst case. The rules of a job are written as a contract outside the prompt. Both sides execute it, and it is covered by shared tests. The text of a repository is treated as data, not as instructions. A submitted result goes through independent verification before it reaches the knowledge store.
We have no level three, and we are not building one. An agent registry and a shared gateway solve the problem of many agents and many teams, and we do not have that problem yet. This is a recorded decision with a condition for review, not a gap somebody forgot.
#What a level does not promise
What this does not do
- A high level does not mean no incidents. It means the damage from an incident is bounded and that it will be noticed. Nobody has proven a direct link between the number of a level and the number of incidents.
- The model does not replace the analysis of specific threats. It says in what order to build a defence, and it does not say whom you are defending against.
- A level does not carry over between agents. A level-three platform does not lift an agent that was connected around it.
- The borders between levels are a convention. A level-two measure may be needed at level one if your worst case demands it. The model sets a default order, not a prohibition.
- An assessment goes stale. A level proven six months ago describes a system that no longer exists.
Write your agents in a column and give each a level by evidence, not by feeling. Which of them has the widest gap between what it can break and the level it stands on?