Deployment posture
Security review ofAgenticGrid Pro
The workbench installs inside your perimeter, opens no inbound path to the OT network, and makes outbound calls only for the generative features you configure.
Deployment
Local-first, on one workstation
AgenticGrid Pro is a Windows desktop application. It installs on a standard engineer workstation inside your perimeter, with no application server to stand up, no database to host, and no hosted tenancy holding your evidence. Records live where they are loaded.
That shape is the reason a security review of this product is tractable. There is one host, one local data store, one optional outbound path, and no listening service exposed to your operational network. Most of the review is about which evidence is approved for the workstation and who the named reviewers are — not about network architecture.
The controls
What the posture commits to
- No inbound OT connection
- There is no path from AgenticGrid Pro into protection, control, RTU or SCADA systems, and no mechanism by which the workbench can command, configure or write to operational equipment. It reads files.
- Controlled outbound egress
- Network calls occur only for generative features the operator requests, to the provider you configured, carrying the context approved for that operation. The credential, proxy path and provider data policy are yours to review and approve.
- No autonomous action
- AI output is draft material until a named engineer approves, edits, rejects or escalates it. The software takes no operational action and holds no final authority.
- Telemetry off
- Product telemetry is off. If any error or usage monitoring were ever enabled, it would be disclosed and consented separately, with query strings, form values, request and response bodies, headers, cookies, tool inputs and customer evidence redacted.
- Data minimisation
- A deployment uses the minimum evidence needed for the workflow under evaluation. Confidential evidence is not sent to hosted services unless the deployment profile explicitly permits it.
- Traceability by construction
- Findings preserve source evidence, assumptions, reviewer state and audit history, so an incident review can reconstruct what was known and who decided what.
Data handling
One ledger, agreed before evaluation
Evidence enters through agreed channels keeping its source and provenance, lives on the workstation inside your perimeter, is reviewed by a named engineer whose every state change is logged, and at the end of an engagement is returned or deleted to the schedule agreed at scoping. The decision record remains auditable inside the evidence pack that is handed over.
Retention is a scoping decision rather than a product default, and the terms are written down before technical evaluation begins. Business-contact and website-analytics data are kept entirely separate from transformer evidence used in technical work.
For reviewers
The security review checklist
Work through these before evaluation. Each one has a short, documentable answer.
- Confirm the deployment target: which Windows workstation, inside which network zone, under whose administration.
- Confirm there is no inbound route from the workbench to the OT network, and that no operational system is configured to accept a connection from it.
- Decide whether generative features are enabled at all, and record the decision.
- If enabled, identify the provider (OpenAI, Anthropic, or both), the account that owns the credential, and the provider data-use and retention terms that will apply.
- Approve the outbound path: proxy or egress route, destination hosts, and whether the call is permitted from that network zone.
- Decide whether retrieval uses provider embeddings or deterministic local feature hashing, and record the trade-off accepted.
- Confirm how the provider credential is stored on the workstation and who can read it.
- Define the approved evidence scope: which assets, which streams, which date range, and what is explicitly out of scope.
- Classify the sensitivity of that evidence and confirm it may reside on the chosen workstation.
- Name the engineer-reviewers authorised to sign off, and confirm how their identity is established in the log.
- Agree retention, deletion, export and return terms in writing, including what happens at close-out.
- Confirm telemetry state and that no monitoring is enabled without separate disclosure and consent.
- Review the audit-log contents against your own evidentiary requirements for maintenance decisions.
- Agree the escalation path for a disputed or withdrawn approval.
- Confirm that no autonomous control, protection setting or switching capability is in scope — and that the contract says so.
Documentation
What to send your security team
Security and deployment
The deployment model, the controls a pilot runs under, and what security and engineering teams define first.
Trust and responsible AI
The governance quadrant, the human gate, and the audit-trail commitments.
Data handling
The data lifecycle, the retention posture per category, and what we never see.
Procurement pack
Reviewer-facing documents: security summary, RFP material and the pilot brief builder.
The other GridAPM product
GridAPM also builds ProtectionAI
ProtectionAI
Protective-relay testing, settings management and reporting in one Windows workspace, with an agentic AI copilot that works to your approval.
Put your own evidence through the workflow
A bounded evaluation starts with the records you already have and ends with an evidence pack your reviewers can inspect line by line. Your units, your engineers at the gate.