The production Lambda Action Group registry for Digital Coworker contains no write functions.
Not “write operations are disabled by default.” Not “the prompt instructs the agent not to push configurations.” No Lambda function that modifies network state exists in the registry. When no write tool is registered, no write operation is possible — regardless of what the user asks, what the LLM infers, or what a prompt injection attempts. The boundary is not policy. It is architecture.
Why Architectural Enforcement Is Different From Policy#
An agent instruction that says “do not modify network configurations” is a soft constraint. LLMs follow instructions probabilistically. Under adversarial prompting, under edge cases in instruction-following, that constraint can fail. Prompt injection against agentic systems is an active attack surface — NIST AI 100-2 (Adversarial Machine Learning: A Taxonomy and Terminology) covers input-based adversarial attacks against AI systems; prompt injection is the LLM-specific instantiation of this class.
An empty Action Group is not a soft constraint. If the Lambda function does not exist, the tool cannot be invoked — regardless of what the LLM infers. The distinction matters in OT environments because the failure modes are not equivalent.
A misconfigured MRP ring (IEC 62439-2) can bring a production line down — not disrupt operations, stop production. A correctly designed ring recovers from a physical break in 10–500 ms. But a misconfigured device (a duplicate ring manager, bridged ring ports, or an incorrect VLAN assignment) can cascade into a broadcast storm or persistent topology conflict within seconds, with no self-healing path. MRP’s self-healing assumes a single physical fault, not a logical conflict. The blast radius of a write operation gone wrong in this domain is not recoverable by reverting a config file.
The failure consequence in OT is not a bad user experience. It is an immediate production stop. The architecture had to make the wrong outcome structurally impossible, not merely unlikely.
The Two Failure Modes That Justify Read-Only#
When I revisited this decision in The Four Markers of AI-Native: What Held Up at One Month, I described two failure modes the original framing underweighted. Both require articulation here.
Failure mode 1: Market trust. OT customers will not allow write operations on live equipment until they have run the system in read-only mode long enough to calibrate trust. The market will impose the read-only phase; the question is whether the product team controls it deliberately or has it imposed reactively after an incident.
Failure mode 2: Architectural overreach. Autonomous write operations in OT require a deterministic pre-execution validation layer — a formal check that a proposed configuration change is safe given current network state and downstream dependencies. That layer is a project within a project. We did not have it at launch. Deploying write capability without it would have been an architectural mistake independent of market readiness.
How the Enforcement Actually Works#
AWS Bedrock Agents orchestrate tool calls through Action Groups — Lambda functions with defined schemas. The LLM does not write code; it calls registered tools.
The production Action Group registry for Digital Coworker contains queries only: Lambda functions that retrieve network state, compute graph traversal results, and return device configuration summaries. Adding write capability requires deploying a new Lambda function and explicitly registering it — a deliberate architectural act, not a configuration change or a prompt edit.
The Bedrock Guardrails layer adds content filtering and prompt injection detection as defence in depth — valuable, but not the primary mechanism. The safety guarantee is only as strong as what you put in the registry. That is why the registry is the artefact you govern, not the prompt.
The Trust-Earning Sequence#
The roadmap from read-only to autonomous network management runs in three phases, each gated by what the previous phase has established:
Phase 1: Read-only. The agent queries, analyses, and recommends. The human applies changes manually. This phase establishes the trust record: customers observe recommendations, verify them against their own judgment, and calibrate whether the agent’s accuracy justifies elevated autonomy. For alpha users at the Belden CIC, this produced empirical evidence that resolution time for the diagnostic workflows in scope dropped from multi-day to sub-hour timescales.
Phase 2: Deterministic validation layer. Before write operations are enabled, a formal pre-execution check must exist: graph-based topology impact validation, rule-based operational constraint checking, explicit verification that the proposed change does not break any redundancy path currently carrying traffic. Building this correctly is the gate to Phase 3.
Phase 3: Constrained write (semi-auto — 2027 Q1 target). With the validation layer in place and a trust record from Phase 1, the agent can execute configuration changes within the validated boundary. Each phase narrows the scope of what the agent can do wrong.
The business pressure to compress this sequence was real — semi-autonomous networking is a stronger product story than an assistant that only recommends. The boundary held because the preconditions for Phase 3 had not been met, not because the architecture could not support it.
The Generalizable Principle#
In safety-critical agentic systems, two questions are easily conflated: what is the system technically capable of, and what should it be allowed to do at this stage of the trust-earning sequence? The gap is not a product limitation. It is a roadmap.
“Write capability disabled by default, enable when ready” is not the same discipline. That system has no structural guarantee — the path to write capability is a configuration change, and configuration changes get made under deadline pressure. A system whose write capability does not yet exist has a structural guarantee: the precondition for the next phase is a deliberate deployment decision, not a flag flip.
The read-only posture in Digital Coworker is not a UX constraint. It is a boundary that exists in the architecture before the prompt is written.
The organisational reflection on holding this boundary against business pressure is on javatask.systems: The Discipline of Restraint in OT.
The original marker 3 claim — read-only posture as feature, not limitation — is in: What “AI-Native” Actually Means in an Industrial Product.
Marker 3 sharpened under scrutiny at one month: The Four Markers of AI-Native: What Held Up at One Month.
This post is part of the Digital Coworker series.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.