Direct answer

Treat an IoT agent as an untrusted planner operating through narrowly scoped, policy-enforced tools. Give it only the observations and actions required for its assigned workflow. Validate identity, parameters, current state, time window, and risk outside the model on every action. Keep independent safety interlocks in control, and require explicit human approval for high-impact or difficult-to-reverse operations.

An agent’s prompt is not an authorization policy. Neither a persuasive user message nor retrieved context should be able to expand the tools, devices, sites, or parameter ranges granted to the current principal.

Scope and non-scope

This guide covers authority for software agents that inspect telemetry, diagnose incidents, draft changes, or invoke operations on connected devices and supporting services. It addresses capability design, approval, execution, and audit.

It does not explain model training or claim that a language model can certify a physical action as safe. It does not replace device access control, functional-safety systems, change management, or an incident-response process. Emergency stops, hard limits, and protective interlocks must remain independent of the agent and fail safely if the agent or its platform is unavailable.

Use an explicit authority ladder

Assign each workflow the lowest level that produces value:

Level Agent may Example
Observe Read bounded data Summarize alarms for one site
Recommend Propose a typed action Draft a threshold change with evidence
Prepare Validate and stage a change Create a deployment plan without activation
Execute with approval Act after a named approver confirms Restart a gateway during a maintenance window
Execute within policy Act autonomously inside strict limits Retry a reversible data sync three times

Do not collapse read and write authority. An agent allowed to inspect an entire fleet may still be permitted to restart only a single test cohort. Likewise, access to maintenance documents must not imply control access.

Evaluate each proposed action across five criteria: physical impact, reversibility, scope, urgency, and confidence in machine-verifiable preconditions. Reading a log is low impact and reversible. Updating firmware across 10,000 devices has broad scope, delayed consequences, and a complex rollback path; it should pass staged deployment controls rather than a conversational confirmation.

Build the control path outside the model

  1. Authenticate the initiating user or service and derive tenant, role, site, and device scope from trusted identity—not from prompt text.
  2. Expose typed tools, not a general shell. A tool such as restartGateway(gatewayId, reason, changeId) is reviewable; arbitrary command execution is not.
  3. Authorize each call at execution time. Check the principal, resource, action, environment, maintenance window, and current policy version.
  4. Validate parameters against allowlists, units, ranges, and state-dependent preconditions. Reject ambiguous identifiers and implicit unit conversion.
  5. Calculate a risk class deterministically. Route higher classes to a named approver or established change-management workflow.
  6. Re-check state immediately before execution because conditions may have changed during planning or approval.
  7. Execute with idempotency keys, deadlines, bounded retries, and a documented compensation or rollback path.
  8. Record the full decision chain: initiator, observations used, proposed action, policy result, approval, exact tool call, device response, and final outcome.

Approval must bind to a concrete action. “Proceed” should authorize a digest of the target set, parameters, policy version, and expiry—not whatever plan the model produces later. If the plan changes, request approval again.

Evidence and observability

Logs need to remain useful after prompts, models, and tools change. Store stable identifiers for the model and prompt configuration, retrieved source references, tool schema version, policy decision, approval record, and execution result. Avoid storing secrets or unrestricted telemetry inside the reasoning trace; preserve the evidence required for audit while applying retention and access controls.

Monitor attempted actions as well as successful ones. Repeated denials can reveal prompt injection, a broken workflow, stale policy, or an overly broad task. Useful metrics include authorization denials by rule, approval latency, execution failures, rollback frequency, actions per device, and differences between proposed and executed scope.

Failure modes to test

Prompt injection can arrive through operator text, device metadata, logs, tickets, or retrieved documents. Treat all of that as data. It must not alter tool definitions or authority. Test instructions embedded in device names and diagnostic output.

Confused-deputy failures occur when a highly privileged agent acts for a less privileged requester. Preserve the initiating principal through every service hop and enforce resource-level policy at the final executor. Never trust a tenant or device ID supplied only in the model’s arguments.

Race conditions appear when approval is granted for one state and execution occurs in another. Use short approval expiry, optimistic state versions, and a final precondition check. Partial execution must be visible: if three of ten devices restart, report the exact three rather than describing the operation as failed or complete.

Also test tool timeouts, duplicate calls, delayed responses, policy-service failure, revoked credentials, unavailable approvers, emergency-stop activation, and audit-store outage. Default to no new high-impact action when authorization or evidence systems are unavailable.

Implementation checklist

  • Each workflow has a documented authority level and resource scope.
  • Read, recommendation, approval, and execution permissions are separate.
  • Tools are typed, allowlisted, parameter-bounded, and free of general shell access.
  • Authorization uses trusted identity and is enforced at the final action boundary.
  • High-impact approvals bind to exact targets, parameters, and an expiry.
  • Execution is idempotent and has bounded retries plus rollback or compensation.
  • Independent interlocks and emergency controls can override the agent.
  • Audit records connect evidence, policy, approval, tool call, and outcome.
  • Adversarial tests include prompt injection, stale state, duplicates, and partial failure.

Primary sources

Use NIST AI RMF 1.0 to structure governance, mapping, measurement, and management of AI risk. The NIST IoT device cybersecurity baseline covers device identification, logical access, secure configuration, data protection, software update, and state awareness. For authorization terminology and control objectives, consult NIST SP 800-53 Rev. 5. These sources establish risk and security baselines; the equipment’s applicable safety standards remain authoritative for physical control.