FUURAA AI Knowledge Library · Operating-period protocol

Post-deployment monitoring and change control for AI agents

A bilingual protocol that carries a deployment decision into real operations: keep system identity, authority and use boundaries attached; observe outcomes and action paths; detect drift; control changes; and preserve reviewable evidence for containment, rollback and re-evaluation.

Enter the eight operating gates ↓View the minimum signal set

Published4 August 2026Evidence statusFUURAA method synthesis grounded in primary risk, incident-response and secure-development sourcesScopeAI agents with tools or external actions in bounded or production operation

Core principle

Deployment approval is not a permanent conclusion; it is a versioned, scoped and expiring operating hypothesis.

Pre-deployment evaluation describes a frozen system under tested conditions. Operating evidence must show whether real users, tasks, dependency changes and external actions remain inside that decision boundary.

Applicability boundaryThis is a public monitoring and change-control method—not a continuous-monitoring product, safety certification, audit opinion, legal or compliance conclusion. It does not replace sector-specific incident-reporting, privacy, cybersecurity or product-safety duties.

Freeze the four-part operating identity first

Telemetry that cannot identify a version cannot support a versioned decision.

01
acting system
Agent, model, prompts, orchestration, tool schemas and configuration hashes.
02
authority envelope
Permitted actions, credentials, budgets, approvals, exclusions and revocation path.
03
operating context
Users, workflows, data classes, geography, language, environment and dependency versions.
04
decision basis
Evaluation record, accepted limitations, release owner, status and expiry.

Minimum operating signal set

Do not monitor availability alone; monitor why the decision could become invalid.

Slice signals by task class, user cohort, language, environment and version. Aggregate averages must not hide critical failures, authority breaches or degradation in smaller groups.

Signal family	Minimum observation
outcome	Success, partial completion, silent failure and critical-failure rate by task class.
action path	Tool calls, denied actions, retries, approval requests, state changes and side effects.
human control	Interventions, overrides, escalations, abandonment, takeover time and operator workload.
boundary pressure	Requests outside scope, policy conflicts, permission expansion and novel workflows.
quality drift	Changes against frozen baselines across task mix, users, languages and environments.
operational load	Latency, cost, queueing, tool errors, dependency health and resource saturation.
security and misuse	Prompt injection signals, credential misuse, anomalous access and unsafe tool sequences.
change provenance	Who changed what, when, why, review evidence, rollout cohort and rollback point.

Eight operating gates

Every gate connects a question, evidence and a stopping condition.

Freeze the monitored deployment

Core question: Can every observation be tied to one exact acting system, authority envelope and release decision?
Evidence to preserve: System and dependency hashes, tool contracts, permissions, environment, cohort, decision record and expiry.
Stopping condition: Do not aggregate results across versions that cannot be reconstructed or separated.

Declare signals, baselines and thresholds

Core question: Which observable change would alter the deployment decision, and over what window?
Evidence to preserve: Metric definitions, denominators, slices, confidence or uncertainty, alert windows and decision thresholds.
Stopping condition: Block monitoring plans that collect convenient telemetry without a linked decision or owner.

Preserve outcome and action evidence

Core question: Can reviewers reconstruct what the agent observed, decided, attempted and changed without retaining unnecessary sensitive data?
Evidence to preserve: Privacy-minimised traces, tool requests and responses, approvals, side effects, task outcomes, clocks and integrity metadata.
Stopping condition: Stop if critical actions are untraceable, timestamps are incomparable or evidence retention exceeds its stated purpose.

Detect drift and boundary violations

Core question: Is the system, task distribution or environment moving beyond what the evaluation supported?
Evidence to preserve: Baseline comparisons by task class and cohort, new-use inventory, excluded-use hits, failure clusters and residual unknowns.
Stopping condition: Suspend the affected slice when a critical failure, authority breach or unsupported use appears.

Control every material change

Core question: What evidence is required before a model, prompt, tool, permission, memory, policy or dependency change reaches users?
Evidence to preserve: Change class, rationale, diff, owner, targeted regression set, approval, canary cohort and rollback artifact.
Stopping condition: Do not ship an unclassified change or silently inherit a provider update into a bounded release.

Contain and investigate incidents

Core question: Can the team rapidly limit authority, preserve evidence and distinguish model, tool, data, operator and environment causes?
Evidence to preserve: Detection source, severity, affected scope, containment actions, evidence custody, hypotheses, decisions and communications.
Stopping condition: Revoke or pause authority when harm can continue, evidence is being overwritten or ownership is unclear.

Recover, verify and reopen deliberately

Core question: Does rollback or repair restore the defined boundary, and has the failure been tested rather than narrated away?
Evidence to preserve: Known-good version, restoration checks, targeted reproduction, regression results, phased reopening and residual-risk acceptance.
Stopping condition: Do not reopen on the basis of a patch alone; require observed evidence under the affected conditions.

Expire and re-evaluate the decision

Core question: What passage of time, accumulated evidence or contextual change invalidates the current operating decision?
Evidence to preserve: Expiry, review cadence, rerun triggers, unresolved deviations, trend summary, decision owner and replacement record.
Stopping condition: Treat an expired or orphaned decision as invalid, not as continuing approval.

Change classification

Required evidence depends on which boundary the change alters.

Class	Minimum control
routine	No authority or task-boundary change; run targeted regression and preserve the diff.
material	Changes model behaviour, tools, memory, prompts, data, policy or dependencies; rerun affected gates and canary.
boundary-changing	Expands users, tasks, geography, language, permissions or consequences; require a new deployment decision.
emergency	Containment or security repair under active risk; restrict first, document, verify and time-limit the exception.

Operating states

The state describes current evidence without laundering uncertainty.

within boundary

Evidence remains inside declared thresholds, scope and expiry.

restricted

A defined slice, tool or authority is constrained while evidence is gathered.

paused

Affected actions stop while containment, investigation or regression proceeds.

invalidated

The operating decision expired or its evidence no longer covers the system or context.

FUURAA analysisThe central post-deployment risk is not only declining model quality. The acting system may quietly become a different system: a provider updates a model, a tool changes its response contract, authority expands, the task mix shifts or operators form new dependencies. High-quality monitoring ties those changes back to the evaluation and deployment decision; otherwise teams accumulate telemetry without being able to decide whether operation should continue.

Minimum operating-period record

Fourteen fields turn signals into an accountable decision.

01deployment identity
Record an inspectable identifier, definition, value, evidence path, time or owner.
02decision and expiry
Record an inspectable identifier, definition, value, evidence path, time or owner.
03authority envelope
Record an inspectable identifier, definition, value, evidence path, time or owner.
04cohort and task mix
Record an inspectable identifier, definition, value, evidence path, time or owner.
05signal definition
Record an inspectable identifier, definition, value, evidence path, time or owner.
06baseline and threshold
Record an inspectable identifier, definition, value, evidence path, time or owner.
07observation window
Record an inspectable identifier, definition, value, evidence path, time or owner.
08outcome and action evidence
Record an inspectable identifier, definition, value, evidence path, time or owner.
09change history
Record an inspectable identifier, definition, value, evidence path, time or owner.
10deviations and incidents
Record an inspectable identifier, definition, value, evidence path, time or owner.
11containment or rollback
Record an inspectable identifier, definition, value, evidence path, time or owner.
12human interventions
Record an inspectable identifier, definition, value, evidence path, time or owner.
13residual unknowns
Record an inspectable identifier, definition, value, evidence path, time or owner.
14owner and next review
Record an inspectable identifier, definition, value, evidence path, time or owner.

Primary sources and evidence boundaries

Use frameworks to design controls—not to impersonate operating proof.

Sources checked 4 August 2026. Each record preserves publication date, methodological role and non-transfer boundary.

Published 26 January 2023NIST · AI RMF 1.0

Provides lifecycle-wide Govern, Map, Measure and Manage outcomes for voluntary AI risk management.

BoundaryUse-case agnostic and voluntary; it does not supply agent-specific thresholds or certify a deployment.

Open primary source ↗Published 26 July 2024 · source page updated 8 April 2026NIST · AI 600-1 Generative AI Profile

Adds generative-AI risk actions, including monitoring, incident disclosure, content provenance and third-party considerations.

BoundaryA cross-sector profile, not a complete control set for every agent, tool or regulated use.

Open primary source ↗Companion to AI RMF 1.0 · current page checked 4 August 2026NIST · AI RMF Playbook

Offers suggested actions and documentation practices for operationalising the framework.

BoundaryNIST states the suggestions are not a universal checklist; teams must select actions for their context.

Open primary source ↗Final 3 April 2025NIST · SP 800-61 Rev. 3

Frames preparation, detection, response and recovery as integrated cybersecurity risk management.

BoundaryIt addresses cybersecurity incidents broadly; this page adapts—not equates—those practices to AI-agent operating evidence.

Open primary source ↗Published 27 November 2023UK NCSC · Secure operation and maintenance

Provides operating guidance for behaviour and input monitoring, secure updates and lessons learned.

BoundaryHigh-level secure-development guidance; it does not validate any particular monitoring stack or agent release.

Open primary source ↗

Connect the evidence chain

Move from pre-deployment evaluation into operating evidence, incident response and renewed decisions.

Build an Agent operating-period record Evaluate an AI agent before deployment Build an Agent evaluation run record Verify an Agent evaluation record Conduct human review and conclusion Enter AI Evidence Atlas Return to AI Knowledge Library