GxP Agent Control Standard / v0.1 / June 2026

gxp.md

A control standard for governed AI agents used in GxP, quality-system, data-integrity, governance, and evidence-generating workflows.

StatusWorking draft
ScopeAgentic AI systems
Conformance testEvidence-backed

Contents

0.0Abstract 1.0Background 2.0Applicability and Attestation 3.0Control Domains 4.0Disqualifying Deficiencies 5.0Evidence Requirements AAppendix
0.0

Abstract

AI agents can retrieve regulated knowledge, generate controlled content, invoke tools, use credentials, and trigger workflows. These capabilities introduce control requirements that are not fully addressed by prompt review or model testing alone.

Existing computerised-system validation, electronic-record, software-assurance, quality-risk, and AI-governance frameworks remain applicable. This standard defines additional requirements for agent-specific failure modes: runtime drift, wrong-source grounding, memory poisoning, model-mediated tool use, delegated credentials, human authorization, and audit reconstruction.

Conformance requires evidence. Self-attestation without supporting telemetry, reviewed architecture, test results, runtime records, and approval history is not sufficient.

1.0

Background

An AI agent is a software system whose behavior is shaped by model, prompt, runtime context, memory, tools, identity, credentials, and orchestration. The model is one component. The harness is the controlled system.

1.1

Controlled Boundary

The assessed boundary must include the agent manifest, model policy, system instructions, toolset, skills, memory stores, credential vaults, external connectors, channel identity, approval gates, logs, and automation runners.

1.2

Change Sensitivity

Changes to model, prompt, tools, memory, vaults, connectors, channel routing, or approval policy must be treated as controlled changes where they can affect regulated or quality-critical use.

1.3

Evidence Standard

Evidence must be generated from the operating platform wherever possible. Manual narrative without runtime records is not sufficient for high-risk use.

2.0

Applicability and Attestation

This standard applies where an agent performs, supports, or materially influences GxP, quality-system, governance, legal, data-integrity, release, supplier, or evidence-generating work.

2.1

In Scope

Agents are in scope when outputs or actions may affect controlled records, regulated decisions, audit evidence, release state, supplier controls, governance actions, or credentialed systems.

2.2

Attestation

Vendors and operators must produce evidence for each applicable control domain. Unsupported self-attestation is not acceptable.

2.3

Complementary Controls

This standard is additive to Part 11, Annex 11, FDA CSA, GAMP 5, ICH Q9, ISO/IEC 42001, NIST AI RMF, OWASP LLM guidance, and supplier QMS controls.

3.0

Control Domains

Each control domain contains a control objective, required controls, and disqualifying deficiencies. Point-in-time review is insufficient where the agent is operated continuously.

ACS-0

Intended Use, Ownership, and Risk Classification

Design

Control objective

Vendors and operators must maintain a living inventory of all agent systems, approved uses, prohibited uses, owners, autonomy levels, and risk classifications.

Required controls

  1. ACS-0.1 Each live agent must have an approved intended-use statement and prohibited-use boundary.
  2. ACS-0.2 Each live agent must be assigned a risk class covering GxP, patient safety, privacy, legal, financial, governance, and data-integrity impact.
  3. ACS-0.3 Each live agent must have named business, technical, and quality owners.
  4. ACS-0.4 The inventory must preserve current and prior runtime and release status.
An implementation fails this control domain if any live agent lacks intended use, prohibited-use boundary, owner, risk class, or current lifecycle state.
ACS-1

Controlled Runtime Configuration

Runtime

Control objective

Vendors and operators must prove that the observed runtime matches an approved desired state across model, instructions, tools, skills, memory, vaults, connectors, and channel identity.

Required controls

  1. ACS-1.1 The desired runtime must be represented by deterministic configuration and profile hashes.
  2. ACS-1.2 Approved runtime state must include model policy, system instructions, tool allowlist, memory bindings, vault bindings, connector policy, and channel identity.
  3. ACS-1.3 Runtime reconciliation must compare approved state with live state on a defined cadence.
  4. ACS-1.4 Unsafe network posture, unknown external connectors, and broad unapproved tools must block execution for high-risk agents.
An implementation fails this control domain if a controlled agent can execute with unmanaged drift, unsafe environment posture, missing vaults, or unknown tools.
ACS-2

Source, Memory, and Knowledge Integrity

Runtime

Control objective

Vendors and operators must control the sources from which an agent answers and the memory stores from which it learns.

Required controls

  1. ACS-2.1 Each source-sensitive agent must have an approved source hierarchy.
  2. ACS-2.2 Source-critical memory must be attributable, versioned, hash-tracked, and read-only unless write access is explicitly approved.
  3. ACS-2.3 Learning, dream, or improvement outputs must be review-required before promotion to approved memory.
  4. ACS-2.4 Source-gated responses must cite source class or state uncertainty when the approved source is unavailable.
An implementation fails this control domain if a controlled agent can use unapproved memory, wrong-domain knowledge, or unverifiable source material for regulated output.
ACS-3

Tool Use, Action Boundaries, and Human Authorization

Assurance

Control objective

Vendors and operators must distinguish auditable internal tool use from controlled external action, and must route human authorization where accountability is required.

Required controls

  1. ACS-3.1 Actions must be classified as internal, advisory, draft-generating, externally visible, record-changing, or regulated.
  2. ACS-3.2 Internal tool use must be logged and governed, but must not require manual approval unless it creates a consequential action.
  3. ACS-3.3 Controlled actions must require routed authorization from an eligible user or role.
  4. ACS-3.4 Signer, role, actor, and approval authority must be derived from authenticated identity, not client-supplied fields.
An implementation fails this control domain if a user can self-assert authority, bypass an approval gate, or cause a controlled action without authorized approval.
ACS-4

Validation, Evaluation, and Release Evidence

Assurance

Control objective

Vendors and operators must validate agent behavior against intended use, source grounding, permission boundaries, tool behavior, and adversarial inputs before high-risk release.

Required controls

  1. ACS-4.1 Each controlled agent must have an eval pack mapped to intended use and risk class.
  2. ACS-4.2 Eval packs must include happy-path, edge-case, negative-permission, wrong-source, and prompt-injection scenarios.
  3. ACS-4.3 Material changes to model, prompt, tools, memory, vaults, connectors, or approval policy must trigger regression evidence.
  4. ACS-4.4 Release evidence must include test results, deviations, approvals, runtime hashes, and evidence-package metadata.
An implementation fails this control domain if controlled agent changes reach live use without validation evidence and approval attestation.
ACS-5

Runtime Monitoring, Audit, and Data Integrity

Operations

Control objective

Vendors and operators must maintain attributable, contemporaneous, tamper-evident records of agent operation and controlled actions.

Required controls

  1. ACS-5.1 Logs must capture actor, tenant, timestamp, input class, runtime version, tool calls, approvals, output, and resulting action.
  2. ACS-5.2 Audit records must be protected from silent modification and support reconstruction of regulated outputs.
  3. ACS-5.3 Usage, cost, error, refusal, and guardrail events must be retained for operational review.
  4. ACS-5.4 Evidence exports must preserve source, actor, time, runtime, approval, and event context.
An implementation fails this control domain if regulated outputs or actions cannot be reconstructed from audit records.
ACS-6

Incident Response, Quarantine, and Change Control

Operations

Control objective

Vendors and operators must be able to disable, rollback, quarantine, investigate, and retire agent systems without losing evidence.

Required controls

  1. ACS-6.1 Unsafe agents must be disableable across chat, API, channel, workflow, and scheduled execution paths.
  2. ACS-6.2 Runtime rollback must restore a known approved configuration.
  3. ACS-6.3 Memory stores, connectors, and credentials must support quarantine and revocation.
  4. ACS-6.4 Incidents must retain affected sessions, outputs, approvals, runtime state, and remediation decisions.
An implementation fails this control domain if an unsafe or compromised agent cannot be promptly disabled from all active execution paths.
ACS-7

Supplier, Tenant, and Platform Governance

Operations

Control objective

Vendors and operators must govern tenancy, IAM, model providers, connectors, credential vaults, deployment environments, and scheduled automation.

Required controls

  1. ACS-7.1 IAM must enforce tenant isolation and least privilege for human and service identities.
  2. ACS-7.2 Model, connector, and MCP suppliers must be qualified for intended use.
  3. ACS-7.3 GxP and non-GxP service credentials must be segregated and stored in governed vaults.
  4. ACS-7.4 Deployment, cron, and automation changes must be attributable and reviewable.
An implementation fails this control domain if cross-tenant access, unmanaged credentials, unqualified connectors, or untraceable deployments affect agent operation.
4.0

Disqualifying Deficiencies

An implementation must not claim conformance while any of the following conditions are true for an in-scope agent.

  • Live execution occurs without intended use, owner, risk class, or prohibited-use boundary.
  • Observed runtime cannot be reconciled to approved runtime state.
  • Source-critical memory is unapproved, mutable without review, or attributable to no authoritative source.
  • Controlled actions accept client-supplied signer, role, or approval status.
  • Human authorization is bypassable for regulated, record-changing, or externally consequential actions.
  • Material runtime changes reach live use without validation evidence.
  • Regulated outputs cannot be reconstructed with actor, source, time, runtime, and approval context.
  • Unsafe agents cannot be disabled across all execution channels.
5.0

Evidence Requirements

Attestation evidence must be generated from the operating platform or from reviewed quality records. Manual assertion alone is not acceptable for high-risk agents.

DomainMinimum evidenceMinimum cadence
ACS-0Agent manifest, intended-use record, risk classification, ownership record, lifecycle stateAt creation and material change
ACS-1Desired runtime hash, observed runtime hash, environment posture, tool and connector allowlist, reconcile historyContinuous or scheduled reconcile
ACS-2Source hierarchy, memory-store binding, source/version hashes, promotion review, citation behavior evidenceAt source sync and memory promotion
ACS-3Action taxonomy, approval policy, recipient resolution, decision record, auth-derived signer and rolePer controlled action
ACS-4Eval pack, regression run, negative tests, deviations, release approval, evidence packageBefore release and material change
ACS-5Session log, tool-event log, output record, audit chain, usage telemetry, export manifestPer session and retained by policy
ACS-6Incident record, quarantine action, rollback version, credential revocation, memory archivePer incident or controlled rollback
ACS-7Tenant IAM map, supplier assessment, vault validation, connector validation, deployment recordAt onboarding and periodic review
A

Appendix

The following questions are intended for procurement, quality, security, and audit reviewers assessing agent platforms against this standard.

  1. Which agents are in scope, and what evidence proves their intended use, owner, risk class, and prohibited-use boundary?
  2. How is desired runtime state represented, hashed, approved, and compared with live state?
  3. What blocks execution when environment posture, tools, memory, vaults, connectors, or channel identity drift?
  4. How are source authority, memory promotion, and wrong-source behavior controlled?
  5. Which actions are internal tool use, and which actions require human authorization?
  6. How are approver identity, role, decision, time, and scope derived and preserved?
  7. Which evals prove source grounding, permission enforcement, refusal behavior, and prompt-injection resistance?
  8. How can an unsafe agent be quarantined across chat, API, channels, workflows, and scheduled jobs?
  9. How are GxP and non-GxP service credentials segregated and validated?
  10. Can an independent assessor receive an evidence package that maps each control to runtime evidence?