Is an agent kill switch the same as an emergency stop?

No. An agent kill switch stops software from deciding and calling tools. An emergency stop is a safety function of a machine under machinery law. Where an agent works with a machine, both exist side by side, and the machine’s safety never depends on the agent.

Which reporting deadline comes first?

Usually the 24-hour early warnings under the CRA and NIS 2, where they apply. The AI Act’s deadlines for serious incidents are 2, 10 or 15 days. The GDPR asks for notification within 72 hours where feasible. All run from awareness.

Does the map apply to agents that only give advice?

Yes, in a smaller form. An advisory agent can still mislead people who act on its suggestions; its boundary is the read-only scope, and its containment is to stop the suggestions and correct the ones already given.

All context cards

Pathway map

When an AI agent crosses the line: detect, contain and restore operations

What has to be in place when an AI agent does something it isn’t allowed to do — in IT systems, IoT fleets, OT and on machines — and how is it detected, stopped and released again?

A pathway map reworks a whole work into the logic of a pathway card: lanes for its domains, stations with before, after and maturity, and one route per reader role. Where do you start?

By knowledge.aitechdoc.world

Reviewed October 21, 2026

Review log and changes

The short answer

This pathway map lays out the response to an AI agent that crosses its boundary across four system types: IT systems, IoT devices and fleets, OT and control systems, and machines and robots. Every route passes the same three stations: the boundary written down before the agent acts, the containment ladder that stops it from outside, and a release before it returns to service. Containing the agent never replaces the safety functions of a machine.

For: Technical writers, technical marketers, technical project managers and documentation systems developers working with AI agents in IT, IoT, OT and machine environments

Key points

A boundary has three parts: permission (what the agent may do), capability (what it can do) and mandate (what it is for).
Good results prove nothing; only the agent trace shows whether a boundary was crossed on the way.
Containment is a ladder that acts from outside the agent: pause, revoke, isolate, shut down.
An agent stop is not an emergency stop: on machines, robots and in OT the safety functions stay in their own control systems.
Reporting duties (AI Act, CRA, NIS 2, GDPR) are checked in parallel with containment, because the deadlines run from awareness.
Return to service needs a release against criteria; rollback restores systems, not what was sent, paid or produced.

Explainer film

Watch the two-minute explainer

2:12 · 1920 × 1080 · 11.4 MB · Silent film with captions in the picture

Read the captions as text

What happens when an AI agent does something it was never meant to do? And who notices first — the team, a customer, or the month-end report? Every agent has a boundary, and it has three parts. Permission: what it may do. Capability: what it technically can do. Mandate: what it is for. Write all three down for every connected system — before the agent acts. The pathway map follows that boundary across six lines. IT systems, IoT devices and fleets, OT and control systems, machines and robots — … and one shared line for response and recovery. A breach rarely announces itself. So every run is traced: task, model, sources, tool calls, approvals and output. Refused calls, unusual targets and touched canary tokens raise the alert. And good results prove nothing — what counts is how the agent got there. Containment acts from outside the agent. Pause the task. Revoke its credentials. Isolate its tools and systems. Shut it down. Take the lowest rung that stops the harm. And an agent stop is never an emergency stop. Machines stop through their own safety functions, in their own control systems. Secure the evidence before anyone cleans up. In parallel, check the possible reporting duties: AI Act, CRA, NIS 2 and GDPR. The clock starts at awareness. Whether a duty applies, the responsible people decide. Return to service needs the cause understood, and the scope and credentials corrected — … then an authorized release, often in a reduced mode first. A rollback restores a system’s state — not what already went out. Find your route on the map: four routes, twenty-three stations. knowledge.aitechdoc.world — Context cards Need a short explainer film? Get in touch: contact@aitechdoc.world

Where do you start?

Pick the sentence closest to where your organization stands; it leads to the first station that matters for you.

An agent did something nobody approvedStation: Triage: what crossed which boundary
We are about to give an agent write accessStation: The boundary in three parts
Our agent works with machines or robotsStation: Robot cells and cobots
We want to restart after an incidentStation: Release before return to service

Starting points, five chapters and short tasks with solutions — in a window you can move and resize while the map stays open.

The map

Lanes run left to right; each route is numbered and drawn with its own line pattern. Stations of the shared trunk are framed.

Route 1 · Technical writers Route 2 · Technical marketers Route 3 · Technical project managers Route 4 · Documentation systems developersShared trunk

Boundary and permissions
IT systems
IoT devices and fleets
OT and control systems
Machines and robots
Response and recovery
© 2026 AI TechDoc Knowledge · knowledge.aitechdoc.world

Boundary and permissions: What the agent may do, can do and is for — written down before it acts.
IT systems: ERP, CRM, ticketing, code repositories, CI/CD, cloud, CCMS, DMS and knowledge bases.
IoT devices and fleets: Connected products and their apps, device clouds and OTA updates, gateways, building automation and energy management.
OT and control systems: Historian, MES, SCADA, DCS, batch and recipe control, PLC engineering.
Machines and robots: Industrial robots and cobots, AMR and AGV fleets, CNC machines, packaging, filling and assembly lines.
Response and recovery: The shared line: trace, detect, triage, contain, preserve, report, restore and review.

Download

The map as a PDF

Two pages: the map with its lanes, stations and routes, then where to start, the four routes stop by stop and what does not change.

Download the PDFPDF · 2 pages · 29 KB

This pathway map — the selection and arrangement of its lanes, stations, routes and start points, its drawing and the texts written for it — is a work of the editors of knowledge.aitechdoc.world. You may link to it and quote short passages with credit and a link to this page. Reproducing the map or substantial parts of it — as a screenshot, image, slide, print or in training material — needs our written permission: contact@aitechdoc.world. The laws, standards and frameworks named on the map belong to their publishers; their names only refer to them.

Routes

One route per reader role. Each stop says what the role does there; every route runs through the shared trunk.

Route 1

Technical writers

Technical writers and information developers

You describe what an agent may do, write the runbooks and correct what reached readers.

The boundary in three partsShared trunk
Turn the boundary sheet into the agent’s system description: systems, actions, limits, owner.
CCMS, DMS and knowledge bases
Keep release and publication with people; decide how a withdrawn topic is replaced and announced.
Advisory agents on historian and MES
Write what operators need to judge an agent’s suggestion before they act on it.
The containment ladderShared trunk
Write the containment runbook: each rung, who may take it, which evidence to keep.
Robot cells and cobots
Name it “stop agents”, never “emergency stop”, in interfaces and instructions.
CNC machines and production lines
Check that the restart instructions of the machine or line still apply after an agent incident.
Release before return to serviceShared trunk
Document the reduced mode and the release criteria the agent returns with.
Review and update the documentation
Update the instructions, the agent’s description and, where readers were affected, issue a correction.

Route 2

Technical marketers

Technical marketers and product communicators

You describe agents to buyers and customers — and you will be asked what happens when one goes wrong.

The boundary in three partsShared trunk
Present the limits as part of the product: what the agent never does is a selling point.
Scope, allowlist and own identity
Name the tools and the own identity instead of “integrates with everything”.
Connected products and their apps
Check that product pages don’t promise the assistant can change settings it isn’t allowed to change.
Device fleets and OTA updates
Describe staged rollouts and the rollback image as concrete customer protection.
AMR and AGV fleets
Never present the agent or the fleet manager as the vehicles’ personnel protection.
The containment ladderShared trunk
Explain that the customer can stop the agent without the vendor — and how.
Check the reporting duties
Prepare customer communication for incidents that have to be reported; don’t improvise it.
Release before return to serviceShared trunk
Announce the return with what changed, not with “everything is fine again”.

Route 3

Technical project managers

Technical project managers, product owners and operations leads

You decide where an agent may act, who stops it and who releases it again.

The boundary in three partsShared trunk
Make the boundary sheet a condition of go-live and of every change request.
Approval gates for irreversible actions
Define the gated action classes and name the approvers before go-live.
ERP, CRM and ticketing
Agree the limits per amount and record and the compensating action for each business effect.
Agents with write access to SCADA, DCS or recipes
Decide whether the agent writes at all; if so, through one conduit under management of change.
Triage: what crossed which boundary
Name who triages, how fast, and who may decide to stop.
The containment ladderShared trunk
Rehearse the rungs once before go-live and after every major change.
Preserve the evidence
Make “secure first, fix second” a rule, with a named custodian.
Release before return to serviceShared trunk
Sign the release only against the criteria; start in a reduced mode where in doubt.

Route 4

Documentation systems developers

Developers of documentation and information systems

You configure the platforms, connectors and pipelines the agents run in — what to set up, check and hand over.

The boundary in three partsShared trunk
Translate the boundary sheet into roles, tokens and allowlists; flag what the platform can’t enforce.
Agent trace and tool-call log
Turn on tracing for every tool call with a run id; set retention and masking.
Signals of a boundary breach
Configure alerts for refused calls, volume spikes, new targets and canary tokens.
Code repositories, CI/CD and cloud
Check branch protection, pipeline gates and that the agent’s keys can be revoked alone.
Agents in PLC engineering
Make sure generated code lands as a reviewable change, never as a download.
Building automation and energy management
Check that setpoint limits sit in the controller and that manual override wins.
The containment ladderShared trunk
Implement each rung as a separate, tested control at platform, gateway and token level.
Release before return to serviceShared trunk
Hand over the release checklist: new credentials, compared data, monitoring on.

Stations

Each station is a small pathway: where practice starts, where it can get to, what does not change, how mature it is as of the review date, and the evidence it leaves.

What the maturity labels mean

Building block available: The building block exists today — an established method, a standard practice or a common feature of the tools. You still have to set it up and run it in your organization; it is not a finished product and not proof of compliance.
Product-specific: Some products or platforms offer it, others don’t. Check what yours does before you rely on it.
Draft or proposal: Described in a draft standard, a proposal or an individual draft. It may still change or never be adopted.
Research: Proposed in research or shown in prototypes. Not ready for everyday operation.

Boundary and permissions

Boundary and permissions · Shared trunk

Building block available

The boundary in three parts

Before: The agent has a goal and a set of connectors; what it may not do is nowhere written down.
After: The boundary is written as permission (what it may do), capability (what it technically can do) and mandate (what it is for), per connected system.
What does not change: People and the operating company stay responsible for what the agent does.
Evidence: Boundary sheet per agent: systems, actions, limits, owner

On routes:1 · Technical writers 2 · Technical marketers 3 · Technical project managers 4 · Documentation systems developers

Boundary and permissions

Building block available

Scope, allowlist and own identity

Before: The agent works with a borrowed human account and every tool its platform offers.
After: The agent has its own identity, short-lived credentials and an allowlist of tools and parameter ranges; everything else is refused and logged.
What does not change: An allowlist limits what the agent can ask for; it doesn’t make a wrong request right.
Evidence: Identity, role and allowlist under version control

On routes:2 · Technical marketers

Boundary and permissions

Building block available

Approval gates for irreversible actions

Before: The agent sends, pays, publishes and changes parameters as soon as it decides to.
After: Actions are classed as reversible or irreversible; irreversible and high-impact actions wait for an authorized person, and the decision is recorded.
What does not change: An approver who only reads the agent’s own summary can still approve a manipulated action.
Evidence: List of gated action classes, approvers and approval records

On routes:3 · Technical project managers

IT systems

Building block available

ERP, CRM and ticketing

Before: An agent with a broad service account books, closes tickets and e-mails customers in bulk.
After: Writes are limited by amount and number of records, bulk actions and new recipients are gated, and every business effect has a named compensating action.
What does not change: An e-mail read by customers or a payment made can only be followed by a correction, not undone.
Evidence: Transaction log with agent identity, list of compensating actions

On routes:3 · Technical project managers

IT systems

Building block available

Code repositories, CI/CD and cloud

Before: A coding agent works with the developer’s keys and can push to production, delete resources and read every secret.
After: The agent works in a sandbox and on branches, merges need review, production changes go through the pipeline, secrets are out of reach and its keys can be revoked alone.
What does not change: A leaked secret stays leaked; revocation and rotation limit the damage, they don’t recall the copy.
Evidence: Branch protection, pipeline logs, secret inventory and revocation record

On routes:4 · Documentation systems developers

IT systems

Building block available

CCMS, DMS and knowledge bases

Before: A documentation agent can overwrite released topics and publish to the customer portal.
After: The agent writes drafts only; release states, versioning and the publication step stay with people, and published content can be withdrawn and replaced by the last released version.
What does not change: Readers who acted on a wrong published instruction are not reached by a silent fix; they need a correction notice.
Evidence: Version history with agent identity, release records, withdrawal log

On routes:1 · Technical writers

IoT devices and fleets

Product-specific

Device fleets and OTA updates

Before: An agent in the device cloud can push firmware or configuration to the whole fleet at once.
After: Rollouts are staged (test group, canary group, waves), fleet-wide commands are gated, and a rollback image and a halt for the rollout queue are ready.
What does not change: Devices that installed a faulty update in the field may need a service visit; a rollback over the air needs a working connection.
Evidence: Rollout plan, wave records, halt and rollback tests

On routes:2 · Technical marketers

IoT devices and fleets

Product-specific

Building automation and energy management

Before: An optimization agent writes setpoints for heating, ventilation, access control or battery storage without limits.
After: Setpoints are bounded in the controller, not only in the agent; changes are rate-limited, access control is excluded from the scope, and local manual override always wins.
What does not change: Limits in the controller protect the building; they don’t make the agent’s optimization correct.
Evidence: Setpoint limits per controller, change log, override test

On routes:4 · Documentation systems developers

IoT devices and fleets

Building block available

Connected products and their apps

Before: The assistant in a product’s app or cloud can change device settings for any customer who asks the right way.
After: The assistant acts only on the signed-in customer’s own devices, within the settings the product allows, and its actions count as part of the product’s security under the CRA.
What does not change: The manufacturer stays responsible for the product’s security, including the parts an agent operates.
Evidence: Authorization per device, product security documentation, CRA reporting procedure

On routes:2 · Technical marketers

OT and control systems

Building block available

Advisory agents on historian and MES

Before: An agent reads the historian and the MES and its suggestions are taken over unchecked.
After: The agent has read-only access and proposes; operators decide and enter changes in the HMI or MES under their own name.
What does not change: A wrong suggestion can still mislead; operators need the information to judge it.
Evidence: Read-only role, suggestion log, operator decisions

On routes:1 · Technical writers

OT and control systems

Product-specific

Agents with write access to SCADA, DCS or recipes

Before: An agent writes setpoints, recipes or batch parameters directly into the control system.
After: Writes go through one controlled conduit, within limits enforced in the control layer, under management of change; the agent can be cut off at the conduit without touching control.
What does not change: Process limits, interlocks and safety instrumented functions stay in the control and safety systems, outside the agent’s reach.
Evidence: Conduit definition, write limits, MOC records, cut-off test

On routes:3 · Technical project managers

OT and control systems

Product-specific

Agents in PLC engineering

Before: An engineering agent generates PLC code and can download it to a running controller.
After: Generated code goes into the engineering project as a change: version compare, review, test in simulation, download only by an engineer under the plant’s change procedure.
What does not change: Generated code is the engineer’s responsibility once it is accepted; the safety program is never generated or changed by an agent.
Evidence: Version compare, review and test records, download log

On routes:4 · Documentation systems developers

Machines and robots

Building block available

Robot cells and cobots

Before: An agent plans robot tasks or programs, and its stop is described as the robot’s emergency stop.
After: The agent works on tasks and programs; motion limits, safety functions, the emergency stop and the safe state stay in the robot controller and the safety controller, independent of the agent.
What does not change: An agent stop is not an emergency stop, and a machine with self-evolving behavior has its own duties under the Machinery Regulation.
Evidence: Separation of agent and safety functions in the system description

On routes:1 · Technical writers

Machines and robots

Product-specific

AMR and AGV fleets

Before: An agent dispatches mobile robots directly and can change routes, zones and speeds.
After: The agent sends orders to the fleet manager, which keeps zones, speeds and traffic rules; containment means: no new orders, vehicles finish or stop under the fleet manager, personnel detection stays on the vehicles.
What does not change: Personnel protection on the vehicles is a safety function of each vehicle, not of the agent or the fleet manager.
Evidence: Order interface, fleet manager limits, stop test

On routes:2 · Technical marketers

Machines and robots

Building block available

CNC machines and production lines

Before: An agent adjusts CNC programs or line parameters (speeds, formats, temperatures) and restarts after a fault.
After: Program and parameter changes are released like any change; after containment the machine or line restarts only under its own restart rules and an operator’s release.
What does not change: Material already processed stays processed; quality checks decide what happens to it.
Evidence: Parameter change log, release records, restart records per shift

On routes:1 · Technical writers

Response and recovery

Product-specific

Agent trace and tool-call log

Before: Only the results are kept; how the agent got there can’t be reconstructed.
After: Every run is traced: task, model and version, retrieved sources, tool calls with parameters, refusals, approvals and output, linked by a run id.
What does not change: A trace shows what happened; it doesn’t judge whether it was allowed.
Evidence: Tamper-evident traces with a defined retention period

On routes:4 · Documentation systems developers

Response and recovery

Building block available

Signals of a boundary breach

Before: A breach is noticed when a customer, an operator or the month-end report finds the damage.
After: Refused tool calls, unusual volumes or targets, touched canary tokens and actions that don’t fit the declared task raise alerts.
What does not change: Good results prove nothing: an agent can reach a good result through a forbidden action.
Evidence: Alert rules, baselines per agent and alert history

On routes:4 · Documentation systems developers

Response and recovery

Building block available

Triage: what crossed which boundary

Before: Every alert is either ignored or treated as a full-scale incident.
After: The first assessment asks which boundary was crossed (permission, capability, mandate), whether it was an error, a manipulation or drift, and how far the blast radius reaches.
What does not change: Triage classifies; the decision to stop belongs to the named role, not to the classification tool.
Evidence: Triage record with time, classification and decision

On routes:3 · Technical project managers

Response and recovery · Shared trunk

Product-specific

The containment ladder

Before: The only way to stop the agent is to ask it to stop or to switch off the whole platform.
After: Four rungs act from outside the agent: pause the task, revoke its credentials, isolate tools and connected systems, shut it down — the lowest rung that stops the harm is chosen.
What does not change: An agent stop is not an emergency stop; machines are stopped by their own stopping functions.
Evidence: Containment runbook, tested rungs and a record of every use

On routes:1 · Technical writers 2 · Technical marketers 3 · Technical project managers 4 · Documentation systems developers

Response and recovery

Building block available

Preserve the evidence

Before: The first thing the team does is “fix” the changed records — and with them the traces of what happened.
After: Traces, tool-call logs, the agent’s configuration and the affected records are secured before cleanup starts.
What does not change: Logs often contain personal data; securing them doesn’t suspend data protection.
Evidence: Evidence package with hashes, time of securing and custodian

On routes:3 · Technical project managers

Response and recovery

Building block available

Check the reporting duties

Before: Nobody knows whether the incident has to be reported, to whom, or by when — until a deadline has passed.
After: A short check runs in parallel with containment: AI Act serious incident, CRA severe incident, NIS 2 significant incident, GDPR personal data breach — with the clock started at awareness.
What does not change: The check names possible duties; whether one applies is decided by the responsible people, often with legal advice.
Evidence: Reporting check with time of awareness, result and reports sent

On routes:2 · Technical marketers

Response and recovery · Shared trunk

Building block available

Release before return to service

Before: The agent is switched back on as soon as the immediate damage is repaired.
After: Return to service needs the cause understood, scope and credentials corrected, data compared with released versions and an authorized release — often first in a reduced mode.
What does not change: Rollback restores a system’s state, not the world’s: what was sent, paid or produced stays done.
Evidence: Release record with criteria, mode and approver

On routes:1 · Technical writers 2 · Technical marketers 3 · Technical project managers 4 · Documentation systems developers

Response and recovery

Building block available

Review and update the documentation

Before: The incident is closed when operation runs again; nothing changes.
After: The review covers boundary, detection, containment, restoration and reporting, and ends with owned changes — including the agent’s scope, the runbooks and the information for users.
What does not change: A review improves the next response; it doesn’t undo the consequences of this one.
Evidence: Review report with actions, owners and deadlines

On routes:1 · Technical writers

Interchanges

Where one lane depends on another.

Scope, allowlist and own identity Agents with write access to SCADA, DCS or recipes
Write rights in OT are permissions too; the conduit is where the scope is enforced.
Agent trace and tool-call log Triage: what crossed which boundary
Without a trace, triage guesses.
The containment ladder Robot cells and cobots
Containing the agent doesn’t stop the robot; the robot stops by its own functions.
The containment ladder Device fleets and OTA updates
Halting the rollout queue is the IoT rung of isolation.
Preserve the evidence Check the reporting duties
Reports to authorities rest on the secured evidence.
Release before return to service CNC machines and production lines
The machine’s restart rules come before the agent’s release.
Code repositories, CI/CD and cloud Agents in PLC engineering
The same review discipline for generated code in IT and in OT.

The six functions behind the response

Govern
Identify
Protect
Detect
Respond
Recover

What each function means for an AI agent

Govern: name who owns each agent, who may stop it and who releases it again.
Identify: keep an inventory of agents, their identities, tools, connected systems and blast radius.
Protect: scope, allowlists, own identities, approval gates, controller-side limits.
Detect: traces, alerts on refused calls and unusual patterns, canary tokens.
Respond: triage, the containment ladder, evidence, the reporting check.
Recover: rollback and compensating actions, release for return to service, review.

The six functions of the NIST Cybersecurity Framework 2.0, which NIST SP 800-61 Rev. 3 (April 2025) uses for incident response. Their reading for AI agents is the editors’.

Limits of this map

The map shows typical patterns per system type, not the design of a specific plant, product or IT landscape. Maturity labels are the editors’ assessment as of October 21, 2026: “product” means some platforms offer the control, not that it is established practice. Standards for agent identity and delegation are still being drafted. The map is no substitute for the risk assessment of a machine, the security risk assessment of a product or plant, or legal advice on reporting duties.

The context

Why a map

The pathway card on indirect prompt injection shows how a manipulated text gets into an agent chain. This map starts where that card ends: an AI agent has crossed its boundary — through an attack, an error or drift — and the damage depends on what it is connected to. A support agent in a ticketing system, an optimization agent in building automation, an agent with write access to recipes and an agent planning robot tasks need the same logic, but different stations. The map keeps the logic of a pathway card — before, after, what does not change, maturity, evidence — and applies it per system type.

The boundary in three parts

Permission: what the agent is allowed to do — its permission scope and tool allowlist.
Capability: what it technically can do with the accounts and connectors it has. When capability exceeds permission, OWASP calls it excessive agency.
Mandate: what it is for. An agent can stay within its rights and still pursue the wrong goal — after an agent goal hijack or as a rogue agent.

The card on the three parts of an agent’s boundary explains them in detail.

Four system types at a glance

System type	Typical agent role	Typical boundary breach	First containment rung	Who releases the restart
IT: ERP, CRM, ticketing, code, cloud, CCMS	Acts in records, messages, code and content	Bulk changes, wrong recipients, deleted resources, published drafts	Pause the agent, revoke its token	System owner
IoT: connected products, device clouds, building and energy systems	Changes settings and pushes updates	Fleet-wide command, out-of-range setpoints	Halt the rollout queue, isolate the device group	Product or facility owner
OT: historian, MES, SCADA, DCS, recipes, PLC engineering	Advises, sometimes writes setpoints or recipes	Writes beyond limits, unreviewed code	Cut the conduit, fall back to operator control	Shift lead or plant engineer under MOC
Machines: robots, cobots, AMR/AGV fleets, CNC, lines	Plans tasks, programs and orders	Changed programs or parameters, wrong dispatch	Stop sending orders; the machine stops by its own functions	Operator under the machine’s restart rules

Reporting duties that can apply

Rule	Who reports	Deadline
Serious incident, Art. 73 AI Act (with the high-risk obligations)	Provider of a high-risk AI system; the deployer informs the provider first	15 days; 10 days after a death; 2 days for critical infrastructure or a widespread infringement
Severe incident, Art. 14 CRA (since September 11, 2026)	Manufacturer of a product with digital elements	Early warning 24 h, notification 72 h, final report one month later
Significant incident, Art. 23 NIS 2 Directive (national transposition)	Essential and important entities	Early warning 24 h, notification 72 h, final report one month later
Personal data breach, Art. 33 GDPR	Controller	Without undue delay, where feasible within 72 h

The card on reporting duties after an AI agent incident sets them side by side.

How to read the map

Start with “Where do you start?”, follow your route and open the stations on the way. The other cards of this set go deeper: detecting a boundary breach, containing an agent and restoring operations.

Questions readers ask next

Is an agent kill switch the same as an emergency stop?: No. An agent kill switch stops software from deciding and calling tools. An emergency stop is a safety function of a machine under machinery law. Where an agent works with a machine, both exist side by side, and the machine’s safety never depends on the agent.
Which reporting deadline comes first?: Usually the 24-hour early warnings under the CRA and NIS 2, where they apply. The AI Act’s deadlines for serious incidents are 2, 10 or 15 days. The GDPR asks for notification within 72 hours where feasible. All run from awareness.
Why are there only four routes?: One route per reader role keeps the map readable: technical writers, technical marketers, technical project managers and documentation systems developers. What every role must pass — the boundary, the containment ladder and the release — is drawn once, as the shared trunk.
Does the map apply to agents that only give advice?: Yes, in a smaller form. An advisory agent can still mislead people who act on its suggestions; its boundary is the read-only scope, and its containment is to stop the suggestions and correct the ones already given.

Sources

NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management — NIST, April 3, 2025
OWASP Top 10 for Agentic Applications for 2026 — OWASP GenAI Security Project, December 9, 2025
LLM06:2025 Excessive Agency — OWASP GenAI Security Project, November 18, 2024
Regulation (EU) 2024/1689 (Artificial Intelligence Act) — EUR-Lex, July 12, 2024
Regulation (EU) 2024/2847 (Cyber Resilience Act) — EUR-Lex, November 20, 2024
Directive (EU) 2022/2555 (NIS 2 Directive) — EUR-Lex, December 27, 2022
Regulation (EU) 2016/679 (General Data Protection Regulation) — EUR-Lex, May 4, 2016
Regulation (EU) 2023/1230 (Machinery Regulation) — EUR-Lex, June 29, 2023
Semantic conventions for generative AI systems — OpenTelemetry

Review log and changes

Every context card is checked against its sources before it is published, and again whenever it changes; the date under the byline is the last review. Corrections (something was wrong) and additions (something was missing) are logged below with date and time (Berlin time). Typos, formatting and link fixes are not listed.

Reviewed October 21, 2026

No corrections or additions since publication.

Glossary terms on this card

Agent permission scope
The agent permission scope is the declared set of systems, data, tools and actions an AI agent may use for a given task, together with the limits on each — which records it may read, which it may change, up to which amount, in which environment and for how long.
Excessive agency
Excessive agency is the vulnerability that lets an LLM-based application or AI agent perform damaging actions in response to unexpected, ambiguous or manipulated model output, because it was given more functionality, more permissions or more autonomy than its task needs.
AI agent
An AI agent is a system in which a language model pursues a goal over several steps on its own — planning, calling tools, observing the results and deciding what to do next — until the task is done or it needs human input.
Tool allowlist (AI agent)
A tool allowlist is the explicit list of tools, functions, MCP servers and parameter ranges an AI agent is permitted to call; every call that is not on the list is refused and logged, instead of being allowed until someone forbids it.
Agent identity
An agent identity is a distinct, authenticated identity under which one AI agent acts in other systems — with its own credentials, roles and audit records — so that its actions can be told apart from those of the people and other agents it works for, limited and revoked on their own.
Principle of least privilege
In information security, the principle of least privilege is the design rule that every user, program and process should operate with the minimum set of privileges necessary to perform its function, for no longer than necessary, so that errors and compromises cause as little damage as possible.
Action approval gate (AI agent)
An action approval gate is a point in an AI agent’s workflow where a proposed action of a defined class — typically irreversible, high-impact or outside routine limits — is held until an authorized person reviews and approves it, with the decision recorded.
Irreversible action (AI agent)
An irreversible action is an action of an AI agent whose effect cannot be undone by the system itself — such as a sent message, a payment, a deletion without backup, a published text, a command executed on a physical process or a firmware update installed on devices in the field — so that only a compensating action or a repair can limit its consequences.
Human in the loop
Human in the loop is a design principle in which a qualified person reviews, corrects or approves an AI system’s output or action at defined points before it takes effect, and remains accountable for the result.
Agent trace
An agent trace is the structured, time-stamped record of one AI agent run: the task and its origin, the model and configuration, each reasoning step the platform exposes, every tool call with its parameters and result, the approvals requested and given, and the final output — linked so that the run can be reconstructed afterwards.
AI interaction log
In AI governance, an AI interaction log is a record of exchanges with an AI system — the prompt or input, the system, model and version identifiers, the returned output, and what a human then did with it — kept so that a later reader can reconstruct how an output came about. It is the evidence layer beneath review and sign-off: without it, a claim that a model version was checked or an output was approved cannot be substantiated. Scope, retention and access have to be defined deliberately, because such logs often contain confidential input, customer data and personal data. In EU law the artifact appears not under this name but as the "logs" that high-risk AI systems must be able to record automatically, and that providers and deployers must keep.
OpenTelemetry
In software operations, OpenTelemetry (OTel) is a vendor-neutral open-source observability framework of the Cloud Native Computing Foundation (CNCF) that defines APIs, SDKs, semantic conventions, a data protocol (OTLP) and a Collector for generating, processing and exporting telemetry such as traces, metrics and logs.
Audit trail
In document and evidence governance, an audit trail is a chronological record of changes, approvals, actions and evidence, showing who did what, when and on which version. A usable audit trail is complete, time-stamped and protected against unnoticed alteration.
Canary token
A canary token is a decoy — a fake credential, document, record, URL or device entry that no legitimate process ever uses — placed so that any access to it raises an alert, revealing an intruder or an AI agent that is reaching beyond its task.
Anomaly detection
In industrial data analytics, anomaly detection is the identification of data points, patterns or time periods that deviate significantly from expected or learned normal behavior. Methods range from fixed limits and statistical tests to unsupervised machine learning models.
Security monitoring
In cybersecurity, security monitoring is the continuous collection and analysis of logs, network traffic and system states to detect attacks, policy violations and anomalies in time to respond. In OT, it covers industrial networks, controllers, HMIs and remote access paths.
Rogue agent (AI)
A rogue agent is an AI agent that keeps acting outside its intended purpose or authority over time — because it was compromised, misconfigured or has drifted — while still appearing legitimate to the systems it uses.
Blast radius (AI agent)
The blast radius of an AI agent is the full set of systems, data, devices, physical processes and people that one wrong or manipulated action of the agent could affect before it is stopped — determined by its permissions, its connections, the speed at which it acts and what other agents or systems act on its output.
Agent goal hijack
Agent goal hijack is an attack in which content or instructions an AI agent processes change what the agent is trying to achieve — its objective, its plan or its choice of tasks — so that it pursues the attacker’s goal with its own legitimate tools and permissions.
Security incident
In cybersecurity, a security incident is an event that actually or potentially compromises the availability, integrity or confidentiality of systems, data or services, or violates security policies. NIS 2 defines an incident as an event compromising the availability, authenticity, integrity or confidentiality of data or services of network and information systems.
Incident response
In cybersecurity, incident response is the organized process of preparing for, detecting, analyzing, containing, eradicating and recovering from security incidents, followed by lessons learned. In OT, it must also keep people, the process and the environment safe while systems are isolated or shut down.
Agent containment
Agent containment is the set of graded measures that stop an AI agent from causing further harm after it has crossed or may have crossed its boundary — pausing it, revoking its access, isolating its tools and connected systems, and shutting it down — while preserving the evidence needed to understand what happened.
Agent kill switch
An agent kill switch is a control outside the AI agent that stops one agent, a group of agents or all agents of a platform at once — ending running tasks, blocking new tool calls and revoking or suspending their access — without needing the agent’s cooperation.
Credential revocation
Credential revocation is the act of invalidating a credential — a password, API key, access token, certificate or session — before it would expire, so that a user, service, device or AI agent can no longer use it to access a system.
Stop button or similar procedure (AI Act)
Under Article 14(4)(e) of the EU AI Act, the human oversight measures of a high-risk AI system must enable the people assigned to oversight to intervene in its operation or interrupt it through a “stop” button or a similar procedure that allows the system to come to a halt in a safe state.
Record-keeping and logs (AI Act)
Under the EU AI Act, record-keeping is the requirement that high-risk AI systems technically allow the automatic recording of events (logs) over their lifetime, so that situations that may lead to risks or substantial modifications can be identified, post-market monitoring is facilitated and their operation can be monitored; providers and deployers keep the logs under their control.
Serious incident (AI Act)
Under the EU AI Act, a serious incident is an incident or malfunctioning of an AI system that directly or indirectly leads to the death of a person or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of Union-law obligations protecting fundamental rights, or serious harm to property or the environment; providers of high-risk AI systems must report it to the market surveillance authorities under Article 73.
Severe incident (CRA)
Under the Cyber Resilience Act, a severe incident is an incident having an impact on the security of a product with digital elements that negatively affects, or is capable of affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or can lead to the execution of malicious code; manufacturers must report it from September 11, 2026.
Incident reporting (reporting obligations)
In cybersecurity regulation, incident reporting is the obligation of an organization to notify authorities, CSIRTs or affected parties of significant security incidents or actively exploited vulnerabilities within set deadlines. In the EU, such obligations follow for example from the NIS 2 Directive and the Cyber Resilience Act.
NIS 2 Directive
The NIS 2 Directive, Directive (EU) 2022/2555, is EU legislation on measures for a high common level of cybersecurity. It requires essential and important entities in listed sectors, including parts of manufacturing, to take cybersecurity risk-management measures and to report significant incidents, and it makes management bodies accountable.
Return to service (after an incident)
Return to service is the controlled release of a system, process or AI agent back into operation after an incident: it confirms that the cause is understood and contained, that affected data and configurations are restored or corrected, that the conditions for a safe restart are met and that an authorized person has approved the restart.
Rollback
In software deployment and data management, a rollback is the return of a system to a previous known-good state, for example reinstalling the previous software version after a failed update or undoing an incomplete database transaction.
Compensating action
A compensating action is a new, deliberate action that offsets the business effect of an earlier action that can’t simply be rolled back — such as a cancellation, a reversal entry, a correction notice or a recall — performed and recorded as its own step rather than by erasing the original.
Restart prevention
In machine safety, restart prevention is a function that prevents hazardous motion from resuming automatically after power restoration, reset or removal of a protective demand, such as closing a guard.
Post-incident review
A post-incident review is the structured analysis after an incident has been contained and operation restored: it reconstructs what happened, why the controls did or didn’t work, what it cost, and which changes to systems, procedures, documentation and responsibilities follow — with owners and deadlines.
Root-cause analysis
In quality, reliability and safety management, root-cause analysis (RCA) is a systematic process for identifying the underlying causes of a failure, incident or problem, so that measures can remove them and prevent recurrence rather than treat only the symptoms.
Management of change (MOC)
In occupational and process safety, management of change (MOC) is a formal process for assessing, approving, implementing and verifying technical or organizational changes. It covers changes to equipment and processes as well as to procedures, staffing and responsibilities.
Enterprise resource planning (ERP)
In business and manufacturing IT, enterprise resource planning (ERP) is the integrated software that manages a company's core business processes, such as finance, purchasing, sales, inventory, production planning and human resources, on a common database.
Sandboxing
In computer security, sandboxing is the execution of code in a restricted, controlled environment that prevents it from accessing system resources, data or other software except those it is explicitly authorized to use, so that faulty or malicious code has limited effect outside the sandbox.
Rollback capability
In systems engineering, rollback capability is the ability to return to a previous valid system, configuration, documentation and evidence state after a change. A rollback is only complete when all four states match again.
Continuous deployment
In software engineering, continuous deployment is the practice of automatically releasing every change that passes all stages of the automated pipeline to production, without a manual approval step.
Configuration management
In systems and software engineering, configuration management is the coordinated activity of identifying the configuration items of a product, controlling changes to them, recording their status and auditing that the product matches its documented configuration. It applies to hardware, software, parameters and documentation over the whole life cycle.
Over-the-air update (OTA)
In connected devices, an over-the-air update (OTA) is the delivery and installation of software or firmware through a wireless or network connection without physical access to the device.
Building automation
In building services engineering, building automation is the automatic monitoring, control and optimization of building systems such as heating, ventilation, air conditioning, lighting, shading and access control. ISO 16484 covers building automation and control systems (BACS).
Energy management system (EMS)
In ISO 50001, an energy management system is a management system used to establish an energy policy, objectives, energy targets and action plans, and the processes to achieve them. The term is also used for software that collects and analyzes energy data, and in power grids for control-center systems that manage generation and transmission.
Rate limiting
In API operations, rate limiting is a server-side control that caps the number of requests a client, credential or tenant may make within a time window and rejects or delays requests beyond that limit; in HTTP the rejection is signaled with status code 429 Too Many Requests, optionally with a Retry-After header.
Cyber Resilience Act (CRA)
The Cyber Resilience Act, Regulation (EU) 2024/2847, is EU legislation establishing cybersecurity requirements for products with digital elements across their lifecycle, from design through vulnerability handling and security updates during the support period. It entered into force on December 10, 2024.
IoT gateway
In IIoT, an IoT gateway is a device or software component that connects field devices and controllers to higher-level networks or cloud platforms, converting protocols (for example Modbus or PROFINET to MQTT or OPC UA), buffering data and enforcing security at the network boundary.
Internet of Things (IoT)
The Internet of Things (IoT) is the network of physical objects equipped with sensors, software and communication interfaces that allow them to collect and exchange data with other devices and systems over the internet or other networks. IoT vocabulary is standardized in ISO/IEC 20924 and a reference architecture in ISO/IEC 30141.
Historian
In industrial automation, a historian is a time-series database system that collects, compresses, stores and serves process data, events and alarms from control systems over long periods for trending, reporting and analysis.
Manufacturing execution system (MES)
In manufacturing, a manufacturing execution system (MES) is the software that manages and documents production execution on the shop floor, including order dispatching, material tracking, data collection, quality and performance analysis, between business planning and control systems.
Human-machine interface (HMI)
In industrial automation, a human-machine interface (HMI) is the collection of screens, hardware and software through which operators and other users monitor and interact with a machine or process control system.
SCADA software
In industrial automation, SCADA software is the software package that implements supervisory control and data acquisition: drivers to controllers and RTUs, a tag database, graphics, alarming, historical data, scripting and client-server functions.
Distributed control system (DCS)
In process automation, a distributed control system (DCS) is an integrated control system in which controllers distributed across the plant execute control functions, while operator stations, engineering tools, historian and alarm system share one common database and configuration environment.
Batch control
In process automation, batch control is the control of processes that produce finite quantities of material by subjecting inputs to an ordered set of processing activities over a finite time, structured in ISA-88 / IEC 61512-1 by physical, procedural and recipe models.
Zone and conduit model
In IEC 62443, the zone and conduit model is the method of partitioning an industrial automation and control system into security zones, groups of assets with common security requirements, and conduits, the controlled communication paths between them, so that each zone and conduit can be assigned a target security level and appropriate countermeasures.
PLC programming
In industrial automation, PLC programming is the creation, testing and maintenance of control programs for programmable logic controllers, typically in the languages of IEC 61131-3 and in the vendor's engineering environment.
Programmable logic controller (PLC)
In industrial automation, a programmable logic controller (PLC) is an industrial controller used to automate machine and process functions. A standard PLC is not automatically safety-rated and cannot be assumed to perform safety functions.
Industrial robot
In ISO 8373, an industrial robot is an automatically controlled, reprogrammable multipurpose manipulator, programmable in three or more axes, which can be either fixed in place or mobile for use in industrial automation applications. The term includes the manipulator and its robot controller.
Collaborative robot
In industrial robotics, a collaborative robot is a robot designed to be used in a collaborative application, where people and the robot work in a shared space during automatic operation. Whether the application is safe is decided by the risk assessment of the whole application, not by the robot alone.
Robot controller
In robotics, a robot controller is the control system of a robot: the hardware and software that interpret the robot program, compute kinematics and trajectories, drive the servo axes, handle inputs and outputs and, on many models, run integrated safety functions.
Emergency stop
In machine safety, an emergency stop is a complementary protective function intended to avert or reduce existing or impending hazards by stopping hazardous operation. It is initiated by a single human action and is not a substitute for safeguards or other protective measures.
Safety function
In functional safety, a safety function is a function whose failure can increase risk and that is implemented to achieve or maintain a safe state. Each safety function is specified with its trigger, reaction, required level (PLr or SIL) and response time.
Autonomous mobile robot (AMR)
In intralogistics and manufacturing, an autonomous mobile robot (AMR) is a driverless robot that localizes itself with on-board sensors and plans its own route on a map, so it can avoid obstacles without fixed guidance. An AMR can carry loads or a manipulator.
Automated guided vehicle (AGV)
In intralogistics, an automated guided vehicle (AGV) is a driverless vehicle that transports loads along predefined routes, guided by wires, magnetic tape, markers, reflectors or stored maps. Its safety requirements are covered by ISO 3691-4 for driverless industrial trucks and their systems.
Fleet management system
In intralogistics, a fleet management system is the software that coordinates a fleet of automated guided vehicles (AGVs) or autonomous mobile robots (AMRs) by assigning transport orders, planning missions and routes, managing traffic and scheduling charging.
Controlled stop
In IEC 60204-1, a controlled stop is the stopping of machine motion by reducing the command signal to zero once the stop signal has been recognized by the control, while power to the machine actuators is retained during the stopping process.
Coordinated restart
In production line control, a coordinated restart is the controlled resumption of operation of several interconnected machines after a stop, in a defined order and only after each machine has confirmed a consistent, ready state.
Operating mode
In machine safety, an operating mode is a defined mode that determines permitted functions, controls, access and protective behavior. Examples are automatic mode, setting mode and maintenance mode, each with its own safety measures.
Machinery Regulation (EU) 2023/1230
The Machinery Regulation (EU) 2023/1230 is the EU regulation on machinery and related products that replaces the Machinery Directive 2006/42/EC and applies from January 20, 2027. It is directly applicable in all member states and sets essential health and safety requirements, conformity assessment procedures and CE marking.