5. September 2026 · Cybersecurity
Which Process Steps May Your Agent Trigger?
Agentic AI turns a model question into an authorisation question, and most organisations are still answering the first one
Executive Summary
Strategic context
Situation. Enterprises are moving AI agents out of pilots and into processes that release production orders, reconcile payments and adjust inventory. The security discussion accompanying that move is dominated by model-level concerns: prompt injection, jailbreaks, data leakage into training, model provenance.
Complication. Those are real and they are not the binding constraint. An agent that can release a production order is a process actor with rights. The question that decides its risk is not how hard the model is, but which steps it may trigger, under what threshold, with whose countersignature, and how a wrong decision is caught. Those questions live on a process map. Most organisations only have a system map.
Question. What has to be decided before an agent is given rights in a value-creating process, and who decides it?
Key findings
1. Model hardening and process authorisation are different controls for different failure modes. Hardening addresses an agent doing something it was tricked into. Authorisation addresses an agent doing exactly what it was designed to do, in a case where that was the wrong outcome. So what? A programme that has only done hardening has mitigated the smaller of the two exposures and typically believes it has mitigated both.
2. Four questions decide agent risk, and none is answerable on a system map. Which process steps may the agent alter; which thresholds apply; where does a human countersign; how is a wrong decision detected and rolled back. So what? If your architecture documentation is system-centric, you cannot currently answer the questions that govern your agents, regardless of how good that documentation is.
3. The toolchain supplies the map, not the decision. Checked against vendor documentation rather than vendor marketing: SAP LeanIX documents version clustering, which custom applications run on which standard stacks, and lifecycle data. It does not describe dependency mapping as a named capability, nor direct connectors to security tooling. SAP Signavio describes a four-step risk and control approach and names SOX, Basel and Dodd-Frank among supported frameworks. It does not list named features for linking individual risks to security controls. So what? Buying process modelling or enterprise architecture does not buy agent authorisation. It buys the substrate on which that decision can be made by people.
4. The binding constraint is organisational and cheap to fix. Who decides to halt an agent at 03:00 on a Sunday, and at what threshold? Where this is unresolved, the organisation escalates instead of acting, and escalation during an incident consumes exactly the hours that determine its size. So what? A pre-agreed decision matrix with named roles costs nothing and is routinely absent. It is the highest-return artefact in the entire programme.
5. Quantification belongs at the end of the path, not the start. The maturity sequence runs system-centric, inventory, process coupling, process-led, value-steered. Organisations that begin with risk quantification are answering question five while their agents are operating at stage one. So what? A risk figure produced before the process mapping exists measures the quality of the estimate, not the exposure.
Critical recommendations
| Priority | Recommendation | Effort | Timeline |
|---|---|---|---|
| High | For every agent in or near production, write down which process steps it may trigger | Low | Immediate |
| High | Define the countersignature threshold per step, and name the role that holds it | Low | Immediate |
| High | Agree the halt decision and its owner before the incident, in writing | Low | One month |
| Medium | Establish detection and rollback for a wrong but well-formed agent decision | High | One to two quarters |
| Medium | Map value-critical processes to executing systems, and name an owner per process | High | Two quarters |
| Low | Defer risk quantification until process coupling exists | Low | Ongoing |
Bottom line
The agent question that matters is not “is the model safe”. It is “what may this thing do without asking, and who finds out if it was wrong”. That question has an owner, a threshold and a rollback path, or it does not have an answer.
Where the debate currently sits
The public conversation about agent security is largely a model conversation. That is understandable: the model is the novel component, the attacks against it are demonstrable, and the vendors with the loudest voices sell model-layer controls.
It is also incomplete in a specific way. Model hardening asks whether the agent can be made to do something it should not. Process authorisation asks what happens when the agent does precisely what it was built to do, in a situation the designer did not anticipate. The second case produces no anomaly, no injection signature and no alert. It produces a correct-looking transaction with a wrong business outcome.
These two failure modes need different controls, different owners and different evidence. Treating agent security as a model problem leaves the second one unaddressed and, worse, unmeasured.
Finding 1: The four questions
An agent that releases production orders or reconciles payments is not primarily a model security case. Four questions govern it:
- Which process steps may it alter? Not which systems it can reach, which steps it may change the state of.
- Which thresholds apply? Value, volume, frequency, deviation from a norm. A threshold is what separates an agent acting from an agent asking.
- Where does a human countersign? Not as a formality but as a defined step with a named role and a service level.
- How is a wrong decision detected and rolled back? Including the case where the decision was formally valid.
These questions cannot be answered on a system map, because a system map records what is connected to what, not what may be changed by whom under which condition. They can be answered on a process map, which is why the process-centric frame is not a philosophical preference here but a practical prerequisite.
Finding 2: What the frame of reference changes
The shift is not one of ownership. It is a change in the reference frame for each individual measure.
| Dimension | Conventional frame | Process-centric frame |
|---|---|---|
| Authorisation design | role and transaction | process step and the decision taken at it |
| Patch prioritisation | CVSS score of the system | criticality of processes running on it |
| AI agents | model and platform hardening | which process steps the agent may trigger, and who reviews the outcome |
| Interfaces | technical inventory | process dependency: which value stream breaks when it fails |
| Incident assessment | systems affected | processes interrupted and their contribution to the result |
Each row is a decision an organisation has already made implicitly. Making it explicit for agents first is the cheapest entry point, because agents are new enough that no legacy arrangement has to be unwound.
Finding 3: The tooling supplies the map, not the decision
A common response is that no new tooling is required, because process modelling and enterprise architecture already exist in house. That is half right, and the half that is wrong matters.
Checked against product documentation rather than positioning material: SAP LeanIX technology risk and compliance documents version clustering, detection of which custom applications run on which standard stacks, and lifecycle data on support types and policies. It does not describe dependency mapping as a named capability, nor direct connectors to security tooling. SAP Signavio describes a four-step risk and control approach, document, identify risks, implement controls, monitor continuously, and names SOX, Basel and Dodd-Frank among supported frameworks. It does not list named features for linking individual risks to security controls.
Neither vendor claims otherwise. The overreach is not theirs.
The repository makes criticality arguable. It does not produce a security decision, and no procurement will change that. The decision requires people who understand both the process and its technical dependencies, working together, which is an organisational cost that no licence covers.
Finding 4: The 03:00 problem
Isolating a host, disabling a partner integration, halting an agent mid-run: all technically trivial, all organisationally unresolved in most organisations.
If nobody has agreed in advance who decides at 03:00 on a Sunday and at what threshold, the organisation escalates instead of acting. Escalation during an incident consumes exactly the hours that determine its eventual size.
The remedy is a decision matrix with named roles, agreed and signed off before anything happens. It requires no budget, no procurement and no technology. It is routinely absent, and its absence is invisible until the night it matters.
Of everything in this article, this is the item with the highest ratio of consequence to cost. It can be done in a workshop.
Finding 5: Quantification comes last
The maturity path runs in a specific order:
- System-centric. Security stops at the system boundary.
- Inventory. Architecture and dependencies known.
- Process coupling. Systems mapped to processes, criticality clear.
- Process-led. Prioritisation and agent rights driven by process.
- Value-steered. Risk expressed in business figures, governance connected.
Quantification sits at stage five. An organisation that begins there, because a quantified risk figure is what the board asked for, produces a number whose accuracy depends on a mapping that does not yet exist.
The sequence is not bureaucratic. Each stage is the input to the next, and skipping to the output produces a figure that measures the estimator rather than the exposure.
Implications for Executives
Agent authorisation is a business decision that currently has no owner. Security does not know the process, the process owner does not know the systems, and enterprise architecture maintains the repository for reasons unrelated to security. The mapping is the work, and it is nobody’s job until someone assigns it.
Declaring ownership without resourcing it moves paperwork, not risk. Handing a process owner accountability for a risk they have neither budget nor expertise to address is the most common way process-centric intentions are neutralised. The frame changes and the resourcing does not.
Progress requires two uncomfortable admissions. Security has to say it does not know the processes, and the business has to say its documentation does not match what runs. Both are professionally awkward, which is why programmes stall at the mapping step and get restarted as tool selections.
Recommendations
| Recommendation | Rationale | Owner | Effort |
|---|---|---|---|
| List the process steps each production agent may trigger | Cannot be derived from a system map; must be written down | Process owner with security | Low |
| Set a countersignature threshold per step, with a named role | Separates acting from asking; the core control | Process owner | Low |
| Agree in writing who may halt an agent, and at what threshold | Escalation during an incident costs the hours that matter | CISO and COO | Low |
| Build detection and rollback for formally valid, wrong decisions | The failure mode that produces no alert | Security engineering | High |
| Assign each value-critical process an owner who knows its technical dependencies | The mapping has no natural owner today | Executive sponsor | High |
| Postpone quantification until stage three is reached | A figure produced earlier measures the estimate | Risk | Low |
Executive Dashboard
| Question | Can you answer it today? | Where the answer lives |
|---|---|---|
| Which process steps may each agent trigger? | Usually no | Process map, not system map |
| What threshold sends it to a human? | Usually no | Authorisation design per step |
| Who countersigns, with what service level? | Rarely | Named role, not a function |
| How is a wrong but valid decision detected? | Rarely | Detection design, hardest item |
| Who halts an agent at 03:00 on a Sunday? | Rarely | Decision matrix, cheapest item |
| Is our risk figure produced after the mapping? | Often no | Maturity stage three before five |
Appendix: Methodology
Research type. Position extension. This piece develops a recommendation contained in our own published article and does not introduce new external claims.
Frameworks applied. SCQA for framing; a maturity-path model for sequencing; a frame-of-reference comparison for the individual measures. All three come from the published position.
Frameworks considered and not applied. Porter’s Five Forces, BCG Matrix, Value Chain and PESTEL were rejected: this is an operating-model question, not a question of industry structure, portfolio allocation, cost structure or macro-environment. Technology Adoption Curve was rejected because no defensible adoption data for agent authorisation practices exists, and constructing one would be estimation presented as evidence.
Evidence status, stated plainly. Two categories, deliberately separated:
- Sourced. The four questions, the frame-of-reference table, the maturity path and the tooling assessment come from our published article and the underlying canonical note. The tooling assessment specifically was made by reading SAP LeanIX and Signavio product documentation, and it is the strongest empirical passage here.
- Experience claims, not sourced. The organisational findings, the 03:00 problem, the ownership gap, the two admissions, come from practice and are labelled as such in the underlying note (maturity `draft`). They are offered as argument, not evidence, and a reader is entitled to weigh them accordingly.
Confidence. High for findings 1 to 3 and 5, which rest on the published position and on documentation read directly. Medium for finding 4, which is an experience claim.
Limitations.
- The reference case behind the published position is a public-sector transport authority with a mandated process landscape, which is close to a best case for process-centric security. It is a proof of concept, not evidence of general applicability.
- The originating source for the process-centric reading is the public statement of one security executive, not a published framework. It holds as a direction of thinking, not as a procurement basis.
- No published data was found correlating decision-matrix maturity with response speed. The claim that pre-agreed decisions shorten incidents is plausible and unproven.
What could not be answered. Whether organisations that handle the decision matrix well rehearse it, and how often. That is the question worth asking a peer group, and it is why this article ends with a request rather than a conclusion.
Update trigger. Revisit when a published framework for agent process authorisation appears, or when regulatory guidance addresses agent decision rights directly.
Frequently Asked Questions
Does this mean model hardening is pointless?
No. Hardening addresses a real failure mode, an agent being manipulated into acting outside its intent. The argument is that it is the smaller of two exposures and that the larger one, a correct-looking decision with a wrong business outcome, produces no alert and is usually unaddressed.
Why was the Technology Adoption Curve not used?
Because no defensible adoption data exists for agent authorisation practices. Placing the market on a curve would have meant presenting an estimate as evidence. Porter, BCG, Value Chain and PESTEL were rejected for a different reason: this is an operating-model question, not one of industry structure, portfolio allocation, cost structure or macro-environment.
Which parts of this are evidence, and which are experience?
Deliberately separated in the methodology. The four questions, the frame-of-reference table, the maturity path and the tooling assessment come from the published position and from product documentation read directly. The organisational findings, including the 03:00 problem, are experience claims and are labelled as such. They are offered as argument, not proof.
We already run SAP LeanIX and Signavio. Is that not enough?
Those products supply the map, which is a genuine prerequisite. Neither claims to produce the security decision, and their documentation does not describe it. The decision needs people who understand both the process and its technical dependencies, which no licence covers.
Where do we start if we have no process map at all?
Not with the map. Start with the agents already running: list which process steps each may trigger and at which threshold a human is asked. That is a short exercise and it produces the first fragment of the map as a by-product.
The board wants a quantified cyber risk figure now. What do we say?
That the figure will measure the quality of the estimate until the process coupling exists, and that stage three of the maturity path is the prerequisite for stage five. Producing the number earlier is possible; relying on it is not.
Is there evidence that a pre-agreed decision matrix shortens incidents?
No published data was found correlating decision-matrix maturity with response speed. The claim is plausible and unproven, and it is stated that way in the methodology.
Sources
- Shift Up in Cybersecurity: Four Readings, One That Works. saschatheismann.de, published 3 July 2026 (EN and DE).
- The underlying canonical note, including the SAP LeanIX and SAP Signavio documentation assessment.
- Andreas Hauke, Head of the Office of the Chief Security Officer at SAP, public LinkedIn statement of 3 July 2026, retrieved and archived 5 September 2026. Cited as one executive’s public statement, not as a framework.
