AI Agent Governance for Medical Device Field Service

Why Field Service AI Agents Create a New Governance Problem

Medical device manufacturers are introducing AI agents to help field technicians diagnose faults, retrieve service history, interpret error codes, and initiate parts orders. These agents often need access to diagnostic logs, device configuration data, and service records that are subject to quality system recordkeeping requirements under 21 CFR Part 820. No FDA guidance currently addresses AI agents specifically in this context. Existing device cybersecurity guidance and quality system regulation apply generally to any software touching regulated device data, which means organizations must extend those frameworks to cover agent behavior rather than wait for agent-specific rules.

The governance gap is architectural, not just regulatory. A field service AI agent typically operates across multiple trust boundaries: the technician's device, the agent runtime, backend diagnostic systems, and parts ordering platforms. FDA's premarket cybersecurity guidance describes a trust boundary approach requiring authentication and authorization wherever data or commands cross between systems of differing trust levels. An AI agent moving between field tooling and regulated device data systems constitutes exactly this kind of boundary, and it requires explicit controls rather than inherited trust from the technician's own credentials.

Agent Identity Must Be Distinct From the Technician

A common architectural mistake is treating the AI agent as an extension of the technician's login session, with no separate identity or audit trail. This collapses accountability: if the agent takes an action, such as pulling a diagnostic log or drafting a parts order, the system cannot distinguish what the technician directed from what the agent executed autonomously.

Agent identity should be cryptographically verifiable and scoped independently of the human operator, consistent with the zero trust principles in NIST SP 800-207, which call for per-session access decisions based on identity and least-privilege policy rather than static, session-level trust. In a field service context, this means the agent presents its own credential when calling a diagnostic tool or requesting servicing data, and that credential is evaluated against a defined permission set before the call is allowed to proceed. The technician's identity remains attached to the interaction for accountability, but the agent's identity is what governs what it is technically permitted to do.

Runtime Enforcement, Not Just Policy Documentation

Written policy describing what an agent is allowed to do is not the same as runtime enforcement of that policy. Session-level authorization, where an agent is granted access at the start of a task and retains that access for the duration, creates risk if the agent's behavior drifts or if a tool call falls outside its intended scope partway through a task.

The Model Context Protocol, used by many agent platforms to connect AI systems to external tools, defines an OAuth 2.1-based authorization flow for establishing agent-to-tool connections. This provides a foundation for authentication, but the base protocol has historically left fine-grained, resource-level permission enforcement and tool-call auditing to the implementer. For regulated field service use, this means organizations cannot rely on default MCP authorization behavior alone. They need to layer resource-scoped permission checks and logging on top of the protocol's authorization flow, validating each tool invocation against defined scopes rather than trusting a single authorization event for the entire session.

Auditability Requirements for Regulated Service Records

Under 21 CFR Part 820, manufacturers must maintain device history records and service records documenting servicing activities on regulated devices. When an AI agent assists with diagnostics or retrieves service history, the resulting actions need to be traceable in a way that satisfies these recordkeeping obligations.

A usable audit log for AI agent tool calls should capture five elements: the agent's identity, the human operator who invoked or approved the action, the specific resource or tool requested, the permission scope evaluated at the time of the call, and the outcome. OWASP's 2025 guidance on agentic AI security identifies insufficient tool-call logging and lack of identity binding between agent actions and human operators as primary risk categories for autonomous agents, which aligns directly with the recordkeeping gap in field service environments. Logs also need to be immutable and retained consistent with device history record retention timelines, and ideally integrated into existing quality management system documentation rather than kept in a separate, disconnected system.