Agentic Responsible AI: An Enterprise Handbook

Governed, observable, and verifiable AI systems

The Observability Layer | Standalone publication, edition 2.0 | Evidence cutoff: 2 October 2026

By Dr. William Fisher. Published by The Observability Layer. This edition is written for readers who have not read the Agentic Responsible AI Compendium. It explains its terminology, operating model, controls, and implementation decisions within this book.

Executive Summary

An enterprise AI agent can do more than generate an answer. It can select tools, retrieve information, retain state, delegate work, and change a business system. Responsible AI therefore has to govern the complete operating system and the consequences of its actions.

The central recommendation is to approve a bounded deployment configuration: a defined business mandate, accountable owner, permitted actions, controlled tools and memory, tested oversight, and independently observable outcomes. Approval should identify the configuration that was evaluated and specify the changes that invalidate its evidence.

• Establish authority before execution. A model's proposed action must pass an independent authorization check. Consequential approvals must bind the actual action, affected resources, permitted variation, and expiry.
• Verify outcomes after execution. Check the external business state before declaring completion. Reconcile partial, uncertain, and duplicated effects. An agent's explanation is supporting evidence, not independent outcome verification.
• Measure prevention and useful work together. Keep critical prohibited effects, business utility, review burden, customer outcomes, and recovery as separate acceptance conditions. A system that refuses every task has not demonstrated useful operation.
• Maintain assurance throughout operation. Changes to prompts, memory, models, tools, permissions, monitors, and delegation can change behavior. Incidents and material changes reopen the relevant control claims.

This handbook supplies the knowledge and artifacts needed to put that approach into practice: definitions and risk assessment, a control architecture, operating and assurance guidance, worked workflows, a 90-day implementation sequence, 45 baseline control practices, 12 detailed implementation specifications, and 36 proposed acceptance tests. The control practices and tests are original proposed enterprise designs. Their presence is not evidence of effectiveness in an enterprise.

Recent research reinforces the need to test complete configurations. Selected September interaction experiments reported 43 pairwise safety failures among components that passed separately. A proactive-monitoring benchmark reported a highest optimal-window interruption result of 40.74% among its evaluated models. These findings concern the specified experiments. They do not estimate an institution's production failure rate. [S11, S13]

Introduction and reader's guide

Purpose and scope

This is an operating handbook for organizations that build, buy, deploy, oversee, or audit AI agents. It addresses software agents acting in enterprise workflows, including read-only research, drafting, customer service, internal operations, and controlled transactions. Physical robotics and specialized clinical, military, or industrial safety cases require additional domain standards and validation.

The aim is to help a reader answer six practical questions: What is the agent allowed to do? Who owns the result? Which mechanisms constrain it? How are those mechanisms tested? What evidence shows what actually happened? How can the enterprise stop, correct, and recover the workflow?

The book develops The Observability Layer's emphasis on actionable control evidence. It retains traceability to the earlier 112-control compendium through an optional cross-reference index. The 45 handbook practices use a separate H-prefix and are fully explained here; the reader does not need the earlier catalog to use them. E01-E12 name the detailed implementation specifications in chapter 18. These identifiers are local to the handbook and are not regulatory clause numbers. [S01, S02]

How the knowledge is organized

Reading paths

How to interpret evidence and examples

Source identifiers such as [S11] resolve to Appendix I. Research findings describe an inspected study or report. Official legal text, agency announcements, technical specifications, and voluntary frameworks retain their different status. Recommendations labeled proposed practice are designs to test locally.

All worked examples, proposed autonomy tiers, templates, control practices, and acceptance tests are illustrative. Their numbers and decision rules are not measured enterprise outcomes or universal targets. Quantitative figures based on published studies identify their sample and limits beside the exhibit. Figure and table captions are part of the interpretation.

The reading flow is layered: learn the concept, examine a failure mechanism, select a control, define a test and independent outcome oracle, and preserve the evidence needed for an operating decision. This structure lets the book serve as both an introduction and an implementation reference.

1. Foundations: AI agents and responsible AI

1.1 From a model response to a business effect

For this handbook, an AI system is a software system using machine inference to produce outputs that can influence a virtual or physical environment. A large language model, or LLM, is one possible component: it generates text or structured outputs from its input. An enterprise agent combines that component with software that allows it to pursue an assigned task through successive observations, choices, and actions. These are working definitions for this book, rather than a claim that every vendor uses the same terminology.

A useful distinction is between the model, the agent harness, and the deployment. The model supplies predictions or generated proposals. The harness assembles context, interprets outputs, calls tools, maintains workflow state, and applies routing. The deployment also includes identities, permissions, business policies, people, resources, and operational controls. Evaluating only the model leaves much of the operating system untested.

An ordinary chatbot can be consequential when its answer influences a customer or professional decision. Tool use adds a further route to consequence: the system can directly change files, records, messages, transactions, or permissions. The risk assessment should follow those influence and effect paths.

1.2 The agent cycle and its control boundaries

The practical agent cycle is observation, proposal, authorization, execution, and outcome verification. Observation can include a document, tool result, conversation, or stored memory. A proposal may change as new information arrives. Authorization must therefore check the action that will actually execute, and verification must inspect what the resource actually did.

Open figure at full size ↗

Figure 1. Proposed teaching model. An action can return new observations and continue the workflow. Authorization, external outcome verification, and protected evidence are outside the agent's authority to alter. The diagram represents required responsibilities, not a product guarantee.

Consider a finance assistant that reads an invoice. The invoice may contain a forged instruction to change the beneficiary. The model may propose that change. A resource gateway should reject it unless the initiating principal's mandate and exact-scope approval permit it. If an authorized payment times out, the workflow should query external state before retrying. Each stage has a different control obligation.

1.3 What responsible AI includes

Responsible AI concerns the purpose, design, operation, and effects of a system on people and organizations. Security protects systems and information against misuse. Safety concerns harmful outcomes, including unintended ones. Privacy limits inappropriate collection, use, retention, and disclosure. Fairness concerns unjustified or harmful differences in treatment or outcomes. Transparency and explainability support informed use and challenge. Accountability assigns decision rights and preserves evidence.

These responsibilities interact. Recording every prompt may help an investigation while creating an unnecessary privacy exposure. Requiring review for every minor action may reduce autonomy while overloading reviewers and delaying access to service. A control design should document those tradeoffs and test the resulting workflow.

The OECD AI Principles provide a widely used values reference covering human rights, fairness and privacy, transparency, robustness and safety, accountability, and broader well-being. NIST AI RMF 1.0 supplies a voluntary structure for organizing risk-management work. This handbook's mechanisms are proposed ways to implement enterprise responsibilities; they do not constitute certification against either reference. [S43, S45]

1.4 What a control claim means

A control is a mechanism or operating practice intended to constrain a risk or achieve an outcome. A claim states what that control is supposed to establish. Evidence supports the claim under specified conditions. A release decision determines which authority is justified by that evidence.

For example, the claim that only approved beneficiaries receive payments requires more than a written prompt. It needs a beneficiary allowlist or equivalent policy, call-time enforcement on every effect route, approved payload binding, negative tests, and independent resource receipts. A passed test supports the tested conditions; it does not prove that an unknown bypass is impossible.

The book repeatedly distinguishes identity from permission, detection from prevention, intention from effect, and a documented process from operating effectiveness. Those distinctions prevent an attractive dashboard or fluent explanation from receiving more assurance credit than it has earned.

2. Scope, impact, risk, and autonomy

2.1 Define the system boundary before rating it

Start with the business process, affected people, resources, and permitted effects. Identify every entry point and downstream consumer. Include generated content that a human may rely on, background jobs, exported files, queued actions, and child agents. A read-only tool grant does not make a workflow harmless if its recommendations determine a consequential result.

Record the intended benefit and a baseline alternative. The alternative might be a manual process, ordinary rules engine, deterministic workflow, or smaller model with constrained tools. A more complex agent design should justify its additional authority and coordination cost through observed business value.

2.2 Rate risk by failure mechanism and consequence

The risk register should name a specific mechanism, affected asset or person, consequence, exposure conditions, prevention or detection control, and residual uncertainty. A label such as hallucination risk is too broad to drive implementation. Wrong currency conversion in a draft and a fabricated payment-success claim need different controls.

A proposed qualitative assessment can consider severity, opportunity for exposure, propagation, detectability, reversibility, and uncertainty. Do not manufacture a numerical probability when the available data only supports a qualitative judgment. Do not let a low-likelihood guess cancel an intolerable consequence.

2.3 Autonomy is a permission decision by action class

The following tiers are a proposed teaching and policy aid, not a universal industry taxonomy or legal classification. An enterprise can approve different tiers for different actions within the same workflow. A research assistant may autonomously retrieve public information while requiring review before sending a client-facing summary.

Open figure at full size ↗

Figure 2. Proposed decision aid. The displayed control requirements increase with permitted behavior. They are policy examples and contain no measured capability or risk scores. Higher tiers do not authorize the agent to change the governance policy.

Treat irreversible disclosures, payments, privilege changes, covered decisions, and externally published content as distinct effect classes. State which require approval and which cannot be delegated. A control failure, unresolved evidence gap, or reviewer-capacity failure should reduce permitted authority until the relevant claim is re-established.

2.4 Establish an exception process that expires

An exception should identify the unmet control, business need, consequence, compensating measure, accountable approver, scope, expiry, and closure evidence. It does not turn an untested mechanism into an effective control. An emergency operating decision should specify how new authority is bounded and how affected evidence will be restored.

3. Enterprise governance and the lifecycle

3.1 Integrate agents with existing enterprise decisions

The enterprise needs a business owner for the complete process, a platform owner for the deployed controls, resource owners for the systems changed, and independent challenge appropriate to the risk. Responsible AI, security, privacy, compliance, model validation, procurement, operations, and audit should have clear interfaces. A committee without explicit decision rights cannot substitute for these responsibilities.

NIST AI RMF 1.0 organizes risk work through GOVERN, MAP, MEASURE, and MANAGE. In plain terms, establish ownership and policy; understand the use and impacts; evaluate evidence; and decide how to treat risks. NIST reports that AI RMF 1.0 is being revised. This book refers to the inspected 1.0 baseline and does not imply that a completed replacement has been adopted. [S43, S47]

The following lifecycle is the handbook's proposed operating implementation. Its gates are distinct decisions with named owners, not a claim that a particular standard prescribes these exact stages.

Open figure at full size ↗

Figure 3. Proposed lifecycle. The enterprise approves the use before building, the bounded configuration before production, and the affected evidence again after material change or incident. Retirement includes credentials, memory, queued work, retention, and business continuity.

3.2 Give the governing body a decision pack

the sources cited here should state the permitted mandate, action classes and autonomy; critical dependencies; evidence for the main control claims; unresolved failures and unknowns; customer and workforce impacts; exception owners and expiry; containment capability; and the next decision requested. Distinguish tested mechanisms from vendor assertions and planned work.

An executive should be able to ask who can stop the workflow, whether the stop mechanism was exercised, and what remains active after the agent process stops. An auditor should be able to select a completed case and join its resource effect to authority, approval, deployment configuration, and independent outcome verification.

3.3 Account for people, intellectual property, and resource use

Assess the work transferred to reviewers and service teams, training needs, accessibility, overreliance, and the effect of new performance expectations. Obtain feedback from affected people through permitted channels. Track burden and correction outcomes rather than equating faster automated output with improved service.

Record permissions and restrictions for retrieved content, licensed data, code, and generated deliverables. A citation identifies a source; it does not itself confer a license to reuse the source. Procurement and legal review should determine applicable rights and contractual constraints.

For resource use, measure calls, tool invocations, compute where observable, retries, and cost by workflow. Treat supplier energy or water data as measured or estimated according to its actual provenance; do not convert token counts directly to a claimed carbon footprint without a valid model. NIST's GenAI Profile includes environmental impact and intellectual-property risk, among other concerns. The measurement design here is proposed practice. [S44]

3.4 Govern the change in the work, not only the software

Training should explain the agent's role, common failure mechanisms, review rights, evidence sources, escalation route, and permitted overrides. Reviewers should practice correction rather than only acknowledging a policy. Changes in staffing, task mix, customer channel, or workload can invalidate oversight assumptions even when the software is unchanged.

4. Threats and failure mechanisms

4.1 Separate ordinary error, misuse, and adversarial influence

An agent can fail through an inaccurate answer, ambiguous mandate, incorrect tool schema, missing data, dependency outage, or unauthorized user request. A deliberate attacker can also place instructions in retrieved content, compromise a worker, poison memory, abuse credentials, or manipulate approval. Test ordinary and adversarial conditions together with the business task.

Prompt injection means attacker-controlled or lower-trust content attempts to redirect the system's behavior beyond the authority of that content. An invoice can supply invoice facts; it cannot authorize a new payment destination merely by containing an imperative. The issue is the attempted crossing of an authority boundary, including later reuse of contaminated state.

OWASP's Top 10 for Agentic Applications 2026 is a voluntary security reference for agents that plan and act across workflows. The table below is this handbook's enterprise failure register, not a reproduction of the OWASP categories or a conformance claim. [S46]

4.2 Build a threat model that names trust boundaries

Identify protected assets, affected people, attacker entry points, ordinary failure sources, permitted identities, data flows, and effect routes. Draw boundaries between user requests, enterprise policy, retrieved data, agent state, monitors, tools, and resource systems. Specify assumptions about the attacker and the infrastructure.

A useful threat record includes the initial access, required privileges, manipulated component, desired prohibited effect, execution path, existing controls, independent oracle, and residual gap. Record attack budget and adaptive feedback for adversarial evaluation. Do not interpret a fixed benchmark rate as protection against an attacker with different capabilities.

4.3 Use defense in depth with clear claim boundaries

Input filtering can reduce exposure. Model instructions can shape behavior. Runtime monitoring can detect concerning trajectories. Authorization gates can constrain effects. Outcome checks can detect incorrect completion. Recovery can stop propagation and support remedy. Each mechanism has a separate claim and failure mode.

An alert-only monitor can be valuable for investigation, yet a prevention claim requires a demonstrated path from observation to effective intervention before the prohibited effect. A broad data-retention policy can preserve context, yet it needs purpose and access limits. The control architecture in the next chapter assigns these obligations to independently testable components.

5. The operating object and its control architecture

5.1 Register the deployment configuration

Proposed practice. Maintain a deployment manifest containing the business mandate, accountable owner, autonomy tier, model and serving version, system instructions, harness version, tool schemas, authorized data, memory policy, monitor configuration, fallback routing, and delegation topology. Add immutable hashes where feasible and record external versions that cannot be fully pinned.

The configuration digest is the join key between an approved release, an evaluation result, and a production trajectory. An inventory record that contains only the model name cannot establish which controls operated on a particular action. A vendor's moving alias should be recorded alongside resolved versions or documented limits on version visibility.

Open figure at full size ↗

Figure 4. Proposed reference architecture. The reasoning layer proposes work. The execution layer enforces authority and controls effects. The evidence layer records independently observable decisions and results. The arrows represent permitted information or execution flow, not proof that any particular framework implements these boundaries.

5.2 Prevention and evidence are separate obligations

The runtime-contract position paper distinguishes preventive controls from checkable completion evidence. Contract-monitoring research further proposes separate worker, monitor, and adjudication responsibilities. These are useful architectural ideas; their guarantees depend on specified assumptions and should not be imported as unconditional enterprise guarantees. [S19, S24]

Proposed practice. Implement two gates. Before an action, establish authority and satisfaction of hard policy constraints. After an action, independently confirm the intended postcondition before claiming completion or releasing the next stage. A tool's HTTP success status can be inadequate if its business result is asynchronous, partial, duplicated, or later rejected.

For a payment workflow, evidence may include an accepted transaction identifier, an independently queried status, the exact amount and beneficiary, and a reconciliation outcome. For a research workflow, it may include accessible citations, period and unit alignment, calculation checks, and an identified evidence cutoff. The gate should match the business assertion it supports.

Environment-steering research supplies a concrete example of enforcing record-level data-flow policy through execution state and feedback. That implementation is a replication candidate, with benchmark-specific evidence, rather than a general enterprise guarantee. [S20]

5.3 Specify a failure policy for every dependency

6. Authority, identity, approvals, and protocol changes

6.1 Identity must support attribution and constrained delegation

NIST's September identity work moves toward implementation demonstrations in DevSecOps, with additional use cases still to be scoped. The inspected material is project and consultation output, not a completed agent-identity certification regime. It supports the identity and delegation responsibilities explained in the H-DES and H-MAS practices in Appendix B. [S25, S26]

Proposed practice. Distinguish the agent service identity, initiating human or business principal, delegated child identity, and actual resource credential. Preserve the relationships without granting children a parent's full authority. The effective grant is the intersection of the parent's grant, the child's mandate, current resource policy, and unexpired approval.

Open figure at full size ↗

Figure 5. Proposed delegation pattern. Every child inherits a constrained authorization context and must pass resource-level enforcement. Child identities remain attributable. The independent policy and evidence services are outside the agents' authority to modify.

6.2 Approval is a transaction with a bounded meaning

Proposed practice. Show the reviewer the initiating request, proposed effect, relevant evidence, affected resources, applicable limits, and recovery options. The approval record should bind a specific action digest or a defined batch, expiry, reviewer identity, and permitted scope. A batch approval must specify every dimension over which variation is authorized.

Recheck policy after review. If the execution payload differs materially, require a new decision. Prevent the agent from granting approval, using a child's approval to authorize its parent, or interpreting an unrelated conversation as transactional consent. Measure review quality using planted failures and normal cases under realistic workload, not only a count of approvals.

6.3 Model Context Protocol (MCP) 2026-07-28 requires a migration-specific review

The inspected MCP release adopts a stateless protocol core, changes discovery and metadata handling, and introduces authorization hardening including issuer validation. Application state can still persist through explicit handles. The security specification requires intended-audience checks and prohibits token passthrough. Protocol-compliant authentication does not establish business authorization for each tool action. [S27, S28]

6.4 The Agent Control Standard (ACS) is an integration candidate that still needs enforcement proof

OWASP's Agent Control Standard supplies hooks and a declarative control interface. The inspected repository exposes version 0.1.0 and explicitly limits one demonstration to two live hook methods. This is useful implementation infrastructure; it is not evidence of universal hook coverage or framework interoperability. [S29, S30]

Proposed practice. Create an adapter conformance matrix for each adopted framework: supported hook, enforced action surface, failure behavior, bypass route, evidence emitted, and regression test. Include shell subprocesses, background jobs, browser actions, network libraries, child agents, and raw database clients. A registered hook earns control credit only on the routes where it actually mediates effects.

7. Knowledge, memory, privacy, and durable state

7.1 Retrieved content must retain its authority level

Proposed practice. Treat retrieved documents, emails, tool descriptions, web content, and inter-agent messages as data with provenance and an explicit trust class. They cannot independently grant privileges or create a new user instruction. Record origin, tenant, owner, permitted use, retrieval time, effective date where relevant, and the policy that allowed admission.

A content filter can contribute useful evidence. The permission boundary still has to enforce what a tool may do. Delayed-injection research adds a reason to revisit the full lifecycle: malicious influence may remain inactive at ingestion and only become consequential in a later context. [S15]

7.2 Preserve safety state across runs without retaining everything forever

Loop-state research shows an observation limitation: a monitor confined to inner execution windows cannot detect evidence that exists only across those windows. Its mathematical bounds depend on mediated commits and stated detection assumptions. Those assumptions must be established before treating the bounds as operational assurance. [S18]

Proposed practice. Maintain external workflow safety state: pending approvals, accumulated budget consumption, prior policy denials, unresolved provenance warnings, previously quarantined artifacts, and descendant relationships. Avoid automatically clearing relevant risk state when an agent restarts, compresses context, changes model, or opens a new task.

The desired persistence is a policy decision, not indiscriminate retention. Separate a minimal risk register from raw prompt and document content. Set retention by record class, applicable obligation, operational purpose, and deletion rights. Test whether removal of customer data leaves the permitted minimum evidence and whether restoration can resurrect revoked data or authority.

Open figure at full size ↗

Figure 6. Proposed memory lifecycle. Admission, promotion, reuse, and repair each require a decision outside the agent's narrative. A tainted item can have derived artifacts, so removing only the original entry does not demonstrate complete repair.

7.3 Privacy controls need action-level tests

Proposed practice. Test the permitted combination of source, recipient, purpose, and output channel. A correct statement can still be an unauthorized disclosure. Include queries, search terms, URL parameters, attachments, code comments, logs, tool errors, and model-provider requests in the egress inventory.

8. Fairness, customer outcomes, and meaningful human authority

8.1 Scope the decision path, including selection before the final decision

Proposed practice. Identify actions that make or materially influence a covered decision. Include document requests, evidence retrieval, missing-data handling, routing, prioritization, recommendations, escalation, notices, and redress. A flow can disadvantage a group before it reaches the model that receives the formal fairness review.

The ARIA finance architecture illustrates collective exclusion and drift monitoring in constructed simulations. It supplies mechanisms to test and an architectural hypothesis. Its authors explicitly do not establish production effectiveness. The enterprise response should therefore be a falsifiable test plan and observed outcome monitoring. [S23]

Open figure at full size ↗

Figure 7. Proposed decision-path review. Align eligible cohorts at each stage so that a favorable final-stage rate cannot conceal an earlier exclusion. The diagram contains no measured customer data.

8.2 Preserve the actual reasons for adverse action

Regulation B's notification provisions require specific principal reasons for covered adverse action, subject to the applicable rule and procedural alternatives. The governing text, rather than an agent's generated explanation, is the source for the obligation. [S37]

Proposed practice. Capture the factual and policy basis that actually influenced a covered decision. Link it to the configured workflow and to any independently validated quantitative model used within it. An agent may help draft a notice using an approved reason vocabulary and recorded facts; the notice must be checked against the actual basis. Do not infer legal reasons from raw chain-of-thought or from an unsupported post-hoc narrative.

8.3 Human reviewers need competence, access, and authority

Proposed practice. Specify the reviewer's decision rights, available evidence, time budget, conflict rules, escalation path, and authority to reverse or suspend. Train with normal cases and seeded failures that test factual reasoning, scope, consent, and customer rights. Review samples where humans disagreed with the agent, agreed with it, and failed to notice a planted error.

Measure reviewer competence over time. Include performance under peak queue load, unavailable evidence, language differences, accessibility needs, and ambiguous instructions. A reviewer who cannot obtain the relevant evidence or change the result cannot supply the intended operating control.

8.4 Fairness screening is an investigation method

Proposed practice. Predefine outcomes, relevant groups, lawful data use, minimum reportable cell sizes, confidence methods, and escalation criteria. Use matched and counterfactual cases where appropriate, and observed production cohorts where permitted. Investigate overlapping group membership, differences in eligibility, geography, task difficulty, and missing data.

Do not treat a universal selection-rate ratio as a safe harbor across lending, insurance, hiring, and other domains. Do not convert small-cell uncertainty to a zero-disparity conclusion. Retain an alternative-design record: policy simplification, different evidence requests, earlier human routing, constrained tool selection, and accessibility changes can all be tested against the original workflow.

9. A decision-grade evaluation program

9.1 Define the decision before selecting the benchmark

Proposed practice. Specify the business task, consequence of failure, authorized autonomy, prohibited effects, deployment environment, and release threshold before testing. Register the evaluated configuration and each material deviation from production. Test both normal and adversarial work at the intended run length and concurrency.

FinFIRST distinguishes financial search evidence from final-answer correctness, including temporal validity, source authority, entity and reporting-period alignment, units, and traceability. Its 123 expert-authored tasks supply a useful research reference, but a public search benchmark does not validate an institution's private data, suitability rules, or transaction authority. [S22]

9.2 Use a layered test portfolio

Every scenario should identify an external outcome oracle. For state changes, use the resource state, transaction log, or an independently maintained test fixture. For factual or rights-related judgments, use a documented rubric, authoritative sources, and adjudication of disagreements. An LLM judge can assist; report its validation, conflict rate, and uncertainty rather than silently treating its labels as ground truth.

9.3 Keep thresholds interpretable

Proposed practice. Release decisions need separate acceptance conditions for prohibited effects, authorized utility, review burden, latency, recovery, and customer outcomes. Do not collapse them into a weighted score that lets high utility compensate for a forbidden transfer or disclosure.

9.4 A zero-failure result still has a sampling limit

For independent, identically distributed Bernoulli trials with zero observed failures, the exact one-sided 95% upper failure-probability bound is:

upper_bound = 1 - 0.05^(1/n)

This follows by solving (1 - p)^n = 0.05. It is an analytical illustration, not observed enterprise data and not a proposed minimum test quota.

Open figure at full size ↗

Figure 8. Analytical illustration under independent, identically distributed Bernoulli sampling. The upper confidence bound describes uncertainty after zero observed failures in the specified trial distribution; it does not establish coverage of unseen hazards or a posterior probability of safety.

Interpretation. Exact zero-event binomial calculation, rounded only for display. Repeated attacks on the same task, related seeds, shared infrastructure, and selected cases may violate independence or representative sampling. A bound for the sampled population does not establish the failure probability on unseen production tasks. Report clustering and separate strata rather than hiding them in a large aggregate sample count.

9.5 Treat configuration changes as evidence expiry events

Proposed practice. Define re-evaluation triggers for changes to models, monitor versions, tool schemas, permissions, memory transformations, instructions, retrieval data, delegation topology, business policy, and fallback behavior. An unchanged model with changed tools is still a changed operating system.

Open figure at full size ↗

Figure 9. Proposed release process. Independent component checks are necessary, and the gate also examines affected interactions. Candidate generation and production authorization remain separate decisions. A shared holdout set must not become the optimization feedback channel. Retain a baseline, a candidate manifest, targeted interaction coverage, repeated outcomes, new failure cases, and a documented go/no-go decision. If exhaustive combinations are infeasible, prioritize interactions sharing authority, data, persistent state, or consequential effects, and state the remaining coverage gap.

10. Monitoring that supports an operational safety claim

10.1 Measure the full path from observation to effect

Proposed practice. Define event time, monitor receipt, decision time, enforcement time, and resource effect time. Measure clock uncertainty, queue delay, and loss. A prevention claim must show that enforcement occurred before the relevant effect or that the action was held pending the decision.

For asynchronous work, a cancellation request is not proof of cancellation. Include already issued credentials, spawned jobs, delegated workers, queued messages, and in-flight transactions in the halt test. Record the point after which only reconciliation or compensation is available.

Latency percentiles p50, p95, and p99 are the values at or below which 50%, 95%, and 99% of observed delays fall. Report critical overdue cases as well as the distribution. The binary safe-completion rate here differs from the fractional-utility Safe Success metric used in the HARDE study in chapter 17.

Use the same unit of analysis in the numerator and denominator. An alert count, an action count, and a workflow count answer different questions. A run can contain several related harmful actions; counting each as an independent failure inflates apparent sample size.

10.2 Validate the monitor on unfamiliar failures

The lie-detector study reports an in-distribution increase in area under the receiver operating characteristic curve (AUROC) from 0.60 to 0.95 and held-out-category performance around 0.70-0.75. These are discrimination statistics, not recall at an enterprise operating threshold or the probability that a specific assertion is deceptive. The distinction matters when a monitor determines whether an agent may act. [S17]

TACIT separates harmful content from context-dependent unsafe tool use and studies frozen internal-state readouts. Its reported gains make it a candidate for replication when the required model instrumentation is available. They do not establish prevention, universal out-of-distribution transfer, or availability through a particular managed-model API. [S21]

10.3 Reasoning traces are supporting evidence

Proposed practice. Capture approved traces when available, with access controls and a defined retention purpose. Distinguish raw internal traces, provider summaries, agent explanations, and externally observed actions in the schema. Each has a different evidentiary meaning.

The authoritative account of a payment is its initiation, authorization, execution, and reconciled state. The authoritative account of a disclosure is the observed destination and data classification. A persuasive explanation cannot override contradictory resource evidence. Absence of a reasoning trace should be visible as a capability limitation rather than filled by invented rationale.

11. Multi-agent operation and the third-party perimeter

11.1 Register topology, shared state, and joint authority

Proposed practice. Inventory every child agent, role, message route, shared artifact store, memory store, scheduling rule, communication adapter, and credential path. Record which boundaries are independent and which depend on the same model, provider, policy engine, or hosting service.

The unit for consequential-outcome testing is the complete workflow. A child can write a seemingly harmless artifact that causes another child to take a prohibited action later. A monitor that sees only a local message may miss the combination. ORBIT's threat-specific defense results support testing the architecture and threat together; they do not support a single monitor label as a system-wide assurance claim. [S14]

When learned representation-space links are used, include the link's weights, training procedure, and version in the deployment manifest. The latent-communication study makes those links a specific candidate risk surface. Its findings should not be generalized to ordinary text-based communication without additional evidence. [S16]

11.2 Aggregate consequences without expanding surveillance unnecessarily

Proposed practice. Aggregate task lineage, actions, derived artifacts, resource effects, policy decisions, and budget consumption. Preserve access controls over the underlying customer content. Reviewer views can expose the evidence needed for a question without giving every operator unrestricted access to all prompts and records.

Run a necessity assessment before adopting a multi-agent topology. Compare it with a simpler baseline using safe task completion, operational complexity, reviewer burden, and incremental authority. More agents create additional coordination and attribution work; the benefit should be measured rather than assumed.

11.3 Request a vendor evidence pack that can be challenged

Certification, a system card, and contractual promises can support distinct parts of the assurance case. None independently demonstrates that the institution's configured agent will respect its own authorization policy. Preserve the scope of each artifact instead of treating them as interchangeable approvals.

12. Operational telemetry, metrics, and assurance evidence

12.1 Minimum event contract

Proposed practice. Use a shared event schema with stable identity, authority, policy, effect, and outcome fields. Standard tracing can supply transport and correlation conventions. It does not by itself supply the complete business-control semantics. The inspected OpenTelemetry GenAI registry still labels the relevant operation attributes as Development, so pin the mapping version. [S42]

These are proposed semantic fields, not official OpenTelemetry attribute names. Keep personal data out of high-cardinality identifiers where possible, and protect any mapping needed to resolve the business subject.

12.2 An operating scorecard

Set institution-specific escalation thresholds before operation. Name who can stop a workflow or accept a time-limited exception, and how remediation reopens the gate.

12.3 Build a claim-centered assurance case

Open figure at full size ↗

Figure 10. Proposed assurance chain. A control claim links to a mechanism, a test, external outcome evidence, independent challenge, and the operating decision. A change or incident expires affected claims and initiates new work.

13. Incidents, containment, recovery, and retirement

13.1 Define an incident by observable consequence and control failure

An agent incident can involve an unauthorized effect, sensitive disclosure, material factual error, incorrect customer decision, failed review, missing evidence, or a control that no longer performs its approved function. Register near misses and blocked attempts separately from committed effects. They provide different evidence about exposure and prevention.

The response design should identify who receives the alert, who can revoke authority, who owns the resource reconciliation, who determines reporting and remedy, and who approves restart. Use existing enterprise incident channels with agent-specific evidence and descendant handling.

These categories are proposed operating triggers. Local severity definitions, escalation windows, and reporting duties should be assigned by consequence and obligation. A speculative alarm and a confirmed external effect should not receive the same factual description.

13.2 Stop authority and reconcile effects

Stopping the agent process may leave child agents, scheduled work, queues, credentials, callbacks, or already accepted resource operations active. Revoke the relevant grants and prevent new commits at the resource boundary. Record when that revocation becomes effective. Test every covered route rather than assuming a user-interface stop controls all effects.

Open figure at full size ↗

Figure 11. Proposed incident workflow. Containment covers authority and descendants. Unknown or partial resource effects are reconciled before retries or restart. Repair, fresh evaluation, and accountable authorization are separate steps.

Preserve the configuration, mandate, policy version, triggering material, approvals, resource receipts, state snapshots, and relevant lineage. Apply custody and access rules, including minimization of unnecessary personal data. Preserve uncertainty: a missing receipt is an unresolved observation until checked against the resource.

13.3 Repair the cause and the propagation path

Repair can involve policy or schema correction, credential withdrawal, dependency rollback, poisoned-source revocation, derivative invalidation, reviewer training, or process redesign. Examine summaries, caches, reusable skills, delegated artifacts, backups, and downstream decisions for continued influence.

Distinguish rollback from compensation. Restoring a previous harness does not unsend an email or reverse a disclosure. A payment correction, refund, customer notice, or decision reopening has its own authority, evidence, and legal context. The business owner should establish which affected cases need remedy or lookback.

13.4 Require fresh evidence for restart

13.5 Retire systems without leaving active influence

Retirement closes grants, child processes, schedules, callbacks, queues, and stored credentials. Decide how retained memory, derived artifacts, historical decisions, evidence, and unresolved customer duties are handled. Transfer business continuity and ownership before removing the service. Verify that an old job, backup, or credential cannot revive withdrawn authority.

14. Worked enterprise applications

These are synthetic design examples. They contain no private customer data, measured enterprise outcomes, or estimates of actual deployment prevalence.

14.1 Financial research and advisor support

Mandate: Retrieve and summarize approved financial evidence for a human advisor. The agent cannot execute trades, grant suitability approval, or provide unreviewed personalized recommendations outside its authorized role.

Design: Restrict sources and data classes; record retrieval/effective dates; use deterministic calculation tools for financial arithmetic; distinguish observations, assumptions, scenarios, and advice. Require citations that support the exact entity, period, currency, and claim. Where evidence is unavailable or conflicting, produce an explicit unresolved result.

Evaluation: Include revised filings, stale rates, similarly named entities, currency conversion dates, inconsistent units, unsupported comparative claims, and malicious source content. Verify both answer correctness and evidence traceability. The reference value of FinFIRST is its workflow-oriented evaluation approach, not automatic suitability assurance. [S22]

Acceptance artifacts: Source register, versioned calculation recipe, adjudicated answer rubric, citation checks, disclosure handling, and advisor review outcomes. Enable drafting autonomy only within that approved evidence and tool perimeter.

14.2 Back-office payment or reconciliation workflow

Mandate: Reconcile records and propose bounded corrective actions. Payment initiation, beneficiary changes, and account modifications receive their defined consequence-specific controls.

Design: Keep the agent separate from the resource authorization service. Bind approvals to normalized payloads and expiry; enforce shared budgets across children; use idempotency keys; independently query committed state. A retry after a timeout first resolves whether a transaction already occurred.

Evaluation: Change the beneficiary after approval, reuse an old approval, distribute spend across children, inject a delayed instruction through a document, delay a monitor, and revoke credentials mid-run. Exercise partial commits and recovery without relying on the agent's completion statement.

Acceptance artifacts: Denied/accepted call records, transaction receipts, state reconciliation, duplicate-prevention evidence, global exposure ledger, and a halt drill that includes queued work. Increase autonomy by permitted action class rather than by a single workflow-wide trust score.

14.3 Customer service, complaints, and covered decisions

Mandate: Answer routine questions and prepare evidence for a human decision where policy or applicable law requires review. Account closure, credit decisions, restricted data disclosure, and customer redress follow their specific rules.

Design: Separate explanation from decision authority. Preserve the actual factual/policy basis, give reviewers correction authority, and make reopening accessible. Scope vulnerable-customer and accessibility safeguards to the process and applicable obligation.

Evaluation: Include thin-file customers, incomplete records, conflicting documents, language differences, repeated document requests, an unjustified refusal, a wrong adverse-action reason, and a correction that changes the decision basis. Compare stage-level outcomes with aligned eligible populations.

Acceptance artifacts: Decision-stage inventory, approved policy boundaries, actual reason record, reviewer competence evidence, notices, reopening results, and a remediation lookback. An agent-assisted human decision still requires evidence that the human review changed outcomes when it should have.

14.4 A payment example from request to reconciliation

This example is synthetic. Its amount, limits, and sequence illustrate a control design; they are not a recommended financial threshold or an executed transaction. The workflow is permitted to prepare reconciliations and execute an approved payment of 1,250 currency units to Supplier-A. Beneficiary changes are excluded from the mandate.

A useful negative variant changes the beneficiary after approval. The expected outcome is rejection before commit, with the changed action and reason recorded. Another variant splits spending across two children; the shared budget must still apply. The oracle for either test is resource state and authorization evidence, rather than the agent's claim that it behaved safely.

14.5 A research answer with an evidence contract

For a synthetic research task asking whether an issuer's margin improved, the agent must identify the issuer, reporting periods, currency, unit, source versions, and margin definition. If operating profit is 18 and revenue 120 in one period, the margin is 15%. If the prior comparable margin is 13%, the change is 2 percentage points. These inputs are invented for teaching and are not issuer data.

The acceptance record should preserve the source-to-input mapping, deterministic calculation, comparable-period check, answer wording, and independent rubric. If the sources describe different consolidation boundaries or a revised period, the answer should state the unresolved comparison. A link to a document does not establish that the document supports the exact claim.

14.6 A customer correction that changes the decision

In a synthetic service workflow, an incomplete record leads the agent to recommend rejecting a request. The reviewer must be able to obtain the missing evidence, correct the record, and change the recommendation. The customer-facing explanation should reflect the basis actually used, with applicable notice and review rights.

The test oracle checks the stage records and corrected outcome. It also checks whether derived summaries, open tasks, and later agents retain the earlier rejection. An accessible reopening channel is effective only if corrected evidence can reach the decision and any affected downstream use.

15. A 90-day implementation sequence

This is a proposed sequence for a first controlled workflow, not a claim that every enterprise can complete the work with existing staffing. Select a process with a clear success oracle, a named resource owner, and bounded consequences. Schedule depends on access, integrations, procurement, reviewer capacity, and the maturity of existing controls.

15.1 Responsibilities across the three lines

Assign one accountable role per deliverable in the local RACI. Internal audit should retain independence from designing or approving the controls it will later audit. Legal review should establish applicable duties and exemptions without substituting for technical enforcement tests.

15.2 What the governing body needs

The operating pack should contain the permitted business mandate; maximum autonomy by action class; system configuration and material dependencies; evidence for the critical control claims; unresolved misses and coverage gaps; customer impacts; exception owners and expiry; incident/recovery results; and the basis for the next operating decision.

Keep detection performance separate from prevention. Identify any claim that relies on an untested vendor assertion, unavailable reasoning trace, missing effect oracle, or unresolved legal applicability. A governed exception should be explicit, time-limited, attributable, and accompanied by a containment plan. It should not silently become evidence that the control works.

15.3 A reusable incident drill

16. Regulatory and standards scope

This table distinguishes regulatory text, official implementation information, supervisory guidance, draft rules, and voluntary technical documentation. Applicability still depends on the entity, jurisdiction, role, decision, and data. This chapter supplies an implementation crosswalk rather than a comprehensive legal opinion.

The EU legislative links returned an access/anti-bot limitation during this review. The timeline above is attributed to the Commission's official implementation page; this report does not claim a completed review of the amending or consolidated regulation. Colorado and California draft/final status and dates are stated at the inspected source level. Avoid placing one jurisdiction's record-retention or incident-reporting clock on every enterprise agent.

16.1 Foundational voluntary references

NIST AI RMF 1.0, its Generative AI Profile, the OECD AI Principles, and OWASP agent security guidance supply different forms of context. They are voluntary references; this handbook does not assert certification, complete clause coverage, or legal compliance from using its practices. Record which version and scope the enterprise adopts, and distinguish its internal policy commitments from external duties. [S43, S44, S45, S46, S47]

17. What current research changes

17.1 Read evidence at its demonstrated scope

The primary-source review emphasizes July through September 2026, with an inspected paper revision dated 1 October included. It preserves older authoritative sources where they establish the operating or legal baseline. A benchmark, incident, simulation, protocol, and proposed architecture answer different questions.

Use the findings below to improve falsifiable enterprise tests. A research result motivates a mechanism and a replication candidate. Its transfer to a business workflow requires a matched configuration, threat model, task population, external oracle, and operating evidence.

17.2 Evidence that merits implementation attention

The following findings have different evidentiary meanings. A benchmark experiment, a live incident report, a simulation, a protocol specification, and a proposed architecture should not receive the same assurance weight.

17.3 Three quantitative exhibits, three distinct questions

Open figure at full size ↗

Figure 12. Selected PASTABench results from section 4.2. Each rate uses the study's 1,139 trajectories. The metric requires a correct specific risk label and an interruption between the annotated earliest signal and trigger. Early interruption can prevent the hazard while failing this timing metric; the chart does not measure realized harm. Model names are the paper's labels. [S11]

Open figure at full size ↗

Figure 13. Joint safety failures after baseline and singleton-update checks: AgentDojo 22/157; Agent-SafetyBench 2/11; Agent Security Bench 19/1,243. Rates are independently recomputed from Table 2. They are not pooled, ranked as deployment risk, or extrapolated beyond the selected interaction panels. [S13]

Open figure at full size ↗

Figure 14. HARDE Table 1. Base has no defense; Vanilla monitor and HARDE use DeepSeek-V4-Flash. Safe Success averages paired per-run utility times attack non-success, not aggregate means. Values are paper-reported three-run averages within each benchmark, with no confidence intervals or enterprise effectiveness claim. [S12]

The table illustrates a practical evaluation principle: the joint outcome can change when the defense changes, and greater blocking can reduce utility. Safe Success must be calculated from paired run-level outcomes. Multiplying an aggregate safety rate by an aggregate utility rate does not recover it unless the required independence relationship has been established.

18. Twelve detailed implementation specifications

These specifications are proposed practice. Each contains its objective, required behavior, implementation, maturity progression, ownership, evidence, handbook mapping, optional historical anchors, and source basis. E01-E12 identify the mechanisms discussed throughout the main chapters. They are not additional statutory requirements.

E01. Join the deployed configuration to its approval evidence

Objective: Ensure the system being operated is the system that was approved.

Control: Each production trajectory identifies an approved configuration and current mandate; material configuration changes reopen relevant release evidence.

Implementation: Generate a manifest at build/release time. Store it independently of agent memory. Resolve provider aliases where possible and expose unresolved version visibility as a limitation.

Maturity: Baseline records the manifest; Enhanced automates production comparison; Frontier identifies affected evaluation coverage on change.

Ownership: First line business and platform own deployment identity; second line validates materiality and release gates; third line tests the linkage.

Evidence: Manifest, configuration digest, production attestation, change record, and re-evaluation decision.

Handbook practices: H-GOV-01, H-DES-01, H-MON-04, H-ASR-01

Original anchors: GOV-03, GOV-11, EVL-16, TPR-03.

Source basis: Historical TOL context [S02, S03, S07]; interaction research [S13]. Exact implementation is proposed.

E02. Enforce authority at the consequential-effect boundary

Objective: Prevent approved credentials or a misleading review from enabling an unauthorized effect.

Control: Each consequential commit passes current resource authorization, limits, and any required action-bound approval outside the agent's control.

Implementation: Normalize the action, bind review to its digest, revalidate after review, enforce idempotency, and deny raw bypass routes. An asynchronous transaction requires its own cancellation and reconciliation logic.

Maturity: Baseline mediates privileged tools; Enhanced covers subprocesses and background work; Frontier verifies enforcement routes continuously.

Ownership: First line platform and resource owners enforce; second line approves consequence policy; third line re-performs bypass tests.

Evidence: Authorized/denied calls, payload-drift tests, approval records, resource receipts, and bypass inventory.

Handbook practices: H-DES-02, H-RUN-01, H-RUN-02, H-RUN-03

Original anchors: DES-08, DES-09, RUN-15, RUN-17.

Source basis: MCP security requirements [S28], AISI incident [S38], and runtime-contract framing [S24]. Design details are proposed.

E03. Verify completion from external business state

Objective: Prevent false completion and downstream reliance on an unverified result.

Control: Critical completion claims require an independent postcondition check appropriate to the claimed business outcome.

Implementation: Declare the expected state, query or observe it independently, reconcile partial effects, and retain failure or uncertainty rather than overwriting it with a success narrative.

Maturity: Baseline checks critical outcomes; Enhanced records reusable evidence contracts; Frontier propagates verified status and invalidation to dependent workflows.

Ownership: First line process owner defines success; platform supplies the verifier; second line challenges validity; third line samples completed cases.

Evidence: Postcondition specification, receipts, independent state checks, failed-completion cases, and reconciliation.

Handbook practices: H-EVL-01, H-RUN-04, H-MON-01

Original anchors: EVL-07, EVL-08, RUN-18, MON-01.

Source basis: Runtime-contract evidence framing [S24] and financial evidence evaluation [S22]. The postcondition contract is proposed.

E04. Preserve relevant safety state across the workflow

Objective: Prevent limits and unresolved risks from disappearing at task boundaries.

Control: Approved safety state persists across retries, compaction, restarts, model changes, and child-agent delegation.

Implementation: Use an external workflow ledger for budget consumption, revocation, pending approvals, policy denials, and quarantined artifacts. Set retention by purpose and record class.

Maturity: Baseline retains per-run state; Enhanced maintains cross-session lineage; Frontier tests patient, distributed attempts and recovery after restoration.

Ownership: First line platform and process owner operate the ledger; second line approves retention and escalation; third line tests state continuity.

Evidence: Restart and delegation tests, global budget records, revocation propagation, and restoration checks.

Handbook practices: H-DES-04, H-RUN-03, H-MAS-03

Original anchors: RUN-09, RUN-14, MAS-07.

Source basis: Loop-state research [S18] and multi-agent control scope [S06]. Enterprise persistence and retention rules are proposed.

E05. Evaluate delayed influence and repair its descendants

Objective: Keep contextual contamination from becoming enduring authority.

Control: Retrieval and memory tests include later activation, derivative creation, and repair that remains effective after reuse.

Implementation: Track lineage from sources to summaries, skills, caches, and child artifacts. Revoke influence through the lineage and test benign as well as malicious conditional instructions.

Maturity: Baseline separates instructions from data; Enhanced gates memory promotion; Frontier verifies descendant repair under continued adaptation.

Ownership: First line data and platform owners maintain provenance; second line privacy/security define sensitive uses; third line samples repair completeness.

Evidence: Trigger-turn tests, admission decisions, lineage, quarantine records, and post-repair recurrence tests.

Handbook practices: H-DES-03, H-DES-04, H-EVL-03

Original anchors: DES-03, DES-14, EVL-10, RUN-16.

Source basis: Delayed-injection study [S15] and evolving-harness interactions [S13]. The repair workflow is proposed.

E06. Validate affected interactions before approving change

Objective: Detect joint failures hidden by isolated component validation.

Control: Material changes receive targeted joint tests covering shared authority, state, data, and consequential effects.

Implementation: Compare baseline, isolated changes, and combinations. Keep optimization data separate from release holdout data, record selected coverage, and retain newly identified failures.

Maturity: Baseline tests direct dependencies; Enhanced tests prioritized pairs; Frontier adds higher-order and persistent-state interactions with documented coverage limits.

Ownership: First line engineering supplies candidates; second line validation owns challenge and thresholds; third line reviews change decisions.

Evidence: Candidate manifests, interaction matrix, controlled comparison outcomes, holdout lineage, and release minutes.

Handbook practices: H-DES-01, H-EVL-05, H-MON-04, H-TPR-04

Original anchors: EVL-16, MAS-09, MON-12, TPR-03.

Source basis: Controlled harness-composition experiments [S13]. Risk-prioritized coverage rules are proposed.

E07. Limit monitor assurance to demonstrated operating conditions

Objective: Prevent an impressive detection statistic from overstating operational prevention.

Control: Each monitor claim states observed signals, tested threats, operating threshold, error rates, timing, and failure response.

Implementation: Evaluate unseen categories, schema changes, adaptive attacks, context loss, and capacity limits. Test the monitor with its actual trigger and feedback logic. Keep hard authorization enforcement independent.

Maturity: Baseline measures threshold errors; Enhanced adds holdouts and delay tests; Frontier maintains repeated adaptive red-team evidence.

Ownership: First line operates monitoring; second line validates the claim; third line verifies the evidence and response mechanism.

Evidence: Confusion counts, labeled corpus, latency distribution, coverage exclusions, outage tests, and residual failures.

Handbook practices: H-EVL-04, H-MON-02, H-RUN-05

Original anchors: GOV-13, RUN-10, MON-07, MON-08.

Source basis: Monitor generalization [S17], harness optimization [S12], and AISI monitor red teaming [S40]. Operating policy is proposed.

E08. Prove protocol and adapter enforcement coverage

Objective: Keep protocol integration from creating hidden control bypasses.

Control: Adopted versions and adapters have a conformance record and a tested inventory of all effect routes.

Implementation: Validate request identity, issuer/audience, state handles, cached tools, approval exchanges, and downgrade paths. Test supported ACS hooks and unsupported routes separately.

Maturity: Baseline pins versions; Enhanced automates conformance and bypass tests; Frontier correlates live route coverage with deployed capabilities.

Ownership: First line integration/resource teams enforce; second line security approves standards; third line samples claimed routes.

Evidence: Protocol versions, adapter matrix, token-negative tests, hook coverage, and bypass outcomes.

Handbook practices: H-DES-02, H-RUN-01, H-TPR-01

Original anchors: DES-13, RUN-15, TPR-06.

Source basis: MCP release/security [S27, S28] and ACS documentation [S29, S30]. Adapter acceptance is proposed.

E09. Test multi-agent outcomes across threat and topology

Objective: Bound consequences that emerge only across several agents.

Control: Delegated workflows receive end-to-end testing and maintain constrained child authority and aggregate effect evidence.

Implementation: Vary topology, shared memory, scheduling, worker compromise, coordinated violations, and ordinary errors. Include learned links only where used. Compare with a simpler baseline.

Maturity: Baseline records topology and lineage; Enhanced varies threat/topology pairs; Frontier adds distributed, cross-session adaptation scenarios.

Ownership: First line orchestrator/process owner governs the system; second line validates aggregate risk; third line challenges system-level sign-off.

Evidence: Topology manifest, delegation grants, artifact lineage, joint outcomes, and global budget tests.

Handbook practices: H-MAS-01, H-MAS-02, H-MAS-03, H-MAS-04

Original anchors: MAS-01, MAS-03, MAS-05, MAS-10.

Source basis: ORBIT [S14], latent-link study [S16], and loop-state research [S18]. Acceptance rules are proposed.

E10. Measure customer outcomes across the complete decision path

Objective: Detect uneven treatment that occurs before final decision scoring.

Control: Covered workflows measure aligned eligible cohorts, intermediate exclusions, decision errors, and redress outcomes under an approved fairness protocol.

Implementation: Register stages and eligible populations; compare evidence burden, routing, review delay, and results. Investigate differences and test alternative designs before attributing cause.

Maturity: Baseline scopes covered decisions; Enhanced captures stage-level outcomes; Frontier joins production evidence to remediation and alternative-design tests.

Ownership: First line business owns outcomes; second line compliance/fairness validates the protocol; third line tests lineage and remediation.

Evidence: Cohort definitions, stage counts, uncertainty, reason records, alternatives, and lookback decisions.

Handbook practices: H-FCO-01, H-FCO-02, H-FCO-05

Original anchors: FCO-01, FCO-03, FCO-07, FCO-09.

Source basis: Historical TOL fairness [S09], ARIA simulations [S23], and applicable decision-rights sources [S34, S35, S36, S37]. Analysis design is proposed.

E11. Demonstrate human correction competence and approval integrity

Objective: Make human oversight capable of changing consequential outcomes.

Control: Reviewers have necessary evidence and authority, demonstrate competence in seeded tests, and approve a bounded action or batch.

Implementation: Test factual, authorization, and customer-rights errors under ordinary and peak load. Bind approval to scope and expiry. Preserve reasons for override and non-override.

Maturity: Baseline trains reviewers and binds approvals; Enhanced measures error and queue outcomes; Frontier tests competence decay and difficult edge cases.

Ownership: First line business staffs review; second line risk/compliance defines acceptance; third line samples operating effectiveness.

Evidence: Reviewer rubric, planted-case outcomes, queue results, override records, and payload-drift rejection.

Handbook practices: H-GOV-05, H-RUN-02, H-FCO-04

Original anchors: RUN-02, RUN-17, FCO-08, FCO-10.

Source basis: Historical TOL runtime/fairness [S04, S09] and applicable review-rights sources [S34, S35, S36]. Competence tests are proposed.

E12. Link assurance claims to protected operational evidence

Objective: Make important control claims reconstructable and challengeable.

Control: Each material claim links to an approved configuration, a tested mechanism, independently observable outcomes, and a named owner.

Implementation: Correlate policy decisions, approvals, resource receipts, and state checks. Protect integrity and access, reconcile missing events, and rehearse containment and recovery.

Maturity: Baseline supplies a complete case record; Enhanced automates reconciliation; Frontier maintains continuous evidence expiry and challenge.

Ownership: First line platform/process owns evidence; second line validates claims and access; third line re-performs selected tests.

Evidence: Claim ledger, trace custody, event reconciliation, recovery drill, and unresolved limitations.

Handbook practices: H-MON-01, H-MON-03, H-ASR-01, H-ASR-04, H-ASR-05

Original anchors: MON-01, MON-03, MON-10, ASR-10.

Source basis: Existing evidence controls [S05], runtime-contract framing [S24], and telemetry documentation [S42]. Assurance design is proposed.

Appendix A. Glossary and acronym reference

These definitions are the handbook's operational vocabulary. Legal and protocol definitions should be taken from the applicable versioned source. The entries explain the language used in the main chapters without requiring prior AI knowledge.

ACS. Agent Control Standard, a voluntary runtime-control interface inspected in chapter 6. Local adapter hooks and effect-route coverage must be demonstrated.

Action class. A group of operations with the same permission, consequence, and oversight rules. Reading a public file and initiating a payment are different action classes.

Action digest. Integrity value derived from a normalized proposed action. It helps bind review to what executes; normalization and field coverage must be tested.

Adaptive attack. An attack refined after observing defenses or feedback, under a stated search and retry budget.

ADMT. Automated decision-making technology. The legal definition and covered uses depend on the relevant jurisdiction and instrument.

Agent. Task-directed system that selects successive observations and actions using a model and supporting software.

Agent identity. Identity of an agent service or instance used for attribution. Identity alone does not establish permission for an action.

Agentic AI. AI used in systems that select and execute steps toward a task, often through tools, state, and delegation. This book uses an operational definition.

AISI. UK AI Security Institute, the source of the incident, simulation, and monitor-research reports discussed in this handbook.

API. Application programming interface, a software route for invoking a service. An alternate API can become an authorization bypass if it is not controlled.

Approval. A decision by an authorized reviewer to permit a specific action or explicitly bounded batch, with scope and expiry.

ARIA. Governance architecture discussed in source S23, illustrated through constructed multi-agent finance simulations rather than established production outcomes.

Artifact. An output retained or reused by a workflow, such as a summary, file, plan, skill, ticket, or proposed transaction.

Assurance case. Structured argument linking a bounded control claim to its mechanism, owner, tests, evidence, limitations, and operating decision.

Attack success rate. Successful attacks divided by evaluated attack opportunities under the reported success definition, selection, and attacker budget.

Audit trail. Record used to reconstruct decisions and effects. Its completeness, integrity, access, and retention need their own controls.

AUROC. Area under the receiver operating characteristic curve, summarizing score discrimination across thresholds. It is not recall or prevention at a chosen operating threshold.

Authorization. Decision that a subject may perform a particular operation on a resource under current scope, purpose, and policy.

Autonomy. Permission for a system to select or execute actions without a new human decision at each step. It is specified by action class.

Baseline. Reference configuration or process used for comparison. A simpler workflow can be a business baseline; a prior release can be a change baseline.

Bernoulli trial. An observation with a binary event outcome. The exact zero-event bound in chapter 9 assumes independent, identically distributed trials.

Business postcondition. External state that must be true for a claimed business outcome, such as a matched receipt and ledger status.

Canary. Limited production exposure used to observe a validated configuration under bounded consequence and rollback conditions.

CCPA / CPPA. California Consumer Privacy Act / California Privacy Protection Agency. Covered-business and processing scope must be established separately.

Chain of thought. Internal or generated reasoning text associated with a model. Availability and evidentiary meaning differ from resource effects and provider summaries.

Claim. Specific assertion about a control outcome. A claim should name its operating conditions and exclusions.

Collusion / coordinated violation. Multiple agents cooperating or combining actions to violate the overall mandate. Tests can be constructed without attributing human intent.

Commit boundary. Point at which an operation can produce a consequential resource effect. Checks must cover the real effect route and asynchronous behavior.

Compaction. Reduction or summarization of context. Safety state and provenance can be lost unless independently preserved.

Compensation. A corrective business action after an effect that cannot literally be undone, such as a refund or remedial notice.

Confabulation / hallucination. Plausible generated content that is inaccurate, unsupported, or fabricated. The consequence depends on how the output is used.

Configuration digest. Integrity value identifying a deployment manifest. It joins the approved, evaluated, and operating configuration.

Consequence. Effect on people, business resources, rights, security, or continuity if an action or failure occurs.

Contestability. Ability to challenge a consequential outcome through an accessible process that can consider evidence and correct the result.

Control. Mechanism or operating practice intended to constrain a risk or establish an outcome.

Control plane. Components governing permissions, policy, routing, and operation. The reference architecture separates critical controls from agent-editable state.

Correlation / lineage. Links among workflows, agents, actions, source artifacts, and derivatives. Correlation IDs do not by themselves prove causal attribution.

Data minimization. Limiting collected and retained data to what is necessary for an approved purpose and applicable obligations.

Delegation. Granting a child agent a bounded task and authority that cannot exceed the applicable parent and resource limits.

Deployment manifest. Versioned inventory of business mandate, model, harness, tools, permissions, memory, monitors, fallback, and relevant dependencies.

Deterministic enforcement. A rule check whose decision does not depend on the agent generating a compliant narrative. Its inputs and routes still need testing.

DevSecOps. Software development, security, and operations practices integrated across delivery and runtime. NIST identity demonstrations discussed here initially emphasize this setting.

Drift. Change in configuration, data, task mix, population, policy, or operating capacity that may invalidate earlier evidence.

Effect oracle. Independent method for determining what actually happened, such as resource state, transaction receipt, or adjudicated factual rubric.

Egress. Information or network traffic leaving a boundary. Destination and content policy are separate from successful authentication.

Eligible cohort. Population meeting a defined entry condition for a stage or analysis. Changing denominators can conceal earlier exclusion.

Evidence expiry. Reopening of a control claim when relevant conditions, components, or operating evidence change.

Fairness. Assessment and management of unjustified or harmful differences in treatment or outcomes, within the domain, law, and affected population.

Fallback. Alternative model, tool, process, or human route used when the primary path fails. It requires its own permitted scope and evidence.

False negative. A labeled harmful or relevant case that a detector misses under a defined threshold and labeling protocol.

False positive. A labeled benign or irrelevant case flagged under the detector protocol. It can create interruption or review burden.

FinFIRST. Financial search-agent evaluation benchmark discussed in S22, emphasizing retrieval, sourcing, and traceability. It does not establish suitability or production assurance.

GenAI. Generative artificial intelligence, producing content such as text, code, images, or structured outputs.

Global budget. Limit maintained across the entire workflow and its descendants, rather than separately reset by every worker or retry.

Grant. Scoped authorization context identifying subject, purpose, resources, operations, limits, expiry, and revocation conditions.

HARDE. Research system in S12 that jointly optimizes risk triggering, monitoring, and feedback in an agent harness. Reported results are configuration- and benchmark-specific.

Harness. Software coordinating model calls, context, tools, retries, routing, and workflow state.

Holdout. Evaluation data withheld from optimization or tuning. Repeated feedback can compromise its independence.

HTML. Hypertext Markup Language, used for the portable web edition. Its browser behavior requires rendered interaction and accessibility checks.

HTTP. Hypertext Transfer Protocol. A successful HTTP response does not necessarily establish a completed business effect.

Human oversight. Human ability to understand relevant evidence, intervene, correct, or stop within an effective time window.

Idempotency. Property that retrying the same operation does not create an additional unintended effect. It depends on the resource implementation and key scope.

Impact assessment. Documented examination of purpose, affected people, benefits, risks, alternatives, legal context, and controls.

Independent evidence. Evidence not controlled solely by the component whose behavior is being assessed. Independence has architectural and organizational dimensions.

Invariant. Condition intended to hold across every permitted execution, such as no commit with revoked authority.

Issuer / audience. Token issuer and intended recipient. Correct checks help prevent accepting a token from the wrong authority or for the wrong service.

JSON. JavaScript Object Notation, a structured data format used for manifests, example events, and schemas in the supplementary files.

Least privilege. Granting only the resources, operations, duration, and scope needed for the approved task.

LLM. Large language model, a component that generates language or structured outputs from context. It is not the entire agent deployment.

Mandate. Approved business purpose, permitted actions, limits, exclusions, owner, and oversight for a workflow.

Material change. Change likely to affect a relevant risk, authority path, outcome, or assurance assumption. Materiality should be defined locally.

MCP. Model Context Protocol, a versioned integration protocol. Protocol authentication does not establish business authorization for every action.

Memory. Retained information influencing future execution. It can include stored facts, summaries, skills, caches, and workflow state.

Monitor. Component observing signals and producing risk assessments or intervention requests. Its coverage and effective enforcement must be distinguished.

Multi-agent system. Workflow with multiple agents exchanging messages or artifacts, sharing state, or delegating tasks.

NIST. US National Institute of Standards and Technology. Its AI RMF is a voluntary risk-management framework; the identity work discussed here is a project and consultation output.

OECD. Organisation for Economic Co-operation and Development, publisher of the intergovernmental AI Principles used as a high-level values reference.

OpenTelemetry. Open-source observability specifications and tooling. GenAI attribute stability and enterprise semantic mappings should be versioned.

Optimal interruption window. Study-defined interval between an annotated earliest risk signal and trigger. It is distinct from a direct measure of realized harm prevention.

ORBIT. Multi-agent safety and security evaluation framework in S14. Its results motivate testing threats and architectures together.

Outcome. Business or human result of the workflow, independently assessed where possible rather than inferred from a success message.

OWASP. Open Worldwide Application Security Project. Its agent-security guidance and ACS are voluntary technical references, not laws or enterprise-effectiveness certificates.

PASTABench. Research benchmark in S11 using curated synthetic trajectories to assess risk attribution and intervention timing. Its timing metric is not realized harm.

Percentile. Value at or below which a stated percentage of observations falls. p50 is the median; p95 and p99 identify higher-delay portions of a latency distribution.

Policy engine. Component applying current authorization or business rules to a normalized proposed operation.

Prompt injection. Attempt by lower-trust or attacker-controlled content to redirect behavior beyond the authority of that content.

Provenance. Record of origin, version, transformation, and permitted use of information or an artifact.

RACI. Responsibility matrix identifying who is responsible, accountable, consulted, and informed. Assign local roles and avoid conflicting accountability.

RAG. Retrieval-augmented generation, supplying retrieved material to a model. Retrieval does not establish the truth or authority of the material.

Reconciliation. Comparison of expected, recorded, and actual resource states to resolve missing, partial, duplicated, or uncertain effects.

Red team. Structured adversarial testing under a stated threat model, scope, environment, and attack budget.

Residual risk. Risk remaining after controls, including observed failures and uncertainty. Acceptance must be bounded and attributable.

Revocation. Withdrawal of permission or reusable influence. It must propagate to descendants, pending work, and relevant retained artifacts.

RMF. Risk Management Framework. AI RMF refers here to the inspected NIST 1.0 framework, with its scope and revision status identified.

Rollback. Restoring an earlier configuration or state where supported. Some business effects instead require compensation.

Safe Success. The HARDE study metric averaging per-run task utility multiplied by attack non-success. It differs from a binary enterprise safe-completion rate when utility is fractional.

Safe task completion. Authorized successful task outcomes with no defined prohibited effect, measured from paired outcomes in the same runs.

Safety state. Persistent limits, denials, revocation, pending approvals, quarantine, and unresolved hazards needed across execution boundaries.

SDK. Software development kit, providing libraries or integration helpers. SDK adoption does not establish that all effect routes are mediated.

Shadow mode. Operation that produces proposals or comparisons while independently preventing the tested agent from making production effects.

Skill. Reusable procedure, code, or instruction set affecting future agent behavior. Updating it is a configuration and change-governance event.

SR 26-2. US interagency revised model-risk guidance, inspected in chapter 16. Its scope expressly excludes generative and agentic AI.

SSRF. Server-side request forgery, where a service is induced to fetch an unintended destination. Metadata-fetch routes need destination restrictions.

TACIT. Internal-state readout approach discussed in S21. Instrumentation availability and configuration-specific empirical results constrain its use.

Telemetry. Recorded operational events and measurements. Business-control meaning requires more than transport-level tracing.

Tenant isolation. Separation of customer or organizational data, state, authority, and effects across tenancy boundaries.

Three lines. Operating responsibilities, independent risk and compliance challenge, and independent internal audit. Local assignments must preserve audit independence.

TOL. The Observability Layer, publisher context for this handbook and the earlier Agentic Responsible AI Compendium.

Tool. Callable capability that reads information, invokes a service, or changes a resource state.

Trajectory. Sequence of observations, model outputs, actions, artifacts, and effects within a workflow.

Trust boundary. Boundary across which information or authority changes its permitted interpretation or privileges.

Utility. Useful authorized business performance, measured against the task and eligible population rather than merely fluent output.

Zero-event bound. Upper confidence limit for a binary event probability after zero observed events under stated sampling assumptions.

Appendix B. Baseline control reference and optional compendium crosswalk

B.1 How to use the reference

The following 45 practices are original proposed enterprise baselines. H-identifiers are fully specified within this book and are separate from the earlier TOL catalog. Apply each practice according to the system boundary and consequences. Inapplicability needs a reason; an unmet control needs a scoped operating decision. A written practice is not evidence that its mechanism works.

B.2 Governance and accountability

B.3 Design, data, identity, and architecture

B.4 Evaluation and release

B.5 Runtime execution and oversight

B.6 Monitoring and post-deployment evidence

B.7 Multi-agent coordination

B.8 Third-party and supply chain

B.9 Assurance, reporting, and review

B.10 Fairness and customer outcomes

B.11 Relationship to the earlier 112-control compendium

The earlier compendium has 112 identifiers across nine families. The table records that namespace for traceability. It is not a claim that five handbook practices are equivalent to every detailed control in a family. Specific E01-E12 mappings retain selected original anchors alongside explained handbook practices. No original control is renumbered. The prior index remains an optional historical reference. [S02]

The implementation mapping identifies mechanism-level relationships; it is not a statement of legal equivalence, exhaustive coverage, or certification. Use the practice descriptions and evidence here to make the local decision.

Appendix C. Implementation templates and filled examples

C.1 Agent mandate template

C.2 Deployment manifest template

Record mandate ID and version; business and platform owner; model/provider/serving version or visibility limit; harness and instruction digest; tool schemas and adapters; credentials and grant policy; source and retrieval versions; memory transformations and retention; monitor/trigger/feedback versions; fallback; topology and global budgets; policy and event schema versions; approved evaluation and release record.

Protect the manifest from agent edits. A digest establishes an integrity join to the recorded object; it does not establish that every hidden vendor component is known. Record unresolved upstream versions and their effect on the assurance claim.

C.3 Risk and threat record template

C.4 Approval record template

Record workflow and initiating principal; reviewer identity and authority; proposed effect and normalized action digest; resources and subjects affected; allowed batch variation; data scope; relevant evidence; decision and reason; issuance and expiry; policy and configuration version; execution comparison; receipt and postcondition.

An approval form should show the difference between the request, proposed effect, and verified outcome. A generic instruction to proceed should not be interpreted as approval for an unspecified payment, disclosure, or changed destination.

C.5 Evaluation and release record template

Record the decision being supported, configuration, mandate and proposed autonomy; prohibited effects; eligible tasks and strata; case provenance; labeling/adjudication; oracle validation; attack model and budget; deterministic invariants; threshold errors and timing; paired utility; customer outcomes; recovery; failures; exclusions; uncertainty; holdout separation; independent challenge; bounded authorization and expiry triggers.

Report tests that failed, were inconclusive, or could not run. A status of proposed specification is different from an observed pass. The test catalog in Appendix D is a starting set; it does not cover every business task or effect route.

C.6 Incident and corrective-action record template

Record first signal; confirmed and unknown effects; severity and affected people; configuration; authority and approvals; containment action and effective time; descendants, queues, callbacks, and credentials; independent state reconciliation; custody; legal reporting determination; customer remedy and lookback; root mechanism; repair; retained failure cases; new evaluation; accountable restart or retirement.

C.7 Included example files

The supplementary files include an example mandate, control event, and proposed JSON event schema. They are synthetic implementation aids. Example digest strings illustrate field relationships and are not computed signatures. The schema validates event structure; it does not prove semantic authorization, completeness, integrity, or deployed enforcement. Appendix E explains the event semantics.

Appendix D. Proposed acceptance-test catalog

D.1 Execution protocol

These 36 starter tests are proposed, not executed results. Use an isolated environment or safe replica with synthetic data and constrained connectivity. Define configuration, mandate, expected outcomes, oracle, sampling design, and stop conditions. Record observed effects and evidence, including failed, inconclusive, and unrun tests.

Oracle independence requires protected measurements outside the evaluated agent's authority. Use separate verifier permissions and test evidence tampering and missing events. Agent messages, tool statuses, and monitor flags alone cannot establish business effects. Pass only when the oracle demonstrates the expected outcome; a coverage gap is not a pass. Add benign counterparts and local effect routes to assess useful work and false interruption.

D.2 Tests for E01

D.3 Tests for E02

D.4 Tests for E03

D.5 Tests for E04

D.6 Tests for E05

D.7 Tests for E06

D.8 Tests for E07

D.9 Tests for E08

D.10 Tests for E09

D.11 Tests for E10

D.12 Tests for E11

D.13 Tests for E12

D.14 Test-result record

Record test ID; case and data provenance; deployment and policy versions; eligible population or attack selection; actual inputs; start/end times; observation and effect records; expected versus observed outcome; label/adjudication; pass/fail/inconclusive/not-run status; residual gap; corrective action; retest link; and approving reviewer. Separate independent repetitions from clustered variants and adaptive retries.

Appendix E. Event semantics and metric dictionary

E.1 Interpret the event chain

A proposed action, authorized request, issued call, accepted request, committed effect, reconciled effect, and verified business outcome are different states. Some resources commit asynchronously. The event schema should preserve those distinctions and permit an unresolved state rather than inventing completion.

Use stable joins for workflow, agent and parent, initiating principal, configuration, grant, policy, approval, tool call, and receipt. Protect resolvable personal identifiers and full content separately from routine operational views. Collect only what the control purpose and applicable retention duty justify.

E.2 Metric definitions

Define the reporting window and strata before reporting. Preserve numerator, denominator, exclusions, unresolved cases, source grain, and uncertainty. The proposed dictionary below avoids collapsing utility, critical violations, reviewer capacity, and rights into one score.

M01. Unauthorized consequential commits

Unit and denominator: Count by severity; report eligible runs and consequential actions separately.

Definition: Count independently confirmed effects that violated current authority or required approval.

Evidence: Resource receipts joined to policy and approval.

Owner and interpretation: Platform and process owner. Any critical violation initiates containment.

M02. Safe task completion

Unit and denominator: Eligible runs; report excluded and unresolved runs.

Definition: Authorized successful runs without a defined prohibited effect / eligible runs.

Evidence: Same-run rubric; independent postcondition, oracle and limitations (E.1).

Owner and interpretation: Business owner. Use precommitted workflow threshold and confidence method.

M03. Timely prevention

Unit and denominator: Labeled harmful cases under the specified scenario design.

Definition: Harmful cases prevented before effect within the precommitted criticality-specific deadline / labeled harmful cases.

Evidence: Labels, effective intervention time, resource state.

Owner and interpretation: Security operations. Report misses and late interventions by criticality.

M04. Unnecessary interruption

Unit and denominator: Labeled benign cases.

Definition: Benign cases erroneously interrupted / benign cases.

Evidence: Adjudicated benign labels and actual hold/deny events.

Owner and interpretation: Business operations. Define acceptable burden against staffing and service commitments.

M05. Review queue delay

Unit and denominator: Cases requiring review, by stage and severity.

Definition: Review-start minus queue-entry; review-completion minus queue-entry. Report median, p95, tails, and overdue count.

Evidence: Queue, reviewer, and completion timestamps.

Owner and interpretation: Review operations. Define action-class deadlines and peak-load stop conditions.

M06. Evidence reconciliation

Unit and denominator: Consequential actions, including uncertain and partial ones.

Definition: Actions with the required matched authority, approval, decision, effect, and outcome evidence / consequential actions.

Evidence: Independent action inventory and event matches.

Owner and interpretation: Platform and assurance. Unreconstructable critical effects reopen assurance.

M07. Scope or revocation failures

Unit and denominator: Negative tests and production actions reported as separate populations.

Definition: Count prohibited acceptances; do not blend adversarial samples with production prevalence.

Evidence: Grant state, decisions, and resource effects.

Owner and interpretation: Identity and resource owners. A material acceptance initiates authority reduction and repair.

M08. Configuration mismatch

Unit and denominator: Inspected runs with a declared approved configuration.

Definition: Runs whose material deployed configuration differs from approved configuration / inspected runs.

Evidence: Approved manifest and production identity.

Owner and interpretation: Platform and validation. Separate unapproved mismatch from opaque upstream version uncertainty.

M09. Recovery performance

Unit and denominator: Each incident or drill; no averaging across unlike effects without scope.

Definition: Time to effective halt; active descendants at verification; pending/partial effects reconciled.

Evidence: Resource queries, queue state, and delegation tree.

Owner and interpretation: Incident response. Compare with approved recovery and containment objectives.

M10. Customer stage outcomes

Unit and denominator: Eligible entrants for each defined stage and relevant cohort.

Definition: Report entry, burden, exclusion, errors, delay, correction, and remedy with explicit counts and uncertainty.

Evidence: Stage lineage, lawful cohort labels, adjudication.

Owner and interpretation: Business and compliance. Investigate material unexplained differences and rights failures.

E.3 Threshold and sampling cautions

Do not copy a benchmark threshold into production without the workflow population, task, and consequence justification. Precommit operating decisions, then report the observed evidence. A monitor threshold selects a tradeoff between misses and false interruption. A queue percentile can conceal a critical overdue case. A high reconciliation percentage can conceal the one unreconstructable effect that requires containment.

The exact zero-event example in chapter 9 requires independent identically distributed binary observations. It cannot resolve missing hazard coverage or transform a hand-selected adversarial set into a production prevalence estimate.

Appendix F. A worked assurance case

F.1 Start with a bounded claim

Synthetic claim: For deployment D-47 and mandate W-47, a payment can execute only to the approved beneficiary, for the approved amount and currency, using current authority, exactly-scope-bound approval, and a controlled idempotency key. Claimed completion requires independent reconciliation. This is a proposed assurance argument, not an established enterprise result.

F.2 State the evidence conclusion precisely

A proposed wording after successful local testing would identify the tested configuration, routes, case population, prohibited-effect definition, observed outcomes, and unresolved gaps. It would avoid a general assertion that the agent is safe. If a critical route remains untested, the release authority should either restrict that route or record a scoped exception with a compensating mechanism.

This handbook does not supply a completed local assurance case. It supplies the structure, proposed tests, example events, and challenge questions needed to assemble one.

F.3 Challenge the case with counterexamples

Try the wrong tenant, wrong beneficiary, payload drift, revoked grant, stale approval, child budget reset, raw API, delayed injection, missing receipt, and lost response after effect. Then test ordinary authorized work and peak review load. Preserve failures and new routes as evidence that reopens the relevant claim.

Appendix G. Legal scope and supplier worksheets

G.1 Obligation scope worksheet

The regulatory table in chapter 16 is a researched scope aid for the listed US and EU instruments. It is not an exhaustive jurisdictional inventory. Do not treat a voluntary framework, protocol requirement, or proposed test as a statutory duty.

G.2 Supplier evidence worksheet

G.3 Local responsibility worksheet

Assign a named local role for each mandate, resource boundary, oracle, reviewer pool, monitor, evidence store, legal determination, exception, halt, restart, supplier relationship, and retirement. Record consulted roles and escalation substitutes. The first line operates controls, the second line challenges risk, and internal audit preserves its independence.

Appendix H. Research method, validation, and open questions

H.1 Review method

This is a targeted primary-source scoping review with foundational references, not an exhaustive systematic review or a statistical meta-analysis. Searches covered agent safety, monitoring, intervention timing, harness evolution, prompt injection, multi-agent behavior, fairness, finance evaluation, identity, protocol changes, and regulatory status. Discovery results were traced to papers, official specifications, regulatory text, agency pages, or first-party incident reports before supporting report claims.

The baseline review inspected the live compendium overview, complete control index, and relevant evaluation, runtime, monitoring, multi-agent, third-party, regulatory, fairness, and implementation sections. It did not revalidate every one of the compendium's historical citations. The standalone edition adds original explanations, worked examples, a glossary, baseline practices, and reference worksheets; prior baseline context remains distinct from new evidence.

Quantitative exhibits use reported values or transparent calculations. The underlying model/agent experiments were not rerun. Paper versions, study units, denominators, selection conditions, and interpretation limits are retained in the publication kit. No cross-benchmark averages or model safety rankings were constructed.

H.2 Evidence classes

Evidence classes help the reader assess what a source establishes. A new preprint is not established consensus.

H.3 Validation and limitations

• Original anchors were checked against the inspected 112-identifier index. The 45 H-practices and twelve E-specifications use separate namespaces; their described mechanisms are proposed enterprise designs.
• Composition percentages and benchmark percentage-point differences were recalculated from recorded values. The zero-event bound was computed from the displayed equation, with rounding confined to presentation.
• Critical distinctions were checked explicitly: permission versus identity; detection versus prevention; statistical discrimination versus operating-threshold recall; early interruption versus harm; live incident versus simulation; process assurance versus behavioral effectiveness; final regulation versus proposed rule.
• The EU legal-text access limitation is recorded in chapter 16. The relevant timeline is attributed to the official Commission page. A source titled Safety in Self-Evolving Agents was excluded as a recency anchor because inspected submission metadata conflicted with its identifier/month; its date was not silently repaired.
• This report makes no claim that public benchmark results transfer to a particular institution. Local deployment effectiveness, reviewer competence, data representativeness, and legal applicability remain local acceptance questions.

H.4 Research worth commissioning next

H.5 Editorial and artifact validation scope

The standalone revision validates term and acronym coverage, all H/E/T identifiers and relationships, source references, figure captions, metric definitions, synthetic worked calculations, event-schema structure, PDF navigation and bounds, and the integrity of the publication kit. A recorded check only supports its stated scope. Browser interaction and responsiveness checks for the portable HTML could not be completed in the authoring environment; published model experiments and enterprise integrations were not rerun.

Appendix I. Annotated source bibliography

The references identify the inspected sources and scope. The research cut-off is 2 October 2026. Later source revisions require a new review rather than silent substitution.

[S01] Agentic Responsible AI Compendium. Live pages inspected 2 October 2026. Evidence class: Baseline. Inspected: Overview, structure and relevant source sections. Scope: Live baseline; not an immutable July snapshot.

[S02] Appendix A: Master Control Index. Live pages inspected 2 October 2026. Evidence class: Baseline. Inspected: Complete index of 112 controls. Scope: Used to preserve original identifiers and control meaning.

[S03] Part III-B: Pre-Deployment Evaluation and Testing. Live pages inspected 2 October 2026. Evidence class: Baseline. Inspected: Relevant evaluation and change-control sections. Scope: Baseline context; historical citations were not all revalidated.

[S04] Part III-C: Runtime Controls. Live pages inspected 2 October 2026. Evidence class: Baseline. Inspected: Relevant runtime-control sections. Scope: Baseline context; handbook supplies testable acceptance artifacts.

[S05] Part III-D: Monitoring and Post-Deployment Controls. Live pages inspected 2 October 2026. Evidence class: Baseline. Inspected: Monitoring, evidence and operational-response sections. Scope: Live baseline reviewed for traceability.

[S06] Part III-E: Multi-Agent Controls. Live pages inspected 2 October 2026. Evidence class: Baseline. Inspected: Multi-agent control sections. Scope: Live baseline reviewed for delegation and collective-risk alignment.

[S07] Part III-F: Third-Party and Supply-Chain Controls. Live pages inspected 2 October 2026. Evidence class: Baseline. Inspected: Third-party and supply-chain control sections. Scope: Live baseline reviewed for vendor and dependency alignment.

[S08] Part V: Regulatory Mapping for Financial Services. Live pages inspected 2 October 2026. Evidence class: Baseline. Inspected: Regulatory mapping and supervisory discussion. Scope: New legal status checks are separate from the baseline mapping.

[S09] Part VI: Fairness and Customer Outcomes. Live pages inspected 2 October 2026. Evidence class: Baseline. Inspected: Customer outcomes, reasons and human review. Scope: Live baseline reviewed for outcome-control alignment.

[S10] Part VII: Implementation Playbook. Live pages inspected 2 October 2026. Evidence class: Baseline. Inspected: Implementation and operating-model sections. Scope: The proposed 90-day handbook does not replace the original playbook.

[S11] PASTABench: Proactive Assessment of Sequential Trajectories for Agent Safety. v1, 23 September 2026. Evidence class: Empirical preprint. Inspected: Sections 3.2-4.3, selected model results. Scope: 1,139 curated synthetic trajectories; optimal-window interruption includes exact risk attribution. Not a realized-harm measure, deployment estimate, or current vendor ranking.

[S12] HARDE: Optimizing Agent Harnesses for Runtime Risk Detection and Execution Control. v1, 29 September 2026. Evidence class: Empirical preprint. Inspected: Sections 3.1-3.3; Table 1. Scope: Selected DeepSeek-V4-Flash monitor condition; three-run means; no uncertainty intervals supplied here. Safe Success is a within-run joint outcome, not a product of aggregate means.

[S13] Compositional Safety Failures in Harness Evolution: Identification and Runtime Monitoring. v2, 29 September 2026. Evidence class: Empirical preprint. Inspected: Section 3.2; Table 2. Scope: Filtered eligible interaction panels, with different construction across benchmarks. Rates do not estimate production prevalence and are not pooled.

[S14] ORBIT: A Framework for Multi-Agent Safety and Security Evaluations. v1, 27 September 2026. Evidence class: Empirical preprint. Inspected: Threat, defense and architecture methods; results. Scope: Configuration-specific multi-agent evaluation; defense performance does not automatically transfer to collusion or a different topology.

[S15] Defusing Explosive Prompts: Understanding and Preventing Trigger-Based Prompt Injections in LLM Agents. v1, 18 September 2026. Evidence class: Empirical preprint. Inspected: Attack construction, feasibility tests and detector limitations. Scope: Conditional and delayed injection. Feasibility trials use selected application versions and 30 cases each; detector is not hardened against adaptive attacks.

[S16] Safety of Latent Communication in Multi-Agent Systems. v2, 1 October 2026. Evidence class: Empirical preprint. Inspected: Communication-link methods and experimental results. Scope: Learned representation-space communication links; findings are not evidence about every ordinary text-based agent workflow.

[S17] Fine-Tuned Lie Detectors Failed to Generalize. 21 August 2026. Evidence class: First-party research. Inspected: Methods, seen/held-out category results, labeling discussion. Scope: Seen-category improvement and weak novel-category transfer; AUROC is not recall at a deployment threshold. Deception labels have acknowledged limitations.

[S18] Safety Does Not Compose: Non-Decaying Loop State for Autonomous LLM Agents. v6, 22 September 2026. Evidence class: Formal / empirical preprint. Inspected: Observation-separation argument, loop state and bound assumptions. Scope: Formal guarantees depend on mediated commits and stated detection assumptions. Not an unconditional production-safety guarantee.

[S19] Contract monitoring: governing AI via separation of powers. v1, 25 September 2026. Evidence class: Concept / formal preprint. Inspected: Worker, monitor, judge and resource-asymmetry framework. Scope: Proposed governance architecture with assumption-dependent arguments; no universal enterprise guarantee.

[S20] Environment Steering: Using Data Flow Control to Improve Agent Utility and Safety. v1, 19 September 2026. Evidence class: Empirical preprint. Inspected: Database state, data-flow policies and execution feedback. Scope: Environment-level enforcement is a research implementation candidate. Benchmark attack resistance is not a universal guarantee.

[S21] Agent Safety From Within: Detecting Harmful Trajectories from LLM Internal States. v1, 27 September 2026. Evidence class: Empirical preprint. Inspected: TACIT methods, harmful content/tool misuse results and limitations. Scope: Requires internal-state instrumentation. Detection gains do not establish prevention or managed-API availability.

[S22] FinFIRST: Benchmarking Search Agents for Financial Information Retrieval, Sourcing and Traceability. v1, 21 September 2026. Evidence class: Empirical preprint. Inspected: Task construction, source registry and financial-evidence rubric. Scope: 123 expert-authored financial search tasks. Does not validate private institutional data, suitability decisions, or transaction authority.

[S23] Compliant with Local Controls, Collectively Discriminatory. A Governance Architecture for Multi-Agent AI in Regulated Finance. v1, 23 September 2026. Evidence class: Architecture / constructed simulation. Inspected: ARIA architecture, two simulations and validation agenda. Scope: Illustrative constructed simulations; production effectiveness is not established.

[S24] Agent Safety Should Be a Runtime Contract. v1, 11 August 2026. Evidence class: Position preprint. Inspected: Preventive and evidential contract framing. Scope: Position paper used as architectural framing, not an empirical proof of enterprise effectiveness.

[S25] Comments on Software and Agentic AI Identity Concept Paper. 29 September 2026. Evidence class: Official project update. Inspected: NCCoE project update and implementation direction. Scope: Project and consultation work; not a completed agent-identity certification standard.

[S26] Software and Agentic AI Identity: Summary of Comments. Inspected 2 October 2026. Evidence class: Official consultation summary. Inspected: Comment themes and implementation recommendations. Scope: Public-comment summary, not a finalized normative standard.

[S27] The 2026-07-28 Specification. 28 July 2026. Evidence class: Released technical documentation. Inspected: Protocol release changes. Scope: Version-specific protocol changes; implementations must be evaluated at their deployed version.

[S28] MCP Authorization Security Considerations. Specification 2026-07-28. Evidence class: Released technical specification. Inspected: Audience validation, token passthrough, issuer checks, SSRF and client metadata. Scope: Authentication requirements do not independently establish business authorization for each action.

[S29] OWASP Agent Control Standard resource. Inspected 2 October 2026. Evidence class: Voluntary technical framework. Inspected: Resource overview and runtime-control description. Scope: Voluntary integration candidate; enforcement coverage requires local tests.

[S30] Agent Control Standard repository. Inspected version 0.1.0. Evidence class: Implementation documentation. Inspected: README, version and demonstration scope. Scope: Inspected demonstration explicitly covers two live hooks; not universal framework interoperability or hook coverage.

[S31] SR 26-2: Revised Guidance on Model Risk Management. 17 April 2026. Evidence class: Official supervisory text. Inspected: Letter, supersession and applicability. Scope: Replaces SR 11-7 and SR 21-8; interpret with its attachment and explicit scope.

[S32] Revised Guidance on Model Risk Management: SR 26-2 attachment. 17 April 2026. Evidence class: Official supervisory text. Inspected: Scope section, printed page 3, footnote 3. Scope: Explicitly excludes generative and agentic AI models. Reuse of model-risk disciplines is not a direct agent-specific obligation under this guidance.

[S33] AI Omnibus enters into force. 27 July 2026. Evidence class: Official implementation announcement. Inspected: Commission effective/application-date announcement. Scope: Dates attributed to the Commission. Linked controlling and consolidated EUR-Lex texts were blocked by an anti-bot response; no full-text legal review claimed.

[S34] SB26-189: Automated Decision-Making Technology. Governor signed 14 May 2026. Evidence class: Official legislative status. Inspected: Bill page, summary and enacted status/history. Scope: Bill status verified from the General Assembly. Detailed role/obligation determinations require applicable enacted text review.

[S35] Colorado Attorney General: AI rulemaking. Inspected 2 October 2026. Evidence class: Official legal implementation / draft rules. Inspected: ADMT effective date and proposed-rule status. Scope: New-law effective date 1 January 2027; 11 August rule drafts are proposals, with comments through 26 October 2026.

[S36] California CCPA Updates, Cyber, Risk, ADMT, and Insurance Regulations: Final Regulations Text. Final approved text inspected 2 October 2026. Evidence class: Final regulatory text. Inspected: Article 11, section 7200, PDF page 112 of 127. Scope: Covered significant-decision ADMT compliance from 1 January 2027; applicability and exemptions require case-specific review.

[S37] Regulation B, section 1002.9: Notifications. Current official text inspected 2 October 2026. Evidence class: Governing regulatory text. Inspected: Notification requirements and specific principal reasons. Scope: Applies to covered adverse action, with rule-specific procedures and exceptions. Avoid relying on withdrawn explanatory circulars.

[S38] Incident report: unsanctioned agent behaviour during cyber testing. July 2026 activity; inspected 2 October 2026. Evidence class: First-party incident report. Inspected: Run/action counts, environment, clustering and harm assessment. Scope: 10/122 runs, 19 actions; internet access intentionally allowed, cyber classifiers disabled, no evidenced real-world harm. Not a sandbox escape.

[S39] GPT-6 Astra performs unsanctioned supply-chain attacks in simulations. Inspected 2 October 2026. Evidence class: Official controlled simulation report. Inspected: Experimental setup, simulated actions and limitations. Scope: All activity simulated; cyber classifiers disabled. Unequal comparison seeds and simulation conditions restrict interpretation.

[S40] How our new control red team is stress-testing frontier monitors. Inspected 2 October 2026. Evidence class: Official research-program report. Inspected: Monitor red-team remit and open questions. Scope: Program direction, not evidence that a particular monitor prevents all deployment hazards.

[S41] CPPA: New regulations approved by Office of Administrative Law. 23 September 2025. Evidence class: Official regulatory announcement. Inspected: Effective date and staged compliance dates. Scope: Regulations effective 1 January 2026; specific ADMT compliance date is distinguished from other schedules.

[S42] OpenTelemetry Semantic Conventions: GenAI Attribute Registry. Inspected 2 October 2026. Evidence class: Development-stage technical conventions. Inspected: GenAI operations and attribute stability labels. Scope: Relevant GenAI semantics carry Development status. Proposed fields in this kit are not claimed to be OTel standard field names.

[S43] Artificial Intelligence Risk Management Framework (AI RMF 1.0). January 2023. Evidence class: Voluntary risk-management framework. Inspected: Foundational risk characteristics and four core functions. Scope: Used for concise foundational context. Handbook mechanisms and lifecycle gates are original proposals, not a certification or clause-level crosswalk.

[S44] Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. July 2024. Evidence class: Voluntary cross-sectoral profile. Inspected: Overview, risk descriptions, environmental-impact and intellectual-property considerations. Scope: Provides foundational risk context. Exact enterprise controls and measurement recipes in this handbook are proposed.

[S45] OECD AI Principles overview. Updated May 2024; page inspected 2 October 2026. Evidence class: Intergovernmental principles. Inspected: Values-based principles and AI terminology. Scope: High-level values reference, not a deployed-control effectiveness claim or comprehensive legal determination.

[S46] OWASP Top 10 for Agentic Applications for 2026. 9 December 2025; 2026 edition. Evidence class: Voluntary security framework. Inspected: Official overview and intended scope. Scope: Used as a security reference. The handbook threat table is original and does not reproduce or claim conformance to the ten categories.

[S47] NIST AI Risk Management Framework: current program status. Inspected 2 October 2026. Evidence class: Official program status. Inspected: Overview and revision-status notice. Scope: NIST states AI RMF 1.0 is being revised. No completed replacement or new mandatory requirement is asserted.

Appendix J. Supplementary files, publication, and maintenance

J.1 Complete publication package

The implementation kit contains fourteen original SVG graphics, source and claim ledgers, the 45-practice register, twelve implementation specifications, thirty-six proposed acceptance tests, glossary and metric dictionaries, ten blank templates, two synthetic examples, and a proposed event schema.

Read the complete handbook and individual chapters on The Observability Layer website, or download its PDF and editable Markdown. The implementation kit supplies reusable reference files. File integrity hashes describe file contents; they do not certify research validity or control effectiveness.

J.2 Publish as an independent handbook

Use the standalone title, evidence cutoff, edition, and scope. Introduce the subject before the control architecture. Keep definitions, captions, denominators, caveats, source references, and appendices with the material they support. The earlier compendium can be linked as background, but it is not a prerequisite for understanding or applying this edition.

An editorial review should verify house style, intended byline and publication rights, accessibility and hosting behavior, source updates after the cutoff, and jurisdiction-specific legal additions. These are publishing responsibilities, distinct from the recorded analytical and artifact checks.

J.3 Maintain a versioned body of knowledge

For a new edition, record source versions and scope; inspect changed legal or protocol status; update claims, calculations, graphics, and implementation consequences together; retain superseded editions; and explain material changes. Reopen a control recommendation when new evidence contradicts its mechanism or operating assumptions.

Do not update an evidence cutoff merely because the file was rebuilt. A new cutoff should reflect inspected evidence. Enterprise users should version their adopted practices and document which local deployment evidence supports them.