otgate — OT policy gateway

otgate

An OT-aware authorization gateway that sits between an LLM agent and an industrial OPC UA server, applying a process-aware access policy — value ranges, rate limits, interlocks — to every call the agent makes.

Русская версия →

[MCP client / agent] ---MCP---> [otgate] ---OPC UA---> [OPC UA server]

| [policy engine + audit + shadow mode]

The same decisions as terminal output ( python examples/demo.py )

otgate is itself an MCP server. The agent connects to it as if it were an ordinary OPC UA MCP; internally otgate holds a client to the real OPC UA server. Every call is transparent to the agent, and otgate intercepts each one to apply policy and record an audit line.

Why

• Existing OPC UA MCP servers write to tags with no authorization layer — the agent has full, unbounded access.
• Existing LLM guardrails (LlamaFirewall, NeMo Guardrails) work on text/prompts and do not understand process semantics — they know nothing about ranges, rates of change, or interlocks.
• otgate closes exactly that gap: OT semantics + admission policy + audit.

It is not "you may write to this tag" but "you may write *within range X, no faster than Y over interval Z, and only while the emergency tag W is not active*".

Where this fits: OWASP ASI02

In the OWASP Top 10 for Agentic Applications, the risk otgate targets is ASI02 — Tool Misuse & Exploitation: an agent that stays inside its granted privileges but uses a legitimate tool unsafely — parameter pollution, excessive execution, or a call that is only dangerous given the current system state.

Identity and access layers (ASI03) answer *may this agent call this tool*. They do not look at what it writes, how fast, or under which conditions. otgate is the layer that does:

Per-step limits judge one write; cumulative limits judge a *series*. Without the latter an agent walks around max_rate with many small legal steps:

step 1: 50.0 -> 52.5  (drift  +2.5)  ALLOW

step 2: 52.5 -> 55.0 (drift +5) ALLOW step 3: 55.0 -> 57.5 (drift +7.5) ALLOW step 4: 57.5 -> 60.0 (drift +10) ALLOW step 5: 60.0 -> 62.5 (drift +12.5) DENY cumulative drift too large: 62.5 is +12.5 from 50, allowed [-10, 10]

A full mapping against all ten OWASP agentic risks — including what otgate explicitly does not cover (tool-chain manipulation, goal hijacking, memory poisoning, rogue-agent detection) — is in [docs/threat-model.md](docs/threat-model.md).

Install

pip install -e .           # core: FakeBackend, engine, MCP server

pip install -e ".[dev]" # + pytest for the test suite pip install -e ".[opcua]" # + asyncua for a real OPC UA backend

Python 3.11+.

Policy example

A policy is a YAML list of per-tag rules. Any tag not listed is denied by default.

# examples/reactor_policy.yaml

• tag: "ns=2;s=Reactor.TIC101.PV" # temperature, read-only access: read

• tag: "ns=2;s=Reactor.TIC101.SP" # temperature setpoint access: write_with_approval # writes need human approval (ASK) value_range: [40, 80] # only within 40..80 degC cumulative_range: [-10, 10] # ... and no more than 10 degC total drift cumulative_interval: 3600 # from where it stood an hour ago max_rate: 5 # no faster than 5 degC ... rate_interval: 60 # ... per 60 seconds interlocks:
• tag: "ns=2;s=Reactor.ESD" # blocked while emergency shutdown ... condition: "== true" # ... is active action: deny

Access levels: read, write, write_with_approval, deny.

Write check order (first failing check wins): tag-in-policy → access → value range → interlocks → rate of change → approval → allow.

Demo

python examples/demo.py

otgate demo — agent interacting with a reactor via the policy gateway

read temperature (PV) ALLOW read allowed -> 55.0 write setpoint = 60 degC (in range) ASK write requires human approval write setpoint = 200 degC (out of range) DENY value 200.0 is outside allowed range [40.0, 80.0] write setpoint = 60 degC while ESD active DENY interlock active: ns=2;s=Reactor.ESD == True (current ns=2;s=Reactor.ESD = True) write setpoint = 78 degC one second later DENY rate of change too high: |78.0 - 50.0| = 28 in 1s exceeds 5 per 60s

audit log

{"timestamp": "...", "action": "read", "node_id": "ns=2;s=Reactor.TIC101.PV", "value": null, "decision": "ALLOW", "reason": "read allowed", "shadow": false, "executed": true} {"timestamp": "...", "action": "write", "node_id": "ns=2;s=Reactor.TIC101.SP", "value": 60.0, "decision": "ASK", "reason": "write requires human approval", "shadow": false, "executed": false} {"timestamp": "...", "action": "write", "node_id": "ns=2;s=Reactor.TIC101.SP", "value": 200.0, "decision": "DENY", "reason": "value 200.0 is outside allowed range [40.0, 80.0]", "shadow": false, "executed": false} {"timestamp": "...", "action": "write", "node_id": "ns=2;s=Reactor.TIC101.SP", "value": 60.0, "decision": "DENY", "reason": "interlock active: ns=2;s=Reactor.ESD == True (current ns=2;s=Reactor.ESD = True)", "shadow": false, "executed": false} {"timestamp": "...", "action": "write", "node_id": "ns=2;s=Reactor.TIC101.SP", "value": 78.0, "decision": "DENY", "reason": "rate of change too high: |78.0 - 50.0| = 28 in 1s exceeds 5 per 60s", "shadow": false, "executed": false}

Run as an MCP server

Published to the official MCP Registry as `io.github.alikup-ai/otgate-opcua`, and to PyPI as `otgate`.

The registry name carries opcua because its search matches on the server name only and does not index

descriptions, so a bare otgate is findable only by someone who already knows the word.

otgate exposes: read_tag, write_tag, browse, get_audit_log, and the operator approval tools list_pending, approve, deny.

otgate                      # console script (stdio transport)

python -m otgate.server # equivalent

Configuration is via environment variables (so the backend switches without code changes):

Example MCP client config (FakeBackend):

{

"mcpServers": { "otgate": { "command": "otgate", "env": { "OTGATE_BACKEND": "fake" } } } }

Related work: the layer underneath

otgate governs what the process allows right now — ranges, rate against the live value, interlocks, drift, approval. It does not try to be the access layer underneath that, and there is a good one: IndustriAgents/OPCUA-MCP answers *may this caller touch this node at all* — read-only by default, control profiles, allowlisted targets, pinned certificates, audited control calls.

The two questions are genuinely different. A write of 40 °C to an allowlisted target satisfies every access rule and is still wrong if the tag reads 22 °C and the ramp violates a thermal limit. Access control without process limits permits that write; process limits without access control have nothing to stand on.

A visible difference in the audit trail shows the split: their acceptance criteria require records to carry profile, tool, decision and target IDs without values, which is right for an access log. otgate records the value, because "200.0 refused, outside [40, 80]" is not a sentence you can write without it.

Connecting a real OPC UA server

No code changes — install the extra and point the config at your server:

pip install -e ".[opcua]"

export OTGATE_BACKEND=asyncua export OTGATE_OPCUA_ENDPOINT=opc.tcp://localhost:4840 otgate

The backend lives behind an abstract interface (otgate/backends/base.py) with two implementations — FakeBackend (in-memory simulator, no dependencies) and AsyncuaBackend (real OPC UA). asyncua is imported lazily, so the fake backend, the tests and the demo run without it.

Shadow mode

With OTGATE_SHADOW=1, a write that the engine allows is not executed on the backend — instead the audit records a "WOULD execute" line with executed: false. This lets you run an agent and see what it *would* do to the process without any real effect.

Human approval workflow

A write_with_approval tag returns ASK. Rather than silently drop the write, otgate parks it as a pending request with a TTL and hands the agent an approval id. A human then resolves it through the operator tools:

• list_pending — show parked write requests.
• approve — approve and execute, *after re-checking policy* against the current process state. If an interlock tripped or the value drifted out of range while the request waited, the approval is recorded but the write is blocked — an approval is intent, never a blind execute.
• deny — reject; the write never runs.

Requests