awesomechecklists
llms.txtGitHub ↗
/

17 — AI Agents and Tool Orchestration Checklist#

Verify that AI agents achieve bounded tasks through permitted tools, safe handoffs, controlled state, and meaningful human supervision. The model may propose plans and actions, but independent application controls must enforce access, approvals, budgets, and actual execution.

Scope: Backend / API-specific. This file is one part of the 17_AI_Agents_and_Tool_Orchestration.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

  • Project / product:
  • Release / version / environment:
  • Scope and applicable jurisdictions / markets:
  • Agent tasks, delegated roles, and tool inventory:
  • Model / runtime / connector versions and execution environment:
  • Authorized users, approvals, permissions, and limits:
  • Review / security / operations owner:
  • Review date:
  • Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

  1. Copy this shared template into project-specific review records; leave all repository checkboxes unchecked.
  2. Define the agent's goal, scope, tool authority, user delegation, human-approval policy, and stop conditions before running tests or granting production access.
  3. Mark [x] only after verifying workflow diagrams, tool permissions, adversarial and failure-mode tests, approval traces, safe retry behavior, monitored execution limits, or qualified risk decisions. Track failures, evidence, accepted exceptions, and justified N/A in project records/issues keyed by AGENT ID rather than adding an evidence table here.
  4. Review ## API Checks and ## Frontend Checks separately where those surfaces exist; document N/A and why for headless or disconnected deployments.
  5. Do not assume particular SDK approval, session, or MCP protocol features apply to other frameworks. Treat model messages and tool outputs as untrusted; enforce permissions, schemas, and side-effect safeguards in the calling application or infrastructure.
  6. Reassess after changing tools, providers, delegated identities, workflow goals, model or policy versions, execution sandboxes, approval rules, or user-facing actions. Coordinate detailed red-team, governance, monitoring, and regression review with the other AI-specific templates.

API Checks#

  • AGENT-095 Expose only the approved agent workflows and tool operations through authenticated, versioned API contracts.
  • AGENT-096 Require server-side authorization for starting, inspecting, resuming, canceling, and approving agent runs.
  • AGENT-097 Enforce resource and tenant isolation across run IDs, tool call IDs, checkpoint IDs, and conversation identifiers.
  • AGENT-098 Validate tool call arguments and all model-supplied routing metadata against trusted schemas.
  • AGENT-099 Test that agent API consumers cannot fabricate an approval or bypass a pending human decision.
  • AGENT-100 Check approval binding to current run, tool identity, precise arguments, and authenticated reviewer.
  • AGENT-101 Prevent untrusted callers from injecting serialized run state or editing pending approval decisions.
  • AGENT-102 Use stable idempotency keys and authoritative status checks to avoid repeated external actions after retry or resume.
  • AGENT-103 Define run lifecycle states including queued, running, waiting for approval, completed, failed, canceled, and partially completed.
  • AGENT-104 Document consistent API error states for invalid tools, policy denial, quota exhaustion, timeout, and unrecoverable failures.
  • AGENT-105 Enforce per-run limits on steps, token usage, tool calls, concurrency, wall-clock time, and cost.
  • AGENT-106 Apply per-tool rate limits, timeouts, permitted destinations, and network isolation independently of prompt instructions.
  • AGENT-107 Validate external API responses before returning them to an agent as tool results.
  • AGENT-108 Test nested agent handoffs and background tasks for preserved authorization and correct context filtering.
  • AGENT-109 Trace model, tool, guardrail, handoff, and approval events with correlation IDs without logging confidential payloads by default.
  • AGENT-110 Check that stream events and partial API results do not falsely report a tool action as executed before confirmation.
  • AGENT-111 Implement cancellation and stop procedures that reach queued tasks and active integrations when possible.
  • AGENT-112 Exercise failure and retry scenarios for payments, publishing, deletion, messaging, and other non-idempotent actions as applicable.
  • AGENT-113 Ensure connector secrets and delegated tokens are absent from API responses, error messages, and logs.
  • AGENT-114 Verify deployed tool inventories, versions, approval policies, and agents match the approved release configuration.
  • AGENT-115 Monitor excessive tool loops, anomalous privilege requests, denied calls, and unexpected outbound destinations.
  • AGENT-116 Test that deactivated users, revoked permissions, and expired delegations cannot resume privileged actions.

Release gate#

  • The agent's business purpose, task boundaries, permitted tools, authorized user population, run limits, and responsible owners are documented and reviewed.
  • Tool and connector inventory, least-privilege scopes, tenant boundaries, schema validation, and external execution/network restrictions have been tested against unauthorized access and tool misuse.
  • Representative end-to-end tasks meet agreed outcome and severe-error criteria, including blocked objectives, malformed tool data, and adversarial indirect instructions.
  • Routing and handoff tests confirm that specialist agents cannot gain extra privileges, improperly disclose context, or bypass normal approval and resource limits.
  • High-impact tool calls require authenticated, action-specific human approval bound to exact parameters; rejected, expired, changed, or replayed approvals do not execute.
  • Cancellation, shutdown, crash recovery, duplicate delivery, and partial external side effects have tested safe outcomes or a documented compensating/escalation procedure.
  • API and frontend consumers can distinguish proposed actions from confirmed execution and handle pauses, refusals, errors, and partial completion safely.
  • Monitors, alerts, incident response, execution traces, cost and throughput limits, and emergency tool revocation are operational with named responders.
  • Material unresolved authority, user-harm, privacy, prompt-injection, or side-effect risks are resolved or have an explicitly authorized and time-bound disposition.

Domain-specific approval rule: Block sign-off if an agent can reach unauthorized data or tools, autonomously cross approved scope, execute material unapproved side effects, resume with forged authority, or replay irreversible actions without accepted controls. Passing the checklist does not imply that agents are infallible, that actions are exactly once, or that a specific security or regulatory certification has been achieved.

Trusted references and scope#

The following primary and authoritative sources inform these practical review checks. Their SDK-specific details should be mapped to the actual framework and deployment environment rather than assumed to apply universally.

Applicability: MCP tool discovery is not permission to invoke every available function. Its November 2025 authorization specification is optional for some transports and implementations, and newer drafts may differ. OpenAI and Microsoft agent approvals must be implemented with server-owned decisions and current permission checks; resuming a previously approved run does not ensure exactly-once external side effects. OpenTelemetry conventions describe instrumentation but do not justify storing protected prompts or tool payloads. OWASP risk lists and NIST AI RMF practices support threat modeling and governance rather than certifying deployment safety. Anthropic's 2024 orchestration article carries an explicit notice that tooling has evolved.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

  • Test focus: tool permissions, budgets, retries, state handoffs, and high-risk approval gates; include API and service behavior where applicable.
  • Cross-stack: promptfoo + OpenTelemetry.
  • Python: LangGraph testing + pytest; for pytest-based suites, run python -m pytest -q.
  • TypeScript: promptfoo + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
  • JavaScript: promptfoo + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
  • Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

  • agent-owasp-compliance — Review agentic threat and tool-abuse scenarios (github/awesome-copilot, 41,073 repo stars).
  • workflow-orchestration-patterns — Check agent state, retries, and handoffs (wshobson/agents, 42,437 repo stars).
  • agentic-eval — Test bounded tool outcomes and regressions (github/awesome-copilot, 41,073 repo stars).

How to check: In a project-specific copy, have the agent audit the backend / API scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.

Reference, not a certification. Check applicability, verify important claims against current primary sources, and seek expert review where necessary. Suggest an improvement.