Agents are the last step, not the first

Most product pitches we have seen this year have the agent slide. An AI that takes over tasks, closes tickets, implements measures, works incidents. It is the slide where everyone in the room sits up, and it is the slide that gets shown first.

That is the wrong order. It makes the most expensive step the first one.

Why acting is the most expensive place to start

An agent that acts needs three things before it takes work off anyone: a dependable data base, an approval path, and somebody who carries the responsibility. If one of them is missing, it moves work around instead of doing it.

The data base. An agent working on an incomplete register multiplies the gap. If the asset inventory does not know half the systems, it closes measures for one half and reports completion. The error is harder to find afterwards than it was before, because it now looks like finished work.

An example. An agent is told to follow up the logging check on all servers. It reads the asset register, finds eighty systems, works through them and reports eighty completed checks. The organisation runs a hundred and ten. The missing thirty were never in the register, because they came from an acquisition and were never recorded. Before, that was a known gap. Now it is a green report about eighty systems, and nobody goes looking any more.

The approval path. As soon as an agent may act, every action with consequences needs an approval, either one by one or as a mandate granted in advance that somebody answers for. The load lands back on the same two people who were overloaded before. Production was automated, the bottleneck stands untouched behind it.

The responsibility. When an agent marks a measure as implemented and the audit later finds otherwise, the question is not technical. It is who made that claim.

None of these three problems dissolves because the model gets better.

The order that takes work away

AI can do three things in an ISMS: derive, ask, act. The three build on each other. Each step requires what the previous one delivers, and none replaces it: whoever later lets agents act keeps deriving and keeps asking. They differ in how much trust they require and how much work they save.

Derive

The least spectacular and the most effective. Documents and organisational details go in. Out of them come the objects of an ISMS: systems, suppliers, risks, measures, the binding to the requirements of the catalogue, and finally policies.

This runs in six stages, and the order is compulsory because each stands on the result of the one before. A scanned contract becomes readable text first, then objects. Risks attach to the objects, measures to the risks, the measures are bound to requirements. Only at the end does a policy text appear. Enter in the middle and you have lost the connection to your own organisation, which is exactly what happens with off-the-shelf template policies.

This step comes first because its trust threshold is low. Every stage produces proposals. A human accepts them, individually or per stage, and rejects what does not fit. Without acceptance nothing enters the register. Whoever chooses automatic adoption when starting a run accepts every proposal of that run under their own name.

That makes the three problems above manageable. The data base is only now coming into existence. The approval path is the acceptance step itself. And the responsibility sits clearly with whoever accepted.

It is also the step that attacks the largest single line item in an ISMS project, namely the assessment of the current state.

Ask

The second step presupposes a reliable register, of the kind the first step delivers. An answering system without a data base is a chat with opinions.

With the base in place, something shifts in daily work. "How many open measures does the northern site have past their deadline?" becomes answerable without anyone building a report. On our side this part is called OdySecure Navigator, it is live, and it works over a fixed set of server-side checked queries, currently 34.

The value of such a system lies in what it refuses. Its data queries answer only within the read rights of the person asking. And it separates two cases that often collapse into one: no data and no read right. Merging those two into an empty answer produces precisely the kind of non-statement that later gets used as evidence.

A figure that comes from a reviewed query and carries its source is a different object from a figure a model assembles out of a context window. In an audit only the first one counts.

Act

Only here do the agents arrive, and only here does the arithmetic work, because the preconditions now exist.

What has to be built for it can be listed. An agent needs its own account with its own roles, so its actions stay distinguishable from a human's. It needs a visible badge, so nobody mistakes an agent action for a colleague's. Proposing stays the default. Allowing an agent to act requires two different authorised people. On top of that hard locks that no approval lifts: no final closure of incidents, no risk acceptance, no self-authorisation. And a kill switch with expiring access keys.

On our side this step is in testing, in our own operation. It is not a generally available feature.

Why everyone starts with agents anyway

The reason is demonstrability.

Deriving looks bad in a demo. You upload a document, wait, and afterwards a list of proposals sits there that somebody has to review. That is the work in question, and it is dull to watch.

An agent that opens a ticket, assigns a measure and writes a response looks like the future in the same ninety seconds. It creates the feeling in the room that somebody has solved a problem.

So the agent slide goes first, and it goes first in most of them. It is the strongest slide in the deck. That says nothing about its usefulness in year one.

There is a second reason. Agents can be bolted onto many existing tools without touching their core. Deriving usually cannot: turning documents into a register needs a data model that separates proposals from accepted entries, provenance per entry, and the name of whoever accepted it. That is a change to the foundation, and whoever does not have it sells the slide they can build.

The order is not an excuse for later

The usual objection is that this is a polite way of saying the agents are not ready. The objection would hold if the first two steps were only preparation. They are not.

Deriving without the later steps can lower the largest item in the build. Asking without acting replaces part of the recurring reports in operations. Anyone who stops at the second step can lower the cost of their ISMS without ever letting an agent perform a single action.

The reverse does not hold. Start with the third step without a checked register and working approvals, and you have an agent working on gaps and an approval path nobody can staff.

What the inverted order costs

For whoever signs off the budget, this can be written as line items.

The largest single item in building an ISMS is the assessment of the current state: recording systems, reviewing suppliers, reading contracts, clarifying accountabilities. It is usually paid for in consulting days or in-house time, and it falls due before a tool can display anything reliable.

Starting with the agents does not remove that item. It moves it forward, because the agent can do nothing without a register, and it gets paid on top of the agent licence. The result is a project in which the most expensive part is still done by people and the most visible part requires a paid licence.

Starting with derivation attacks that item. The assessment still takes effort, yet it shifts from producing to reviewing, and reviewing is usually the cheaper activity. How much that saves depends on how good the documents in the organisation are. We do not quote a figure for it, because we have none that holds for your organisation.

The second item is liability. Somebody has to answer for every action an agent carried out. As long as it is unclear under which account it ran and who approved it, that item stays open.

What to ask a vendor

When the agent slide comes up, four questions are useful.

Where does the register come from that the agent works on? If the answer is an import format, the assessment of the current state is still your problem.

What happens when the agent does not know something? Does it invent, does it ask, or does it record a gap? Only the first answer is unusable.

Under which account does the agent act? If it acts under the operator's account, the log no longer tells the two apart by account. The log is the reason you are buying the tool.

What can the agent not do even with approval? A vendor without a list of hard locks cannot show that they have answered the question.

The sentence that remains

Sovereignty and control are the conditions under which AI is allowed into an ISMS. The benefit arises somewhere else, namely in deriving, and it arises there today.

Anyone who talks only about agents has mixed up the order and is selling the most expensive step first.

The test is simple. Ask what the tool does for you if you allow no agent a single action. If something remains, you are talking about a product. If nothing remains, you are talking about a slide.

Measured against the shipped OdySecure source and the internal product context, as of 10 October 2026. This describes what the platform can do, not a commitment about the availability or scope of any individual installation. Acting by agents is in testing in our own operation and not generally available.