How Should Field-Service Teams Authorize AI Agents for OT Systems?

Direct Answer for OT

Field-service organizations should authorize AI agents separately from human technicians, even when an agent is initiated by a named employee. Human identity establishes accountability, but it does not automatically prove that an AI process is permitted to read a particular asset, change a controller, bypass an interlock, or contact an external service. The defensible model assigns each agent a cryptographically verifiable identity, limits it to a narrowly defined task, and checks every consequential action at runtime. For OT, authorization should be based on the requested action, target asset, operating state, safety policy, and current conditions—not merely on the identity of the user who started the workflow. This matters because industrial systems combine legacy protocols, vendor-specific engineering tools, long-lived credentials, and production availability constraints. A successful login by a contractor should not silently become unrestricted control of a pump drive or safety system. A practical target is least privilege at the action and resource level, short-lived credentials, recorded decisions, immediate revocation, and human approval where safety, compliance, or production impact warrants it. The agent may help dispatch, collect readings, summarize alarms, prepare a work order, or recommend a diagnosis, but the authorization envelope must state exactly what it may do without further confirmation.

Also worth reading: How Is AI Field Service Automation Transforming Dispatch and Diagnostics? · Which Field Service AI Metrics Should Businesses Track in 2026? · How Can SMBs Automate Field Service With AI Without Losing Control?

Authorization is especially difficult in OT because “identity” is only one part of the decision. A technician may be authenticated with multifactor authentication and still lack permission to energize equipment outside an approved maintenance window. A monitoring agent may be allowed to query a historian but not a programmable logic controller; a diagnostic agent may retrieve a fault code but not download logic; and a parts agent may update a service record but not place an order above a defined dollar limit. NIST and CISA guidance on token security reflects the broader shift toward continuously evaluated access rather than treating possession of a long-lived token as sufficient proof. Commercial frameworks such as Spiffe, SPIFFE/SPIRE, Pomerium, Tenuo, and emerging agent-authorization protocols all point toward workload identity, capabilities, and policy enforcement, although their maturity and applicability differ. OT teams should adopt the principles while testing each product against actual safety and availability requirements.

How Agent Authorization Should Work

A sound OT agent-authorization flow begins when a dispatch system, employee, monitoring event, or approved integration creates a job. The system issues a short-lived workload identity representing the specific agent, version, tenant, and intended function. A policy decision point then evaluates the human sponsor, device posture, agent provenance, requested task, target asset, action type, operating mode, environmental context, and token freshness. The decision may permit, deny, redact, downgrade, step down, or require human approval. For example, the system could allow a service agent to read drive temperature but replace the return value only after a supervisor approves the work order. The agent should receive a capability bounded by time, asset, method, and number of operations rather than a reusable bearer credential with broad plant access.

Every subsequent tool call should be checked rather than trusting a broad session created at the start. If an agent begins by reading a PLC diagnostic buffer, an external call should not automatically grant it permission to write a register. This “every action” requirement is important because planning models can choose an unexpected sequence, integrations can expose hidden tools, and compromised dependencies can turn a read-only workflow into a production command. Short sessions of 5 to 15 minutes are often a reasonable starting point for sensitive actions, but there is no universal lifetime. A low-risk historian query might use a 30-minute identity, while a command could require a 60-second credential, one approved action, and no replay. A denial or unusual action should generate an audit record containing the policy version and reason without recording secrets or sensitive plant data. The control plane should fail safely: a loss of the authorization service should not grant access, and in a safety-critical environment it should normally leave equipment in its existing state rather than block a protective function.

The decision should be explainable in operational language. An operator needs to know that “write denied because this agent lacks a valid work-order permit” is more useful than “policy 47 failed.” Audit records should also distinguish the initiating employee, the agent workload, the delegated decision, the model or tool involved, and the human who approved an exception. That separation supports incident response and nonrepudiation without pretending that the language model is an accountable person. Agent identity, authorization, and safety control are related but different concerns. Authentication answers who or what is calling; authorization answers whether that caller may perform this action here and now; safety engineering determines whether the resulting physical state is acceptable.

Why Traditional RBAC Is Not Enough for AI Agents

Role-based access control remains useful for coarse assignments, but static job titles do not adequately describe an AI agent’s dynamic behavior. A field technician may need read access during diagnosis, temporary write access during a test, and no write access after work is completed. One technician may also cover several sites with different equipment ownership, vendor policies, and contractual restrictions. A static role such as “OT engineer” would either be too broad for security or so narrow that administrators would routinely create exceptions. Agent workflows also cross systems: dispatch, asset management, CMMS, historians, vendor clouds, identity providers, remote-support gateways, and the control network. Each transition can change the trust context.

Capabilities, attributes, and policy-based controls address more of that variation. A capability can state that this particular diagnostic run may read tags from asset PLC-17 for 20 minutes. Attributes can restrict the request to an approved work order, a maintenance state, a trusted site network, and a verified contractor training record. Policy can require a second person for safety PLC changes, production-impacting writes, or access outside business hours. Attribute-based access control is not automatically safe, because attributes can be stale, overpopulated, or incorrectly sourced. Capability-based systems reduce some wildcard-permission problems, but capability theft, confused-deputy behavior, and incorrect delegation still require strong issuance and enforcement. OT security leaders should therefore treat “capability-based” as a design property rather than a product category that removes the need for policy.

A further problem is that the agent identity may be static while its behavior is probabilistic. The identity proves that the workload is the workload it claims to be; it does not prove that a generated command is correct. Runtime controls should also limit tools, constrain parameters, validate results, prevent arbitrary code execution, and provide a deterministic policy layer outside the model. Cryptographic workload identity, including the SPIFFE model for service identity and SVIDs through compatible systems, can prevent a copied username or unmanaged API key from being accepted. The cryptography only authenticates the workload, however. It does not judge whether the requested operation is safe, so teams should not equate signed identity with authorization or with trustworthy output.

Practical Implementation for Field-Service AI

The first implementation step is to inventory workflows and rank them by consequence. Start with low-risk tasks such as summarizing maintenance history, matching an error code to an approved article, checking whether a part is in stock, and drafting a work plan. Give the agent no direct route from those tasks to a controller write. Next, identify the systems that can enforce policy and distinguish advisory data from command paths. A read-only replica, historian, or gateway may be safer than the engineering workstation itself. Segregate credentials and network paths so that a prompt-injection message in an email or CMMS note cannot inherit dispatch-system privileges. Sensitive instructions found in retrieved documents should be treated as untrusted data rather than as new authorization.

Define a small set of measurable controls before deployment. A sensible pilot might cover 10 to 25 technicians, 2 to 3 sites, and no more than 3 read-only workflows, with a 30- to 90-day observation period. Useful thresholds include 100% of agent actions tied to a logged identity, zero standing production-write credentials, under 1 minute for high-risk credential lifetime, and revocation completed within 5 minutes for terminated or compromised workloads. For commands, record whether the target was in the expected maintenance mode and whether the preconditions passed. Review false grants, false denials, approval rates, expired credentials, anomalous tool calls, and attempts to cross from IT into OT. A 95% task-completion rate is not a useful security success metric if unauthorized attempts were simply excluded from the denominator.

Human approval should be selective rather than ceremonial. Requiring a technician to click through every sensor query adds friction without reducing meaningful risk. Approval becomes more valuable for writes, safety-system interaction, credential changes, external data transfer, or actions outside a defined maintenance window. The approval interface should show the exact target, operation, parameters, expected state change, and reason, rather than merely saying “Allow AI agent.” High-frequency controls may use two-person authorization, deterministic interlocks, or simulation. The agent must never be permitted to approve its own request or alter the policy used to judge that request. Emergency access should be separately issued, time-limited, strongly audited, and tested periodically; “break glass” is not a substitute for normal least-privilege design.

Comparison of Authorization Approaches

No single approach covers authentication, dynamic policy, delegation, safety, and audit requirements equally well. Many OT teams will combine a human identity provider with workload identity, gateway enforcement, and deterministic controls at the control-network boundary.

Commercial agent gateways can add policy evaluation, session recording, and agent-specific identity controls. A zero-trust access proxy may be valuable when agents connect through web applications, while a purpose-built agent authorization protocol may suit cross-vendor delegation. Spiffe and SPIFFE/SPIRE provide a mature foundation for cryptographically verifiable workload identity, but they are not complete OT authorization systems. macaroon-style capabilities can be attenuated and delegated, yet recipients still need an appropriate verifier and revocation strategy. DIY policy in an AI orchestration layer is acceptable for a pilot, but it should not become the only control because application logic can be bypassed by another tool or integration. A layered design is usually stronger than selecting a fashionable protocol name.

Costs, Product Claims, and Operational Tradeoffs

Pricing is not standardized because agent authorization may be bundled into identity and access management, remote access, API security, service mesh, or a specialized authorization service. Open-source components such as SPIFFE/SPIRE are free to use, but infrastructure, engineering time, certificate lifecycle management, support, and OT testing still have real costs. Commercial products may be sold per user, agent, workload, connection, policy decision, or gateway; some will quote custom enterprise pricing, so a vendor should not be assumed to cost a particular monthly amount without a current quote. A small read-only pilot can sometimes be built with existing IAM and gateway licenses, but that does not mean it is inexpensive. A production OT design may require redundant policy services, high-availability connectivity, immutable logs, safety reviews, and 24/7 operations.

The main cost is often process redesign rather than license fees. Organizations must classify assets, document actions, issue machine identities, change service accounts, test failure modes, and decide who can approve exceptions. Legacy equipment may not support modern identity protocols, forcing access through a monitored jump host or industrial DMZ. Workstations and vendor tools may require a gateway that understands proprietary sessions. Some gateways marketed for “agentic access” may still rely on static API keys or user impersonation, and some authorization protocols may not yet have broad OT interoperability. Buyers should ask whether the product can enforce per-action decisions, support non-HTTP protocols, deny by default, expose a read-only mode, operate during network failure, and produce evidence an auditor can use.

Build versus buy should be based on enforcement coverage and organizational capability. Buy when the required policy and gateway functions are available and the vendor can demonstrate them against representative OT equipment. Build only when no supported product can enforce the necessary boundary, and place the custom component in a narrow intermediary rather than inside the PLC or safety controller. Neither decision removes the need to keep current asset inventories and approved maintenance windows. A claimed 99.9% or 99.99% control-plane availability does not guarantee safe operations if the agent can bypass that plane through another route. Conversely, a fully automatic authorization service is unnecessary for a documentation-only workflow. The appropriate spending level should correspond to consequence, connectivity, and regulatory exposure rather than the novelty of AI.

Common Mistakes and When Teams Should Act

A common mistake is giving the AI the same account as the technician who opened the work order. That collapses human accountability, machine identity, and delegated authority into one secret. Another is authorizing an entire session after one broad consent screen, even though the agent can later call unexpected tools. Others use prompt instructions as security controls, trust content retrieved from manuals or emails, or expose a maintenance login directly to a cloud model. Prompt injection is a real threat because external text can influence tool use, but a stronger system removes tool authority from the text and verifies the action independently. Teams also make the mistake of beginning with autonomous writes. That produces impressive demonstrations while providing poor evidence that the authorization model works under maintenance pressure.

Organizations should act before deploying any agent that can access production telemetry, remote support, sensitive customer records, or control-system engineering tools. Waiting for a formal “AI program” is unnecessary; these are access-control and segmentation decisions. A 30-day inventory and policy workshop can identify workflows, while a 60- to 90-day read-only pilot can test identity issuance, logging, revocation, and workflow integration before any write path is considered. Any incident involving stolen credentials, unauthorized vendor access, unexplained PLC changes, or a compromised technician account warrants immediate containment: revoke the associated tokens, terminate sessions, preserve logs, review target systems, and determine whether the agent’s scope was correctly bounded. Post-incident analysis should test whether the failure came from identity, authorization, network reachability, unsafe output, or the underlying asset configuration.

The best time to adopt runtime authorization is when a pilot already shows operational value but controlled scaling is blocked by broad access. Waiting until hundreds of agents operate makes policy debt harder to unwind. Teams should not act merely because peers announce an agentic product, however, and should avoid purchasing a control plane that cannot operate with their actual systems. A field-service deployment that only drafts a technician note may need no gateway at all; a tool that commands a live variable-speed drive needs much stronger technical and safety review. The correct conclusion is not that every agent needs a novel authorization protocol. It is that every consequential agent needs a bounded, attributable, revocable authority—and OT teams should introduce that authority before granting the agent a path to act.

Recommended OT Authorization Baseline

The baseline is straightforward: identify the agent with a cryptographically verifiable workload credential; bind access to one customer, site, asset class, task, and approved operating state; issue credentials for minutes rather than months; and evaluate each sensitive call at the enforcement point. Remove standing shared accounts, including “break-glass” credentials that normally remain active. Place agents behind gateways or policy-enforcement points with explicit allowlists, and use separate pathways for telemetry, control, and external communication. Log the sponsor, agent identity, workload version, action, target, decision, policy version, approval, and outcome. Test replay, token theft, stale work orders, prompt injection, tool substitution, gateway outage, revocation, and accidental scope changes.

For many field-service organizations, the sensible first production objective is authorizing AI for dispatch, diagnostics, and service automation without allowing autonomous plant actuation. The agent can collect readings, compare them with approved documentation, identify likely causes, create a draft work order, request a part, and prepare a human-readable escalation. It should not download PLC logic, change safety parameters, bypass an interlock, or write to a live controller without a separately engineered control and approval path. This boundary allows organizations to measure authorization quality and operational usefulness at the same time. The agent becomes useful because its access is specific, not because it has been made broadly powerful. As confidence and safety evidence accumulate, controlled write scopes can be introduced, but the goal should remain explicit authority: every machine action is attributable, time-bound, policy-checked, and limited to what the organization would safely permit for a trained human operating under the same conditions.