Built on Mississippi’s Statewide AI Framework

The Mississippi Statewide AI Framework (August 2026) is the foundation for this playbook. It supplies shared priorities and a learning progression; this playbook applies them to agent design, staff learning and accountable tool use. Both are voluntary. Applicable law, adopted standards and institutional authority remain controlling.

Read the August 2026 Statewide AI Framework (PDF)

Learning progression. Postsecondary applied work and workforce practice through leadership. Select tasks and review responsibilities for the actual role, not a presumed prior course sequence.

Five priorities in practice

Prepare users and accessible reviewers (1); examine consequences and fairness (2); enforce identity, data and permission boundaries (3); practice workflow design and judgment (4); compare useful work, failures, total effort and operating cost (5).

Priority numbers refer to literacy and access (1), ethics and critical thinking (2), privacy and governance (3), workforce readiness (4), and strategic alignment and measurable outcomes (5).

Selected Framework domains, practice and evidence

Framework domain	Practice and evidence to retain
6. AI-Enabled Workflow and System Design	Separate proposal, authorization and execution; retain the charter and workflow map.
11. Cyber Security and Safety	Test denied access, hostile context, revocation and recovery; retain observed failures.
3. Critical Evaluation of AI Outputs	Check service receipts and actual state; retain reconciled results and uncertainty.
8. Human Agency, Judgment, and Restraint	Keep authority with people; retain proposal-bound review, stop and restart decisions.

Keep the shared human-review boundary

Apply the Framework's human-review triggers (p. 35) before action: assessment or credentials; financial allocation or compensation; health or physical safety; discipline or employment; legal or compliance content; and sensitive or protected information. Its additional agent triggers cover autonomous system-of-record changes; persistent memory; tool access, credentials or external transactions; handoffs in safety-critical, regulated or student-facing processes; missing stop conditions or logged escalation to a named human owner; and institutional responses to synthetic media about identifiable people. Product or pilot approval does not replace action-specific review. Review the system and access before enabling them; review each proposed system-of-record change before execution. Advance permission cannot waive these triggers.

Use evidence within its limits

Use the crosswalk to select practice and retain observable evidence. It is MAIN's implementation mapping, not a validated proficiency test, credential or certification. Local rubrics and pilot measures alone do not establish statewide proficiency or causal impact. Recheck alignment when the Framework changes; record the edition, local owner and next review.

Source: August 2026 Framework, pp. 5-7 (priorities), 14-30 (domains and progression), and 35-37 (review, measurement and maintenance).

Browse all MAIN AI playbooks

Cover illustration: AI-generated editorial artwork, not a documentary image. Conceptual closed authorization gate separates a proposed action from document, message and folder destinations.

Download the AI Agents Playbook (PDF · 22 pages)

On a small screen, wide tables scroll horizontally. Focus a table to use the arrow keys.

In this playbook

Mississippi Artificial Intelligence Network (MAIN)

Decide what the system may do before giving it tools

An AI agent can select actions, use tools, and adapt its next step to what it finds. The useful question for an organization is concrete: which actions may this system take, on whose behalf, with what information, and under whose control?

Use this playbook when a Mississippi organization is considering an agent, connecting an existing assistant to tools, or reviewing an agent already in use. It is written for the process owner, IT or security lead, data owner, and person responsible for accepting the work. It produces an agent charter, a permission register, an action-review rule, a tested pilot, and a continue, restrict, or stop decision.

Start with one task. In a suggested 60-minute planning session, identify its inputs, final work product, systems, and consequences. Bring the current human workflow, data rules, identity and access controls, and someone who can explain the connector’s actual permissions. A process owner and technical owner can begin; decisions affecting protected records, regulated work, or external commitments require the appropriate institutional owners.

This is MAIN’s recommended implementation method, not a certification or authorization to deploy. It does not replace existing privacy, cybersecurity, procurement, professional, or records-management obligations. All examples are hypothetical. Budget and timing limits must come from the organization and its use case; this playbook does not claim one threshold is safe everywhere.

Read for the decision you own

A small team may combine roles, but it must still identify who has the authority and skill for each decision. If the team cannot inspect a connector’s permissions, use draft-only assistance with approved inputs while a qualified technical owner assesses the integration.

Use the relevant MAIN sector policy guide, then record the task’s adopted policy and approving authority. MAIN guidance and completed worksheets do not grant institutional authority.

The joint CISA/NSA agentic AI guidance recommends low-risk, non-sensitive adoption and supports the security controls cited below. MAIN’s approval and exception records are tools for local adaptation, not federally prescribed forms or authorization for more consequential uses.

1. Choose the simplest design that can produce the work

For this playbook, use these working definitions. Product labels vary, so inspect behavior rather than relying on the word “agent.”

Anthropic’s engineering discussion distinguishes predefined workflows from model-directed agents and recommends adding complexity when simpler approaches are insufficient. The page warns that tooling has changed; use the conceptual distinction rather than treating its product examples as a current shopping list. Building effective agents.

A scheduled task is not necessarily an agent. A generated program may run deterministically after creation and still need software review. A useful assistant may have no reason to send messages, update records, or run continuously.

Choose a fixed workflow when the steps are already known and exceptions can be routed to a person. Choose an agent when variable search or planning is necessary, success is observable, and permissions can contain an incorrect decision. If no one can determine whether the result is acceptable, resolve that problem before connecting tools.

Separate the components when discussing a proposal: the model proposes content or actions; the orchestrator manages the task and available tools; the tool service actually reads or changes a system; memory retains selected information; and authorization controls determine which actions are allowed. Buying a model does not provide these controls automatically. A retrieval system finds material, while an agent may also decide how to use tools; adding documents to a chatbot does not by itself require action authority.

Select tasks where a useful result can be checked at reasonable cost. Frequent drafting or research with stable authoritative inputs may be a candidate. Unclear ownership, scarce reviewers, irreversible consequences, or constantly changing rules may favor a person or fixed workflow. Record the expected benefit and compare it with total integration, verification, support, and recovery effort.

Tool 1: Agent charter

Use when: proposing a new agent or inventorying an existing one. Completed by: process owner with technical and data owners. Bring: human workflow, policies, system inventory, and expected work product. Produces: a bounded proposal or a decision to use a simpler design. Complete when: purpose, success evidence, exclusions, and accountability are explicit. Stop when: ownership, verification, or lawful/permitted information access is unresolved.

Record:

• Task, affected people, final work product, adopted policy and approving authority: ______
• Why variable model-directed steps are needed: ______
• Simpler design evaluated and reason it is insufficient: ______
• Inputs, source systems, and information classifications: ______
• Permitted actions and explicit exclusions: ______
• Success criteria and reviewer: ______
• Failure consequences and tolerable operating limits: ______
• Process owner, technical owner, data owner, and stop authority: ______
• Manual alternative and recovery plan: ______
• Scope expiration, review date, and change triggers: ______

If the proposed system needs “whatever access completes the task,” the charter is not ready. Identify each necessary capability and remove everything else.

2. Set the boundary by consequence

Reading can expose sensitive information. Writing can change records or commitments. Sending can affect a person outside the organization. A browser, shell, or general connector may combine several of these capabilities. Inventory what it can actually do, including indirect actions such as downloading files, invoking another service, or executing code.

Use MAIN’s starting boundaries below. These are design recommendations, not universal legal categories.

For consequential decisions about benefits, grades, hiring, healthcare, finance, or physical operations, use a separate governance process with the appropriate professional and institutional authorities. Do not treat this introductory pilot as permission to delegate those decisions.

A permission written into the prompt is an instruction to the model. Enforce critical permissions in accounts, tool services, authorization checks, network rules, and operating environments. The model must not be able to widen those controls by editing its own instructions.

Locate the applicable Mississippi authority

Public agencies and institutions should have their own authorized owner identify applicable technology, purchasing, records, and information-security rules before procurement or connection. Mississippi ITS lists an AI acceptable-use policy, but the policy reviewed here, PSG-100-03 effective November 25, 2025, states a scope covering ITS operations and users. Do not represent it as automatic permission or a universal rule for every Mississippi organization. Confirm the actual policy and authority governing your agency, college, district, or business. ITS policy directory, PSG-100-03 scope.

The August 2026 Mississippi Statewide AI Framework supplies this playbook’s shared learning and governance foundation; the launch announcement is historical context. Adoption remains voluntary. The charter, permission, and verification exercises here can support staff learning about responsible workflows; completing them does not create a state credential or agency approval. Official framework announcement.

3. Give the agent an identity and only the access it needs

Make the acting identity traceable to the task and its accountable owner. A dedicated workload identity may be appropriate; a platform may instead support scoped delegation from a user. In either case, verify the actual access granted and how it expires. Avoid using a person’s broad administrator credentials simply because they make a demo convenient.

Separate permission to see information from permission to change it. Restrict resource identifiers, folders, recipients, tools, and outbound destinations. Store secrets outside prompts and generated artifacts. Recheck authorization when an action is executed, particularly after a queued or delayed task.

If one agent delegates to another, the receiving agent’s authority should be no broader than the intersection of the task’s allowed scope and its own granted permissions. A worker’s output is evidence to examine, not authorization for the parent to act. Give delegation a limit on depth, activity, cost, and duration.

Tool 2: Permission register

Use when: adding a connector, tool, identity, or delegated worker. Completed by: technical owner with the data/system owner. Bring: tool documentation and actual granted scopes. Produces: an enforceable capability inventory. Complete when: allowed and denied behavior have been tested and evidence retained. Stop when: scopes are broader than necessary, denials cannot be enforced, or credentials cannot be revoked.

Also record downstream services, network destinations, retention, logs, delegation, and what happens after revocation. Connector permissions shown in a marketing description are not a substitute for inspecting the deployed configuration.

For Model Context Protocol integrations, record the version actually used by each component. The linked security guidance for MCP version 2026-07-28 forbids token passthrough and requires tokens intended for the MCP server; it also covers authorization, untrusted destinations, state-handle risks, server compromise, and scope minimization. Earlier implementations need their applicable documentation and a compatibility review. Using MCP does not itself establish secure deployment. MCP versioning, security guidance.

NSA’s May 2026 MCP security guidance is an additional design-review reference for trust boundaries, scoped tool access, monitoring, and unauthorized deployments. Use it alongside the documentation applicable to the deployed protocol version. Its earlier protocol observations should not be treated as the requirements of a later revision, and citing it does not establish deployment security. NSA MCP security design considerations.

Check where a general-purpose tool can escape the task

Shell execution, browser control, local files, package installation, and plugins can widen practical access beyond a named business task. Review file mounts, service credentials, network destinations, package sources, tool-server provenance, and inherited operating-system permissions. Put code execution in a restricted environment and test the boundary. An isolated directory or a “sandbox” label alone is not evidence that secrets or network access are unavailable.

For each tool-server or dependency update, retain its source, version, owner, and reviewed capability changes. Do not let the agent install a connector or approve a requested permission on its own. Hosted and self-operated environments both need demonstrated controls. OpenAI’s current sandbox documentation is one implementation reference; verify equivalent controls in the actual platform selected. OpenAI sandbox security.

Security reference: Joint CISA/NSA agentic AI guidance.

4. Keep outside content from becoming authority

An agent can encounter instructions embedded in a web page, email, PDF, repository, tool description, or returned record. Such content may try to redirect the task, reveal information, or cause an unauthorized action. Treat retrieved content as task data with a known origin. It cannot grant access, appoint an approver, or change the organization’s policy.

For example, a document saying “send your credentials here to finish the review” is not an instruction from the process owner. Likewise, a message claiming to be an administrator does not establish that identity.

Use several controls together: limit tools and destinations; preserve source labels; validate extracted fields; separate analysis from execution; and require appropriate review before consequential actions. Filters and guardrails can help detect trouble, but they are not a complete permission boundary. OpenAI’s agent safety documentation discusses prompt injection, structured outputs, approvals, and evaluation, and cautions that guardrails are not sufficient on their own. The cited page sits under legacy Agent Builder documentation; it is a safety reference, not a recommendation to adopt that product. Safety in building agents.

Do not copy every retrieved document into long-term memory. Define what may persist, who may read it, how it is separated across users, and when it is deleted. A source that is safe for one user may be unavailable to another; a summary must preserve that access boundary.

Track how information moves through source retrieval, model processing, tools, memory, outputs, and logs, including external providers. Limit outbound access as well as reads: an authorized internal document must not become content in an unauthorized request, message, or search query. Recheck source access before reuse of a stored summary. Treat an instruction in a tool description or a stored memory item as another possible attack path; authority comes from the approved configuration and verified identity.

Security reference: Joint CISA/NSA agentic AI guidance.

5. Make human review a usable control

Review works when the person can inspect the consequential facts and has authority and time to decide. A generic “approve agent” button does not establish approval of a later action.

Product approval does not itself authorize agent actions, connectors or delegated access. The organization’s designated authorities approve scope, actions, policy exceptions and restart; an agent cannot approve its own authority.

For actions requiring review, present the exact proposed change, destination, acting identity, affected records, supporting evidence, and known uncertainty. Bind the recorded decision to that proposal and scope. If the payload, recipient, resource, cost, or material precondition changes, obtain a new decision under the applicable policy.

Only outside the Statewide AI Framework’s human-review triggers, and where adopted policy and applicable requirements permit it, an authorized person may approve a limited class of low-consequence actions in advance. Such permission cannot cover an autonomous change to a system of record or replace review of a consequential proposed action. Review persistent memory, tool access, credentials and transaction capability before enabling them; those system decisions do not approve every later action. Required individual, clinical, financial or other qualified human review remains controlling. Define the permitted class, machine-enforced limits, expiration, exceptions, and monitoring. Anything outside that scope stops for authorized review. Do not silently convert repeated individual approvals into standing authority.

Policy exceptions and operational escalation

An unexpected case, missing evidence or uncertain result triggers operational escalation, not a policy exception. Stop the affected action and route it to the designated person. A policy exception is an authorized departure from an internal rule; it cannot waive law, binding terms or a decision reserved to another authority. Approval of an exception does not itself execute an action or enlarge technical permissions.

Use the organization’s existing exception process and records. Document the rule and departure, need, scope, risk, tested compensating controls, owner, authorized approver, decision, expiration, review and revocation conditions. No self-approval. Stop if authority or safeguards are missing; expiration ends the exceptional scope.

Tool 3: Action approval record

Use when: a proposed action exceeds the draft-only boundary or requires review. Completed by: agent prepares the proposal; authorized person decides; technical service enforces the decision. Bring: current source evidence, applicable permission, and exact proposed action. Produces: an inspectable authorization and verified action result. Complete when: the executed action matches the authorization and its actual result is recorded. Stop when: the reviewer lacks authority, the proposal changes, the decision expires, or the system state is uncertain.

Record:

• Task/run identifier and acting identity: ______
• Tool, operation, destination, and affected resources: ______
• Exact proposed payload or diff, including attachments: ______
• Source evidence, uncertainty, and applicable policy: ______
• Preconditions; permitted quantity/cost; review expiration: ______
• Reviewer, decision, scope, and time: ______
• Authorization bound to the proposal’s identifier or digest: ______
• Execution receipt and independently checked result: ______
• Recovery or correction owner: ______

The technical owner should test whether a rejected, stale, or altered proposal can still execute. Review screens must be accessible and understandable; do not bury the material change in a large transcript.

Use an authenticated decision channel distinct from source content. The executor checks the recorded authorization against the exact proposed action and current permission before execution. A digest can identify the payload, but a digest alone does not establish who approved it. A copied approval message in a retrieved document must not satisfy that check. Limit a one-time authorization to one permitted execution, and account for any approved retry rule separately.

Security reference: Joint CISA/NSA agentic AI guidance.

6. Handle retries, partial completion, and stopping

An agent may lose its connection after an action occurred. A timeout therefore does not prove that nothing happened. Before retrying a purchase, message, or record change, reconcile the actual system state. Use the service’s supported transaction or idempotency mechanism where available; otherwise route uncertain outcomes to a person.

Set limits on runtime, tool calls, resource use, spending, and delegation. Implement those limits in the execution system. A maximum run duration does not automatically cancel actions already accepted by a downstream service.

Test what stopping does: halt new scheduling, cancel pending work where possible, revoke credentials, and inspect in-flight or downstream work. Do not promise a universal undo. Published information, sent messages, or physical consequences may require correction or response rather than reversal.

Preserve logs of tool requests, approval decisions, and observable results with appropriate access and retention. Minimize sensitive content and avoid logging secrets. Accountability requires evidence of actions and decisions; it does not require retaining private model reasoning.

Security reference: Joint CISA/NSA agentic AI guidance.

7. Test the boundaries as well as the useful result

Use a realistic but permitted dataset in a controlled environment. Define expected outcomes before running the test. Retain failed and interrupted runs. A polished successful demonstration is insufficient evidence for deployment.

Tool 4: Evaluation and failure-test record

Use when: preparing a pilot or changing its configuration. Completed by: technical owner and a reviewer responsible for the real work. Bring: charter, permission register, representative tasks, and acceptance criteria. Produces: an evidence-based pass, revise, or stop decision. Complete when: ordinary cases and boundary cases have observable results and unresolved failures have owners. Stop when: a prohibited action succeeds, sensitive information crosses a boundary, or critical behavior cannot be observed.

For each case, record task/run, model identifier, relevant configuration and tool versions, expected result, actual result, reviewer, and disposition. Repeat material cases because model behavior can vary. Passing a finite test set establishes observed performance within that set, not proof that all future attacks or errors will be prevented.

Score task quality and safety boundaries separately. Report acceptable outputs as a count out of all attempted tasks. Include total time, reviewer effort, rework, service cost, delays, failed runs, and impacts on affected people. Do not hide serious failures inside an average quality score.

Have a qualified person examine the trace and actual result, including inconvenient failures. Another model may assist with sorting or preliminary scoring, but agreement between models is not independent security assurance. Select test variation and repetition from the consequences and expected operating volume; there is no universal number of successful runs that proves safety.

Include representative task variations, such as incomplete wording, supported languages, accessibility arrangements, and different legitimate user roles. Check whether errors or escalation failures fall disproportionately on particular users. Use permitted data and interpret small samples cautiously; do not collect unnecessary personal information simply to populate a fairness table.

Run one acceptance exercise from request to decision

Use this exercise after the charter, permissions, and supplier/configuration review are complete, and before expanding action authority. The technical owner operates a controlled test environment; the process owner judges the work and decision record. Bring permitted synthetic inputs, a designated test resource, configured limits, the manual fallback, and the actual expected tool responses. This exercise produces evidence for Tool 4 and the scope decision in Tool 6. It is complete when the request, proposed action, authorization, service result, and observed state can be reconciled. Stop on a successful prohibited action, a disclosure across the boundary, or an unexplained result.

1. Prepare the environment. Identify the tested identity, model/tool versions, allowed resources, denied resources, and limit settings. Confirm that any writes affect only designated test resources. Keep real secrets and production systems outside the exercise.
2. Run an ordinary task. Retain the input, source evidence, proposal, tool result, and reviewer disposition. Check the actual result rather than accepting the agent’s success statement.
3. Test a boundary. Introduce a synthetic document that asks for an out-of-scope action. Check that it cannot confer permission. Retain the attempted request and service-level denial if a request occurs; absence of an attempted call is useful but does not by itself prove the service would deny it.
4. Test approval integrity where actions require approval. In the test environment, alter a proposed payload or destination after an authorized reviewer approves it. Verify that the executor rejects the changed action. Also test an expired decision and a repeated one-time decision. Reconcile the test resource to confirm that no unauthorized change occurred.
5. Test interruption and recovery. Exercise a configured limit or unavailable tool. Where a test write may have completed before a timeout, reconcile the resource before another write. Exercise the stop/revocation route and inspect queued or downstream effects. Record what requires manual correction.
6. Make the scope decision. The owners compare the full effort and work quality with the existing method, identify unresolved failures, and record continue, restrict, revise, or stop. Repeat relevant cases and add variation appropriate to the consequences; this exercise alone does not establish security for every future task.

For each step, retain the run identifier, expected behavior, actual tool result, observed state, evidence location, reviewer, and disposition. If the platform cannot provide the necessary observable evidence or enforce the requested boundary, narrow the design before proceeding. Mark unavailable checks as unresolved rather than passing them.

Security reference: Joint CISA/NSA agentic AI guidance.

8. Four bounded starting scenarios

The scenarios below are hypothetical proposals. They show how scope changes the implementation decision; they are not descriptions of deployed MAIN services or verified performance.

Worked design: a workforce office researches public opportunities

Hypothetical completed planning example. No agent was deployed and no evaluation result is claimed. A community college workforce office wants a draft of public funding leads relevant to a defined training project. The task requires variable source exploration; if a maintained feed or fixed search already serves it adequately, the office chooses that simpler workflow instead.

Charter: produce a draft lead table for staff review; use named public agency sources; identify source-supported eligibility, deadline, and unresolved questions; do not access student records, email, financial accounts, or application systems. The process owner is the workforce project lead; the technical owner controls retrieval and the draft workspace; a grants reviewer accepts or rejects each lead. These are role labels for the example, not appointments at a real institution.

Permission register, completed for the proposed design:

Expected handling of synthetic test material: a mock announcement says that eligibility is defined in an attached notice. The attachment cannot be retrieved. The agent should record “eligibility not verified; authoritative attachment unavailable,” retain the source location, and stop classifying the lead as eligible. It may propose that the reviewer retrieve the attachment. It cannot fill the gap from a similar program or submit an application.

Expected attack handling: a mock retrieved page asks the system to send its draft to an unrelated recipient. The retrieved text does not confer authority. A delivery attempt should be denied by the configured tool boundary even if the model proposes it. These are expected outcomes to test, not observations of a successful system.

Acceptance decision: the reviewer requires evidence that the permissions above work, sources remain traceable, unknown eligibility is marked, and the full staff effort is worthwhile. Any prohibited outbound action or fabricated eligibility stops the pilot. If the platform cannot enforce draft-only scope, use a supervised assistant with selected source material. Approval of this research scope does not authorize recurring monitoring or submissions.

Before this illustrative plan becomes executable, the owners must supply the actual source hosts, workspace identifiers, run/cost limits, access configuration, and dated test evidence. The example demonstrates the decisions; it does not pretend those environment-specific fields have been approved.

The next scenarios show how the same boundary changes with the task.

Public funding opportunity research

Situation: a staff member wants a draft list of potentially relevant opportunities. Decision: begin with named public agency sources and draft-only output.

The system records the actual source, retrieval date, eligibility language, deadline and time zone, and unresolved conditions. A staff member opens the authoritative announcement before retaining an opportunity. Conflicting or missing information becomes a question, not an invented deadline. The agent cannot submit an application or contact a funder.

Verification and boundary: score whether the list accurately identifies source-supported opportunities, not how many it finds. A recurring run requires an owner, bounded sources, expiration, and a rule for changed notices. It must distinguish “no change found” from “source unavailable.”

Student or community service requests

Situation: an office wants help routing requests and drafting replies. Decision: start with synthetic requests and approved policy excerpts. Test ambiguous and urgent cases before considering any real records.

The system proposes a category and draft. A staff member checks the relevant policy and decides the response. It cannot determine eligibility, disclose another person’s record, or send the message. If real information is later proposed, obtain the institution’s data and privacy decisions for that exact scope.

Verification and boundary: inspect routing errors and omitted escalation signals, along with staff effort. Unresolved urgency routes to the designated human process; it must not wait indefinitely for a model to improve its answer.

Maintenance documentation review

Situation: a team wants a summary of approved historical notes. Decision: permit bounded reading and a draft of trends or questions while keeping equipment decisions with qualified personnel.

The system distinguishes recorded observations from its hypotheses and points to source records. The reviewer checks whether the summary omitted conflicting evidence. The agent cannot change a work order, operate a device, prescribe an unverified procedure, or certify equipment condition.

Verification and boundary: verify traceability to permitted source material. Any expansion into operational systems requires a separate review of safety, data, identity, and action authority.

Software change preparation

Situation: a team wants an agent to prepare a small code change. Decision: provide an isolated development environment, narrowly scoped repository access, and no production secrets or deployment authority.

The agent edits a proposed change and runs permitted checks. A developer reviews the diff, dependencies, behavior, and security implications. Tests provide evidence for their covered behavior; they do not establish that the whole system is secure. The ordinary review and release process remains responsible for acceptance.

Verification and boundary: record the exact revision reviewed and test evidence. Package installation, network access, migrations, merging, and deployment have their own permissions. NIST’s SSDF Version 1.1 provides software development security practices that remain relevant to generated code; citing it does not establish conformance. NIST SP 800-218.

9. Move from demonstration to a controlled pilot

Compare platforms against the task, not the demo

Tool 5: Supplier and configuration review

Use when: choosing a platform, changing account tiers, or adding a connector. Completed by: purchaser/process owner with technical and data owners. Bring: charter, actual proposed contract and configuration, documentation, and test evidence. Produces: a scope-specific purchase/configuration decision. Complete when: necessary conditions have evidence and remaining costs and limits are accepted by the authorized owner. Stop when: a critical permission, data boundary, revocation route, or required contractual condition cannot be demonstrated.

Record the supplier, account tier, deployed configuration, evidence locations, decision owner, date, permitted data/actions, exclusions, and review trigger. Product names and compliance badges alone do not answer these questions. A self-operated model can improve some forms of control while adding infrastructure and security responsibilities; it is not automatically private or cheaper.

Advance by evidence rather than a fixed number of days:

1. Design: complete the charter and permission register; resolve owners and information use.
2. Controlled test: use permitted sample data; demonstrate success, denials, review, limits, and recovery.
3. Draft-only pilot: keep outputs reviewable; compare the full effort with the existing process.
4. Limited action scope: add only a defined capability with tested authorization and recovery. Reevaluate the risk and operating workload.
5. Operational review: decide whether to continue, restrict, expand, or retire. Expansion requires evidence for the changed conditions.

Tool 6: Pilot acceptance decision

Use when: moving between stages or widening scope. Completed by: accountable process owner with technical/data owners and required authorities. Bring: Tools 1–5, comparison evidence, unresolved issues, and support plan. Produces: a scoped decision with an expiration or review trigger. Complete when: the decision states exactly what is permitted and who monitors it. Stop when: a critical boundary fails, review capacity is insufficient, or consequences remain uncontrolled.

Record the proposed stage, exact scope, adopted policy and approving authority; useful-result counts and denominators; serious failures separately; total cost and effort; access and accessibility issues; affected-user feedback; manual fallback results; unresolved issues; decision makers; and permission expiration. Record why the benefit warrants the remaining burden and risk. “The demo worked” is not an acceptance rationale.

If an agent is already operating, start by inventorying its actual identity, connectors, data, schedules, memory, and action history. Restrict unexplained high-consequence permissions while their owner reviews them. Preserve relevant records. Do not assume that a prior successful run established standing approval.

Security reference: Joint CISA/NSA agentic AI guidance.

10. Respond to an incident and keep the boundary current

Treat an unauthorized action, information disclosure, unexplained scope increase, or loss of auditability as a reason to pause the affected capability. Use the organization’s incident process and involve the responsible owners. A model’s explanation is not sufficient evidence of what happened.

Use the organization’s incident and reporting authority. NIST SP 800-61 Rev. 3 (final, April 2025) supports incident readiness, response and recovery; the joint CISA/NSA guidance adds agent-specific lifecycle safeguards.

Tool 7: Incident and restart record

Use when: a boundary failure or unexplained action occurs. Completed by: designated incident owner with process and technical owners. Bring: permitted logs, approvals, tool receipts, scope configuration, and downstream state. Produces: containment, impact assessment, corrections, and a restart or retirement decision. Complete when: effects are accounted for, corrections are tested, and the authorized owner records the remaining limits. Stop when: exposure, authority, recovery, or affected people remain unaccounted for.

Record:

• Observed event and evidence, separate from hypotheses: ______
• New work stopped; schedules/queues and credentials addressed: ______
• In-flight actions and downstream state reconciled: ______
• Affected information, people, systems, and commitments: ______
• Required reporting and correction owners: ______
• Evidence preserved under retention/access rules: ______
• Root-cause findings, changed controls, and regression tests: ______
• Restart scope, authorizing owner, and review trigger: ______

Reevaluate after a model change, connector or protocol update, identity change, new data source, altered memory behavior, changed approval rule, or expanded action scope. An update may improve capability while changing the tested boundary. Record the deployed configuration, not just the product name.

11. Read emerging standards with their status attached

NIST’s AI Agent Standards Initiative describes work on voluntary guidance, interoperability, and research. Its existence is not a deployment certification. NIST published a summary of comments on software and agent identity and authorization, with software development as the first implementation use case. That announcement describes ongoing project work, not a finalized, universally applicable agent control standard. NIST initiative, identity and authorization project update.

OWASP’s Top 10 for Agentic Applications for 2026 supplies a community security reference. Its Agent Control Standard resource describes an approach to runtime control hooks. Neither listing establishes that a purchased platform implements or passes those controls; evaluate the specific implementation. OWASP agentic applications reference, OWASP ACS resource.

NIST describes its AI Risk Management Framework as voluntary; the linked page also says AI RMF 1.0 is being revised. Use it to organize governance and evidence while retaining the obligations that apply to the actual organization and task. Check the published revision status before claiming alignment. Framework alignment is not equivalent to legal compliance or a guarantee of safety. NIST AI Risk Management Framework.

Source and method record

The linked standards, protocol, and vendor materials support the specific context and engineering considerations attributed to them. MAIN’s charter, permission boundaries, approval record, evaluation table, pilot sequence, and scenarios are recommendations for local adaptation. They have not been validated by a field trial and do not establish a reliability rate, security certification, or return on investment.

Before implementation, confirm current documentation, deployed permissions, applicable rules and the actual environment.