The Governed AI Agent Delivery Playbook: Human Authority, Tool Use and Verifiable Action

An AI agent may use model output to choose or sequence actions through tools. Before building one, agree the business outcome and exactly which actions it may take. Set permissions, checks and human escalation so its authority remains clear.

Use this guide to turn an approved architecture decision and governance controls into a testable agent delivery contract. The Automation Architecture Decision and AI and Automation Governance Standard establish those prerequisites. Define goals, state, identity, tool permissions, human approval, verification, traceability, failure handling, incidents and handover. This guide does not approve production, replace the Proof-of-Value Pilot or govern the live service under the Automation Production Operating Standard.

1. The Market Connection Context

The recognisable leadership condition is a compelling agent demonstration that hides the work required for reliable action. The demo uses broad credentials, trusted sample content, one expert operator and reversible tasks. The proposed service must face ambiguous requests, untrusted documents, changing tools, duplicated actions, partial failure, customer consequences and people who cannot inspect a model’s reasoning.

The value path is:

Accepted workflow, architecture and governance boundary
→ explicit goal, identity, tools and human authority
→ verifiable bounded action
→ contained failure and traceable handoff
→ pilot evidence under The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production
→ separately owned production operation under The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control

The agent delivery contract

For each agent component, delivery must answer seven questions:

1. Goal: What exact task outcome may the component pursue, and what is prohibited?
2. State: Which task, session and durable state may it read or change, and when does that state expire?
3. Identity: On whose behalf does it act, using which machine identity and delegated authority?
4. Tools: Which named operations, parameters, resources and transaction limits are allowlisted?
5. Human authority: Which actions require deterministic pre-approval, review, interruption or remedy?
6. Verification: What independent evidence proves that the requested action was authorised and completed correctly?
7. Containment: How are loops, duplicates, prompt injection, tool misuse, model or supplier change, partial failure and incident response bounded?

An instruction is not a control when the same model can ignore or reinterpret it. Consequential controls belong in deterministic orchestration, identity, permission, schema, policy, transaction and runtime layers. Microsoft’s official security guidance similarly recommends isolated agent permissions, explicit action schemas and deterministic human review enforced outside model reasoning for high-risk or irreversible actions (Secure autonomous agentic AI systems, VERIFIED vendor guidance at the source cut-off).

Action classes and dispositions

Classify each tool operation independently:

The delivery disposition is one of READY FOR BOUNDED PILOT, ASSISTANCE OR PROPOSAL ONLY, VALIDATE A CONTROL, CHANGE ARCHITECTURE OR TIER, DEFER, or STOP. A pilot handoff follows the Proof-of-Value Pilot Standard. None means production ready.

NIST has identified indirect prompt injection or agent hijacking as malicious instructions embedded in data that an agent may ingest and then act on (Strengthening AI Agent Hijacking Evaluations, VERIFIED official technical blog). NIST’s 2026 concept paper on software-agent identity asks how agents should be identified, authenticated, authorised, audited and bound to human authority; it is explicitly a concept paper, not a final standard (Agent identity and authorization concept paper, VERIFIED official consultation source).

Scope and exclusions

Use this playbook after The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build selects bounded agentic action and The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action accepts the governance tier and use boundary. Scope includes delivery charter, task and state model, identity and delegation, tool/action contracts, trust separation, human approval, verification, orchestration limits, observability, adversarial and failure evidence, pilot handoff and closure.

It excludes general governance under The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action, portfolio or architecture choice, pilot execution under The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production, production monitoring and service operation under The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control, procurement, enterprise scale and claims that autonomy itself creates value. It does not guarantee security, safety, compliance or reliable model behaviour.

Expected outputs are an agent charter and task/state register, identity/tool/permission register, human approval and verification contract, execution/failure/handoff register, evaluation brief and closure evidence. They are not production code acceptance or an autonomous-workforce plan.

2. The Leadership vs. Delegation Boundary

The reader recognises that production agents require workflow engineering, model evaluation, permission design, human escalation, observability and operational ownership.

Internal leadership

An internal team can lead when it has architecture and governance evidence, can deny tool access, can instrument every action, can test hostile content safely, and can recommend assistance-only or stop. Product delivery measures must not reward the team for higher autonomy, more tool calls or fewer human approvals.

Independent leadership

Independent challenge is justified when the agent crosses suppliers and functions, a platform team controls both implementation and evaluation, broad credentials already exist, or executives assume model quality solves identity and process risk. External specialists may test and challenge but cannot own internal authority or production incidents.

Narrow specialists

Use identity, application security, threat-modelling, reliability, evaluation, privacy, accessibility or domain specialists for bounded questions. Human-factor expertise is necessary where reviewers could face approval fatigue or automation bias. Link specialist findings to exact action and component IDs.

Stop and escalation

Contain immediately after unauthorised tool access, credential exposure, action beyond delegated authority, uncontrolled loop, duplicate consequential action, material prompt injection, sensitive-data leakage, untraceable state change or failed interruption. Escalate workflow consequence to the COO, technical access to the CIO/CTO, incidents to named commanders and specialist matters to qualified authorities.

Questions for evaluating an agent delivery provider

1. Which business decision justifies agentic action rather than rules or assistance?
2. How is the model separated from untrusted content and deterministic policy?
3. Which exact tools and operations are never exposed?
4. How is user authority bound to agent identity and each action?
5. Which approvals are enforced outside model reasoning?
6. How do idempotency and postcondition checks prevent duplicates and partial completion?
7. What does a reviewer see before approving a consequential action?
8. How will prompt injection, tool chaining, loops and state poisoning be evaluated?
9. Which records reconstruct intent, proposed action, approval, execution and result?
10. How does delivery hand only a bounded test to The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production and operations to The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control?

3. The Step-by-Step Execution Standard

Use the Agent Charter Task and State Register, Identity Tool and Permission Register, Human Approval Verification and Trace Register, and Execution Failure Pilot Handoff and Closure Register.

Step 01: Charter the bounded agent task

Purpose and decision served Define the exact workflow task, authorised outcome and delivery decision without autonomy as a goal.

Accountable owner CIO/CTO with COO and executive-sponsor acceptance.

Delegated lead and contributors Delivery lead, architect, operating owner, governance, security, data, evaluation and affected-user contributors.

Preconditions, inputs and access Accepted The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build architecture, The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action governance boundary, source workflow and authority to stop.

Actions

1. State the task, population, environment and authorised outcome.
2. Define prohibited goals, actions and content.
3. Record dependencies, suppliers, decision forum and conflicts.
4. Approve dispositions, evidence gates and immediate-stop conditions.

Evidence to retain Architecture and governance handoffs, charter, authority, interests and approval.

Decision or scoring rule Proceed only if assistance-only, redesign, defer and stop remain possible.

Output and template A2D-CHR-* rows in the Agent Charter Task and State Register.

Acceptance gate PROCEED, CHANGE, DEFER or STOP.

Leadership checkpoint The sponsor confirms autonomy level is not a success measure.

Human control point Only named owners delegate business authority.

Failure modes and safeguards A broad “digital worker” brief is rejected for one bounded task.

Change, stop or escalation condition Stop an ownerless or production-assuming delivery.

Handoff to the next step Pass charter to Step 02.

Step 02: Model task, goal and state boundaries

Purpose and decision served Specify what a run may attempt, remember, resume and terminate.

Accountable owner Operating owner and architect.

Delegated lead and contributors Workflow specialist, domain expert, data engineer, privacy, security and user representatives.

Preconditions, inputs and access Performed workflow, case taxonomy, state sources, retention and exception evidence.

Actions

1. Decompose the task into bounded states and transitions.
2. Define session, task and durable memory separately.
3. Set maximum steps, retries, elapsed boundary and termination conditions.
4. Mark all transitions requiring human decision or prohibited action.

Evidence to retain Task graph, state contract, source, expiry, exceptions and unresolved ambiguity.

Decision or scoring rule The agent cannot invent a new goal, persist unapproved state or continue after termination.

Output and template A2D-TSK-* and A2D-STA-* rows.

Acceptance gate Every state and transition has owner, source, entry, exit and failure response.

Leadership checkpoint The COO accepts what remains human work.

Human control point Domain owners approve task and state meaning.

Failure modes and safeguards Open-ended instruction is replaced by explicit state and stop contracts.

Change, stop or escalation condition Return to The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build if task boundaries require a different architecture.

Handoff to the next step Pass task and state model to Step 03.

Step 03: Establish identities and delegated authority

Purpose and decision served Bind each action to a human principal, agent identity and limited delegation.

Accountable owner CIO/CTO and identity owner.

Delegated lead and contributors Identity architect, security, platform, application and operating owners.

Preconditions, inputs and access Identity standards, user roles, service accounts, session model and approved authorities.

Actions

1. Assign separate human, agent and service identities.
2. Define authentication, delegation, expiry and re-authentication.
3. Bind task, tenant, environment and resource scopes.
4. Test issuance, rotation, revocation and audit linkage.

Evidence to retain Identity source, role mapping, credentials custody, delegation and revocation evidence.

Decision or scoring rule Shared identity or unbounded impersonation prevents tool-enabled delivery.

Output and template A2D-IDN-* rows in the Identity Tool and Permission Register.

Acceptance gate Every action can be attributed to authorised human and system principals.

Leadership checkpoint The CIO/CTO accepts identity and credential operating burden.

Human control point Identity and resource owners grant delegation.

Failure modes and safeguards User convenience cannot justify shared long-lived credentials.

Change, stop or escalation condition Contain unexplained identity or delegation immediately.

Handoff to the next step Pass identity contracts to Step 04.

Step 04: Contract tools and action schemas

Purpose and decision served Expose only the minimum operations and parameters required for the accepted task.

Accountable owner System owner.

Delegated lead and contributors Application, integration, security, data, domain and supplier specialists.

Preconditions, inputs and access Task states, identity, API specifications, system-of-record rules and consequence map.

Actions

1. Register each tool, operation, input, output and side effect.
2. Allowlist resources, parameters, values, frequency and environment.
3. Classify actions as read, propose, reversible write, consequential write or prohibited.
4. Define preconditions, idempotency key, postcondition and compensation.

Evidence to retain Versioned schemas, permission sources, denied operations and test fixtures.

Decision or scoring rule Do not expose a broad tool when a narrow operation can serve the task.

Output and template A2D-TOL-* and A2D-ACT-* rows.

Acceptance gate Every possible side effect has an action class, owner, limit and verification.

Leadership checkpoint Operating owners accept write consequences and compensation paths.

Human control point Resource owners authorise operations, not the model.

Failure modes and safeguards Natural-language tool descriptions cannot replace enforceable schemas.

Change, stop or escalation condition Remove any tool with unknown side effects or unowned recovery.

Handoff to the next step Pass tool contracts to Step 05.

Step 05: Separate trusted instruction from untrusted content

Purpose and decision served Reduce the chance that external data becomes unauthorised operational instruction.

Accountable owner Security owner.

Delegated lead and contributors Application security, model, data, content, tool and threat-modelling specialists.

Preconditions, inputs and access Content sources, tool schemas, instruction hierarchy, threat model and known attack evidence.

Actions

1. Classify system policy, user intent, retrieved data and tool output by trust.
2. Keep policy and permission enforcement outside model text.
3. Constrain retrieved content, tool chaining and cross-domain transfer.
4. Define detection, refusal, containment and evidence for injection attempts.

Evidence to retain Trust-boundary map, enforcement code, adversarial cases, findings and residual exposure.

Decision or scoring rule Content can inform a task but cannot grant identity, permission or new authority.

Output and template Trust and threat rows linked to tools and actions.

Acceptance gate Decision-critical policy is deterministic and untrusted paths are testable.

Leadership checkpoint The CIO/CTO accepts residual prompt-injection exposure.

Human control point Security authorities decide containment and acceptance.

Failure modes and safeguards Prompt wording is not presented as a complete security boundary.

Change, stop or escalation condition Stop action where hostile content can expand permission.

Handoff to the next step Pass trust controls to Step 06.

Step 06: Design deterministic human approval and handoff

Purpose and decision served Ensure consequential action pauses with enough context for a named person to decide.

Accountable owner Operating owner.

Delegated lead and contributors Domain reviewers, workflow, UX, accessibility, security and service specialists.

Preconditions, inputs and access Action classes, human-control contract, identity, workload baseline and challenge routes.

Actions

1. Define actions always requiring approval outside model reasoning.
2. Present intent, source, exact effect, target, limits and reversible path.
3. Bind approval to one action payload, identity and expiry.
4. Define reject, edit, escalate, timeout and handoff behaviour.

Evidence to retain Approval schema, user evidence, workload, decision, binding and bypass tests.

Decision or scoring rule Standing or bulk approval is prohibited where each action needs consequential judgement.

Output and template A2D-HUM-* and A2D-APR-* rows in the Human Approval Verification and Trace Register.

Acceptance gate Reviewers have information, competence, time, authority and safe refusal.

Leadership checkpoint The COO accepts real approval and escalation capacity.

Human control point Named people approve exact action payloads.

Failure modes and safeguards Approval fatigue and misleading summaries are tested explicitly.

Change, stop or escalation condition Narrow to proposal-only if meaningful approval is infeasible.

Handoff to the next step Pass approval contracts to Step 07.

Step 07: Implement independent action verification

Purpose and decision served Prove preconditions and postconditions using authoritative sources rather than model assertion.

Accountable owner Quality and system owners.

Delegated lead and contributors Domain, application, data, integration, finance and reliability specialists.

Preconditions, inputs and access Action schemas, systems of record, approval, expected state and compensation path.

Actions

1. Verify target, authority, state and limits before execution.
2. Generate idempotency and correlation identifiers.
3. verify committed state independently after execution.
4. Reconcile partial, duplicate, delayed or contradictory results.

Evidence to retain Precondition, approval, request, response, source-of-truth and reconciliation records.

Decision or scoring rule Model-generated confirmation is not proof that an external action occurred correctly.

Output and template A2D-VER-* records linked to action IDs.

Acceptance gate Every material write is verified or placed into controlled exception.

Leadership checkpoint Leaders see the operational cost of independent verification.

Human control point Named exception owners resolve contradictory state.

Failure modes and safeguards Success messages and HTTP responses cannot substitute for business postconditions.

Change, stop or escalation condition Interrupt repeated action after uncertain result.

Handoff to the next step Pass verification design to Step 08.

Step 08: Bound orchestration, retries and concurrency

Purpose and decision served Prevent loops, duplicate effort, uncontrolled delegation and state collision.

Accountable owner Technical delivery owner.

Delegated lead and contributors Orchestration, platform, reliability, cost, security and workflow specialists.

Preconditions, inputs and access State machine, tool contracts, retry characteristics, transaction and cost limits.

Actions

1. Set maximum steps, tool calls, retries, concurrency and resource consumption.
2. Define deterministic transition and termination policy.
3. Prevent unregistered sub-agents, tools and delegation chains.
4. Control race, stale state, duplicate and poison-message cases.

Evidence to retain Runtime policy, configuration, limit tests, resource evidence and exceptions.

Decision or scoring rule Exceeding a limit terminates or escalates; the model cannot self-extend authority.

Output and template Orchestration and runtime-limit rows.

Acceptance gate Loops, concurrency and partial work end in deterministic safe states.

Leadership checkpoint The CIO/CTO accepts cost and service limits.

Human control point Named operators change runtime policy under change control.

Failure modes and safeguards Autonomous recovery cannot become uncontrolled repeated action.

Change, stop or escalation condition Contain runaway work or unregistered delegation.

Handoff to the next step Pass orchestration limits to Step 09.

Step 09: Contract traceability and incident evidence

Purpose and decision served Reconstruct what the agent intended, proposed, was permitted to do, did and caused.

Accountable owner Evidence custodian and service owner.

Delegated lead and contributors Observability, security, privacy, incident, data and application owners.

Preconditions, inputs and access Identities, state, prompts or references, tool calls, approvals, actions and retention authority.

Actions

1. Define trace IDs across task, model, tool, approval, action and result.
2. Log versions, policy decisions, limits, errors and human interventions.
3. Minimise sensitive content and protect integrity, access and retention.
4. Define incident signals, investigation query and evidence export.

Evidence to retain Trace schema, samples, access, integrity, alert and deletion tests.

Decision or scoring rule Collect evidence serving an accepted control; do not record speculative hidden reasoning as fact.

Output and template A2D-TRC-* records.

Acceptance gate Material runs and actions can be reconstructed within approved information boundaries.

Leadership checkpoint Leaders accept monitoring and privacy trade-offs.

Human control point Evidence and information owners authorise custody.

Failure modes and safeguards Opaque action and excessive surveillance are both rejected.

Change, stop or escalation condition Disable consequential action after decision-critical trace failure.

Handoff to the next step Pass trace controls to Step 10.

Step 10: Evaluate hostile, failed and changed conditions

Purpose and decision served Test whether the delivery respects authority when content, tools, state, users or suppliers behave unexpectedly.

Accountable owner Evaluation owner independent of delivery where proportionate.

Delegated lead and contributors Security, domain, reliability, privacy, safety, affected-user and supplier specialists.

Preconditions, inputs and access Representative cases, threat model, safe environment, stop authority and pre-registered gates.

Actions

1. Test direct and indirect instruction attacks, malformed data and trust confusion.
2. Test unavailable, slow, contradictory and compromised tools.
3. Test permission denial, stale state, duplicates, loops and partial completion.
4. Test interruption, revocation, fallback, reconciliation and model or supplier change.

Evidence to retain Case, expected result, actual result, trace, containment, recovery and limitations.

Decision or scoring rule One material authority escape or unrecoverable action can stop delivery.

Output and template A2D-FAL-* records in the Execution Failure Pilot Handoff and Closure Register.

Acceptance gate Mandatory safety, authority, verification and recovery cases are demonstrated or visibly failed.

Leadership checkpoint The risk forum accepts residual exposure without autonomy hype.

Human control point Qualified owners control adversarial testing and containment.

Failure modes and safeguards Passing a fixed test set is not represented as universal robustness.

Change, stop or escalation condition Contain any test escaping its authorised environment.

Handoff to the next step Pass complete delivery evidence to Step 11.

Step 11: Decide bounded pilot readiness and handoff

Purpose and decision served Determine whether the delivery can enter The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production under exact conditions.

Accountable owner CIO/CTO with COO and risk acceptance within mandate.

Delegated lead and contributors Decision secretary, delivery, evaluation, governance, operating and pilot owners.

Preconditions, inputs and access Complete task, identity, tool, approval, verification, trace and failure evidence.

Actions

1. Reconcile all mandatory gates and open uncertainty.
2. Record dissent, rejected alternatives and residual exposure.
3. Assign one delivery disposition and exact pilot boundary.
4. Obtain The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production owner acceptance of cases, controls and stop routes.

Evidence to retain Signed decision, evidence index, conditions, exclusions and handoff.

Decision or scoring rule Tool sophistication cannot offset failed human authority, permission or verification.

Output and template A2D-DEC-* and A2D-HND-* records.

Acceptance gate READY FOR BOUNDED PILOT, ASSISTANCE OR PROPOSAL ONLY, VALIDATE A CONTROL, CHANGE ARCHITECTURE OR TIER, DEFER or STOP.

Leadership checkpoint Leaders state that pilot readiness is not production readiness.

Human control point Named owners make and receive the bounded decision.

Failure modes and safeguards Conditional delivery cannot become unbounded pilot activity.

Change, stop or escalation condition Return material scope change to The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build/The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action.

Handoff to the next step Pass accepted handoff to Step 12.

Step 12: Close delivery access and preserve operability evidence

Purpose and decision served Remove temporary delivery authority and preserve records needed by pilot and future operations.

Accountable owner CIO/CTO.

Delegated lead and contributors Identity, environment, supplier, data, evidence, pilot and The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control operating owners.

Preconditions, inputs and access Decision, asset register, credentials, test data, environments, supplier access and retention rules.

Actions

1. Revoke delivery credentials, broad permissions and temporary tools.
2. Close or transfer environments and data under named authority.
3. Package schemas, tests, traces, incidents, runbooks and unresolved gaps.
4. Record change and re-charter triggers for pilot and production design.

Evidence to retain Revocation, closure, transfer, custody and final evidence index.

Decision or scoring rule Only assets explicitly accepted by The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production or later The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control boundaries remain active.

Output and template A2D-CLS-* records.

Acceptance gate CLOSED, TRANSFERRED TO PROOF-OF-VALUE PILOT, RETAINED BY AUTHORITY or ESCALATE.

Leadership checkpoint The CIO/CTO accepts who can operate and change each retained component.

Human control point Asset and evidence owners attest closure or transfer.

Failure modes and safeguards Developer credentials cannot become operational agent identity.

Change, stop or escalation condition Escalate any unaccounted identity, tool, data or environment.

Handoff to the next step Return material new goals or actions to Step 01.

4. The Evidence & Measurement Checklist

Preflight and authority

• The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build architecture and The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action governance boundaries are accepted. Evidence: source handoff. Owner: delivery lead.
• One task, population, environment and authorised outcome are chartered. Evidence: agent charter. Owner: sponsor.
• Assistance-only, redesign, defer and stop remain possible. Evidence: decision mandate. Owner: CIO/CTO.
• Pilot and production decisions remain The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production and The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control gates. Evidence: scope register. Owner: decision secretary.
• Supplier, platform and delivery interests are disclosed. Evidence: conflict register. Owner: independent challenger.

Evidence access and quality

• Every task, state, identity, tool, action and environment has a stable ID. Evidence: registers. Owner: architect.
• Workflow, authority and system-of-record claims retain sources. Evidence: evidence index. Owner: evidence custodian.
• Tool schemas and supplier behaviour retain version and applicability. Evidence: component record. Owner: system owner.
• Failed and hostile cases preserve original traces. Evidence: evaluation record. Owner: evaluation owner.
• Unknown material behaviour remains REQUIRES VALIDATION. Evidence: gap register. Owner: decision owner.

Method execution

• Task goals, prohibited goals and termination are explicit. Evidence: task contract. Owner: operating owner.
• Session, task and durable state are separated. Evidence: state register. Owner: data owner.
• Read, propose, reversible write, consequential write and prohibited actions are classified. Evidence: action matrix. Owner: architect.
• Deterministic controls exist outside model reasoning. Evidence: enforcement design. Owner: security owner.
• Step, retry, concurrency, cost and delegation limits are enforced. Evidence: runtime policy. Owner: platform owner.

Governance, privacy, security and risk

• Human and agent identities have narrow delegated authority. Evidence: identity register. Owner: identity owner.
• Tool operations, parameters, resources and transaction limits are allowlisted. Evidence: permission register. Owner: system owner.
• Untrusted content cannot grant permission or change deterministic policy. Evidence: trust-boundary tests. Owner: security owner.
• Consequential actions require meaningful deterministic human approval. Evidence: approval test. Owner: operating owner.
• Interrupt, revocation, fallback and incident authority are executable. Evidence: containment test. Owner: service owner.

Deliverables and acceptance

• All four working files use linked stable identifiers. Evidence: pack index. Owner: delivery custodian.
• Every write has precondition, idempotency, postcondition and compensation. Evidence: action contract. Owner: quality owner.
• Material runs reconstruct intent, approval, action and result. Evidence: trace sample. Owner: evidence custodian.
• Hostile, unavailable, duplicate, loop and partial-failure cases are tested. Evidence: evaluation pack. Owner: evaluation owner.
• The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production owner accepts exact pilot scope and stop routes. Evidence: handoff. Owner: pilot owner.

Measurement

• Learning, operating, outcome and guardrail measures remain separate. Evidence: measurement register. Owner: benefit owner.
• Measures define baseline, source, unit, owner, cadence and response. Evidence: contracts. Owner: measurement owner.
• Tool-call volume is not treated as business value. Evidence: decision pack. Owner: sponsor.
• Human approval and exception burden use observed capacity. Evidence: workload baseline. Owner: COO.
• Results retain version, population, environment and attribution limits. Evidence: evaluation report. Owner: proof owner.

Decision and handover

• Every component receives one delivery disposition. Evidence: signed decision. Owner: CIO/CTO.
• Assistance-only and prohibited actions remain visible. Evidence: action decision map. Owner: risk executive.
• Conditions, dissent and rejected alternatives accompany pilot readiness. Evidence: decision pack. Owner: challenger.
• The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production accepts evidence testing; The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control retains production operation. Evidence: handoff register. Owner: delivery custodian.
• Agent delivery is not represented as production readiness. Evidence: claim control. Owner: proof owner.

Review, change and stop controls

• Goal, tool, permission, model, supplier and state changes trigger review. Evidence: change register. Owner: CIO/CTO.
• Material agent hijacking or authority escape triggers containment. Evidence: incident route. Owner: security owner.
• Temporary credentials and environments have closure evidence. Evidence: closure register. Owner: platform owner.
• Superseded schemas, permissions and instructions are retired. Evidence: version closure. Owner: architect.
• New goals or consequential actions require re-charter. Evidence: decision trigger. Owner: sponsor.

Measurement contracts

Measure A: Action-contract coverage

Measure B: Verified consequential action

Measure C: Human approval and exception burden

Measure D: Containment and reconciliation evidence

Measure E: Accepted workflow outcome movement

Measure F: Material authority or security exception

Evidence classifications used in this guide

• VERIFIED: retained decision-fit organisational evidence or an authoritative source within its boundary.
• INFERRED: a reasoned interpretation with evidence, alternatives and limitations visible.
• PROPOSED: a task, schema, control, case or method awaiting acceptance.
• REQUIRES VALIDATION: a material claim or control condition that cannot support pilot handoff yet.

Sources and evidence notes

1. NIST: Strengthening AI Agent Hijacking Evaluations describes indirect prompt injection risk and evaluation research. VERIFIED official technical source; research is evolving.
2. NIST NCCoE: Agent Identity and Authorization concept paper raises identity, authentication, authorization, auditing and injection-control questions. VERIFIED official consultation, not final guidance.
3. Microsoft: Secure autonomous agentic AI systems supports isolated permission, explicit action schemas and deterministic human review. VERIFIED official vendor guidance.
4. Microsoft Agent Framework: Tool approval documents approval-required tool execution outside the model request. VERIFIED official implementation guidance; product-specific.
5. Google Cloud: AI security and safety for MCP servers discusses agent identity, least privilege, tool chaining, approval and injection risk. VERIFIED official vendor guidance.
6. UK NCSC: Thinking carefully before adopting agentic AI advises narrow, low-risk adoption and avoiding unrestricted access to sensitive systems. VERIFIED official guidance.

The action classes, twelve-step method, working files, measurement contracts and visuals are PROPOSED Abrasim methods. They do not claim universal security, standards conformance or business outcomes.