AI Agent Control Checklists

1. Purpose, applicability and use

This document supports one decision:

Which testable controls and retained evidence are required for this agent's tier and current lifecycle gate, and is the evidence sufficient to pass, route back, suspend or retire?

It is for Forward Deployed Engineering leads, agent product owners, technical owners, operations owners, independent assurance, security and risk leads, and runtime-selection teams. It applies to production AI systems that include an agent. A client may also apply it to a non-agentic AI system when the same controls are useful.

The controls are an Alpha AI baseline. NIST AI RMF organizes AI risk outcomes under GOVERN, MAP, MEASURE and MANAGE, treats governance as cross-cutting, and calls for continuous risk management across the AI system lifecycle. [G07] [G08] Its Core actions are not an ordered checklist, and its Playbook suggestions are voluntary and explicitly not a checklist to follow in full. [G08] [G09] GOV3 therefore converts selected outcomes into an operational method that must be tailored to the client's purpose, tier, environment, data, obligations and risk appetite. It does not claim to reproduce NIST.

Use the document in this order:

1. Confirm the GOV1 owner, tier, lifecycle gate and current approved version.
2. Apply the tailoring rules in section 3 and record every applicability decision.
3. Execute the controls required for the current lifecycle gate and all inherited cross-cutting controls.
4. Record a result and evidence against each applicable control.
5. Treat a failed or unknown mandatory control as a failed lifecycle gate decision; it cannot be offset by a score.
6. Retain the decision record and route failed controls to the earliest lifecycle gate whose evidence is no longer valid.

Dependency and assurance limits

GOV3 is pinned to the released version of GOV1. Before independent review, GOV3's lifecycle labels, all eight retained evidence names, tier rules and exception rules were verified against that released version.

The NIST Generative AI Profile is a companion to AI RMF 1.0. [G10] NIST SP 800-53 supplies a flexible control catalog and distinguishes control functionality from assurance confidence. [G11] NIST SSDF supplies outcome-based, tailorable secure-development practices rather than a checklist to adopt mechanically. [G12] These sources inform GOV3 but do not make GOV3 a NIST profile, baseline or conformance assessment.

ISO describes ISO/IEC 42001 as an AI management-system standard using Plan-Do-Check-Act to manage organization-wide AI risks and opportunities. [G15] The licensed normative text was not consulted. GOV3 therefore makes no clause-level ISO mapping, paraphrase, alignment or conformity claim.

This document does not contain:

• runtime implementation guidance, vendor capability scoring, weighting or a procurement recommendation;
• a threat taxonomy or red-team methodology (GOV2);
• jurisdiction-specific legal applicability or statutory classification (GOV4);
• compliance report design or audit-pack assembly (GOV5 and GOV6);
• detailed evaluation methods or observability implementation (R5 and R6); or
• a claim that checklist completion proves security, certification, legal compliance or ISO conformity.

2. Control-record schema

Each control record contains the fields below. A client may add fields but should not remove the decision, evidence or ownership fields.

UNKNOWN is a result, not a temporary pass. NOT APPLICABLE requires the reason, approver and the condition that would make the control applicable.

3. Tailoring rules

GOV1 determines the agent's tier, lifecycle gate, accountable roles, review cadence and approval authority. GOV3 determines which control evidence must be present for that context.

1. Start with the baseline. Controls marked T1+ apply to every production agent unless an approved applicability record gives a testable reason they do not.
2. Add, never substitute. T2+, T3+ and T4 controls add evidence depth. A higher-tier control does not remove a lower-tier control.
3. Follow the highest trigger. Data class, action authority, affected parties, deployment boundary, regulatory-applicability status or failure impact may require a higher control depth than the initial tier proposal.
4. Separate inherited and agent-specific evidence. An enterprise identity, logging or secure-build control may be inherited only when scope, owner, current effectiveness and the agent's use of it are evidenced. The agent record links to the inherited control and records any agent-specific gap.
5. Do not infer supplier capability. Vendor documentation can establish what a supplier documents. It cannot replace client-configuration evidence or a representative test in the target environment.
6. Keep unknowns visible. Apply the canonical screening disposition in section 4 to every unknown or unsupported mandatory runtime-selection criterion.
7. Bound compensating controls. A compensating control records the original unmet requirement, the alternative outcome, owner, evidence, monitoring, expiry and closure test. It does not silently rewrite the requirement.
8. Use GOV1 exception authority. An exception follows GOV1 approval and expiry rules. It cannot waive an applicable law.
9. Route material change back. A change to purpose, users, data, decisions, action scope, tier, acceptance criteria, model, tools, runtime, memory or supporting evidence returns to the earliest affected lifecycle gate.
10. Resolve legal applicability outside GOV3. Unresolved applicability follows the GOV1 Tier 4 path until GOV4 and the client's qualified owner resolve it.

4. Runtime-selection governance criteria

These are screening criteria and required evidence only. GOV3 does not weight, score, compare, rank or recommend runtimes.

Tailoring rule: GOV1 tier, lifecycle gate, client data classification, deployment boundary, and regulatory-applicability record determine which criteria are mandatory and how deep the evidence must be.

Canonical screening disposition: An unknown or unsupported mandatory runtime-selection criterion fails screening and excludes the candidate from weighted comparison and selection. The candidate can proceed only under a current GOV1 exception that identifies the unmet requirement, authorizes a defined compensating outcome and satisfies GOV1's approval, evidence, monitoring and expiry rules. The exception cannot be replaced or offset by a weighted selection score.

5. Lifecycle checklists using GOV3 labels L1-L8

The labels and retained-evidence names below were verified against the released GOV1 state pinned in section 1. L1-L8 are GOV3-local shorthand, not identifiers defined by GOV1:

L1 - Intake

Decision: Is there a named owner, bounded purpose and approved initial tier for work to proceed?

• GOV-01 - Business, product, technical, operations, assurance, data and regulatory-applicability functions are named or recorded as open dependencies.
• GOV-02 - Intended purpose, prohibited purposes, users, affected parties, workflow, action authority, stop condition and initial tier rationale are recorded.
• DAT-01 - Expected data classes, sources and persistence are identified at a level sufficient to identify unresolved use or residency questions.
• EXIT-01 - The initial supplier and client ownership assumptions identify what must remain retrievable at handover or exit.
• Any unresolved regulatory applicability follows the GOV1 Tier 4 path.

Pass condition: the required GOV1 owners approve an Agent intake record with no hidden mandatory unknown. Otherwise fail or route back to intake.

L2 - Design

Decision: Are the deployment boundary, controls, evaluation conditions and human decision rights defined before implementation?

• DAT-02 - Data flows cover prompt, memory, files, traces, logs, caches, backups, operator access, retention and deletion.
• IAM-01 - Human, workload, agent and delegated-user identities and trust relationships are designed.
• IAM-02 - Consequential actions and approval authority are defined by tier.
• TOOL-01 - Allowed tools, destinations, methods, parameters and failure boundaries are specified.
• SEC-01 - Secret handling and egress policy are specified.
• CFG-01 - Version and provenance requirements cover model, prompt, tools, policies, dependencies, runtime and environment.
• EVAL-01 - Acceptance criteria, datasets or rubrics, failure thresholds and required independence are approved before testing.
• AUD-01 and AUD-02 - Required event fields, export, access and retention outcomes are designed.
• OPS-01 and IR-01 - Suspension, containment, restart and incident authorities are designed.

Pass condition: required approvers accept the Approved deployment brief and risk-context record, with owners for every unresolved dependency.

L3 - Build readiness

Decision: Can the approved design be built reproducibly in the client-approved environment without unowned components or authority?

• CFG-01 - A version manifest resolves every model, prompt, tool, policy, dependency, image, runtime and environment reference.
• CFG-02 - Change attribution, protected configuration, rollback target and release authority are implemented.
• IAM-01, IAM-02, TOOL-01, SEC-01 - Representative allow, deny, approval, secret and egress paths can be exercised.
• DAT-02 - Isolation, retention and deletion configurations exist for the approved boundary.
• AUD-01 - Correlation identifiers and required audit fields can be emitted in a representative execution.
• OPS-01 - The kill mechanism and operator access path exist before production-connected testing.
• SUP-01 - Build provenance, dependency inventory and vulnerability response ownership are present.

Pass condition: the technical owner approves the Build-readiness record and version manifest and every planned component has an owner and review path.

L4 - Validation

Decision: Does the release candidate meet pre-agreed control and evaluation conditions under representative success, misuse and failure scenarios?

• EVAL-01 - Acceptance tests run against the approved release candidate and environment.
• EVAL-02 - Failure, abuse, unsafe action, prompt-injection and boundary scenarios appropriate to the tier are tested.
• IAM-01, IAM-02, TOOL-01, SEC-01, DAT-02 - Positive and negative tests demonstrate the configured boundary rather than a design claim.
• AUD-01 and AUD-02 - Exported events reconstruct representative requests, actions, approvals, outcomes and versions.
• OPS-01, OPS-02, IR-01 - Kill, containment, alert, incident and recovery exercises meet the approved conditions.
• BCP-01 - Recovery objectives and state behavior are tested where required by tier and workflow.
• Failures are closed or recorded as current GOV1 exceptions with compensating evidence, expiry and closure tests.

Pass condition: independent assurance accepts the Validation report and findings register. An unknown mandatory result fails.

L5 - Production approval

Decision: Is the exact validated version authorized to operate within its recorded boundary?

• GOV-01 and GOV-02 - Registry, owners, tier, approvals and review date are complete and current.
• CFG-01 - Production authorization resolves to the tested version and environment.
• EVAL-01 - Acceptance results meet approved thresholds.
• AUD-01, AUD-02, OPS-01, OPS-02, IR-01 - Operations accepts logging, monitoring, kill and incident runbooks.
• Every exception is unexpired, approved at the required authority and linked to monitoring and suspension conditions.
• Required data, regulatory and residual-risk decisions are present.

Pass condition: the GOV1 decision-makers sign the Production authorization record for the exact version and boundary. Conditions that defer a mandatory unknown do not constitute a pass.

L6 - Operation and change

Decision: Does current operating evidence support continued use, and has every material change been routed correctly?

• OPS-02 - Reliability, quality, security, autonomy, cost and governance evidence required by the approved design is reviewed at the tier cadence.
• AUD-01 and AUD-02 - Event completeness, export, retention and access controls remain effective.
• CFG-02 - Deployed versions match approvals and changes are attributable.
• EVAL-01 and EVAL-02 - Required regression and production evaluations are current.
• GOV-02 - Ownership, tier, purpose, applicability and exceptions remain current.
• IR-01 - Incidents, repeated failures and corrective actions are open, owned and escalated.
• Each material change is routed to the earliest lifecycle gate whose evidence is no longer valid before release.

Pass condition: the Periodic governance review and change-classification record supports continued operation. Otherwise suspend, restrict or route back.

L7 - Suspension and restart

Decision: Has action authority been contained, evidence preserved and the restart independently authorized?

• OPS-01 - The agent or its action authority is disabled; queued and in-flight work is accounted for.
• IR-01 - Scope, impact, timeline, affected identities, data and actions are preserved and investigated.
• Credentials, sessions, tools and egress are revoked or constrained as the incident requires.
• Corrective actions and compensating controls are implemented and tested.
• CFG-01 identifies the restart candidate; EVAL-01 and EVAL-02 provide re-validation evidence.
• Restart uses the production authority required by GOV1 tier and does not rely only on the operator who performed containment.

Pass condition: the Suspension, incident and restart authorization record shows containment, impact assessment, corrective action, re-validation and authorized restart. Otherwise remain suspended.

L8 - Retirement

Decision: Have action authority, access, scheduled work, data and evidence been closed or transferred under approved rules?

• RET-01 - Deployments, triggers, queues, integrations and credentials are disabled or revoked.
• EXIT-01 - Required configuration, logs, traces, evaluations, approvals and control evidence are exported and retrievable by the client.
• Data, memory, logs, backups and evidence are deleted or archived under approved retention and legal-hold rules.
• Users, owners, downstream systems and suppliers are notified where required.
• Residual dependencies, contractual restrictions and unverified deletion obligations remain explicit.
• The registry record is closed but remains discoverable for its approved retention period.

Pass condition: the accountable GOV1 roles approve the Retirement attestation and archived registry record. An unsupported deletion or revocation claim remains an open retirement finding.

6. Cross-cutting control families

The controls below are Alpha AI requirements. The minimum tier is a starting point; section 3 may raise applicability or evidence depth.

Governance, data and identity

Tools, software supply chain and configuration

NIST SSDF groups secure-development practices under Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities, and describes them as outcome-based and tailorable. [G12] SUP-01, CFG-01 and CFG-02 use that structure as informative guidance; they do not claim to implement the complete SSDF.

Evaluation, auditability and operation

NIST AI RMF states that AI systems should be tested before deployment and regularly in operation, that measurement should be documented, and that independent review can improve testing effectiveness. [G08] EVAL-01, EVAL-02, AUD-01 and OPS-02 operationalize those outcomes as Alpha AI controls.

Resilience, incident and exit

MITRE ATLAS can inform threat scenarios for EVAL-02 and IR-01, but it is a threat-informed knowledge base, not a compliance standard or proof that the scenario set is complete. [G14]

7. Evidence sufficiency and assurance method

Evidence sufficiency test

Evidence is sufficient only when all applicable conditions pass:

An interview, screenshot or supplier statement may support context but is not sole evidence for an enforceable technical boundary. Vendor material is labelled vendor-documented until target-environment evidence supports the control.

Sampling

• Record population, period, sampling method, sample size and exclusions.
• Include at least one allowed, denied and failed path when those paths exist.
• Increase depth for higher tiers, broad user populations, high action authority, weak telemetry, recent incidents or prior control failures.
• Do not convert absence of observed failure into proof that a control works.

Failed-control handling

Route back to the earliest lifecycle gate whose evidence is invalid:

8. Standards crosswalk

Mapping rules

• Direct means the cited source explicitly states the outcome GOV3 operationalizes. It does not mean word-for-word adoption or conformity.
• Partial means the source explicitly supports part of the control, while GOV3 adds material scope, evidence or decision requirements.
• Informative means the source helps interpret, test or challenge the control. It does not create normative equivalence.
• None means GOV3 found no support in the reviewed source set. It must not be silently upgraded to a mapping.

NIST SP 800-53 is a flexible and customizable security and privacy control catalog that addresses both control functionality and assurance confidence. [G11] CSF 2.0 and MITRE ATLAS are used only where their outcome or threat perspective helps the control owner; neither proves an agent-specific control. [G13] [G14] ISO/IEC 42001 is mapped only at management-system level. [G15]

9. FDE adoption sequence and tier baseline

1. Map client titles and systems to GOV1 functional roles and the GOV3 control record.
2. Select one production candidate per active tier and record applicability for every GOV3 control.
3. Test the runtime-selection criteria in section 4 before a weighted comparison.
4. Build the L1-L5 evidence path for each candidate; do not reconstruct it only after deployment.
5. Exercise kill, containment, incident, recovery and restart before production.
6. Run one L6 periodic review and one material-change route-back while the FDE is still embedded.
7. Test client-controlled evidence export and retirement on a non-production instance.
8. Transfer control ownership, test procedures, evidence locations and review cadence to the client.

Minimum baseline by tier

10. Reusable worksheets

Control applicability record

Lifecycle gate decision record

Evidence record

Exception and compensating-control record

Selection governance-criteria handoff

Any downstream selection process uses the nine criteria from section 4 by citation. It does not recreate or silently edit them.

The canonical screening disposition in section 4 governs every mandatory unknown or unsupported result in this table. Record any applicable GOV1 exception and its defined compensating outcome beside the result.

Record each result as supported, unknown or unsupported.

References

The references below identify the external sources cited in this framework.

• [G07] NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0).
• [G08] NIST AI Resource Center, AI RMF Core.
• [G09] NIST AI Resource Center, NIST AI RMF Playbook.
• [G10] NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1).
• [G11] NIST, Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5).
• [G12] NIST, Secure Software Development Framework (SP 800-218).
• [G13] NIST, Cybersecurity Framework 2.0.
• [G14] MITRE, Adversarial Threat Landscape for Artificial-Intelligence Systems (ATLAS).
• [G15] ISO, ISO/IEC 42001:2023 official record.