AI Agent Charter Template

An AI agent charter is the approved operating contract for one agent workflow. It turns a broad request such as “use an agent to help with invoices” into a bounded agreement about purpose, ownership, authority, systems, context, human review, evidence, and stop conditions.

The charter is useful before a pilot, production release, material change, or renewal. It gives business, technical, risk, and review teams one document to approve, then gives engineers a specification to implement and test.

Download the AI agent charter template (Markdown)

The download contains a charter record, 14 working sections, action and approval tables, and a version-bound approval record. It is educational material, not legal, compliance, security, privacy, audit, or risk advice. Adapt it to your obligations and systems before approval.

A completed charter may reveal sensitive system relationships, authority, control locations, and stop methods even when it contains no credentials. Classify it, limit readers and editors, preserve version integrity, and use protected references for details that should not travel with an exported copy.

TL;DR

Use an AI agent charter to:

1. Define one agent-workflow-environment combination and its intended outcome.
2. Assign named human owners and decision rights.
3. Bound authority by action, target, data, parameter, environment, and approval condition.
4. Connect tools, context, controls, tests, monitoring, and evidence to the approved release.
5. State what triggers escalation, suspension, recovery, change review, and retirement.
6. Reconcile the approved charter with what identity, deployment, integration, and monitoring systems show.

A signed charter does not grant technical access, enforce a rule, prove a control worked, or show what an agent did. Those claims need evidence from the systems that made or observed the relevant decision.

What Is an AI Agent Charter Template?

An AI agent charter template is a reusable structure for approving how one agent workflow may operate.

The useful unit is usually the agent-workflow-environment combination. One agent may summarize records in a read-only test environment and update production records under approval. Those uses need separate authority, tests, controls, and evidence even when they share a name or model.

NIST’s AI RMF Core calls for clear AI risk roles, inventory mechanisms, defined human oversight, documented intended purpose, specified application scope, and a decision about whether development or deployment should proceed. The framework does not prescribe an agent charter. This template combines those outcomes into one practical workflow record.

Singapore’s updated Model AI Governance Framework for Agentic AI recommends bounding agent risk and power upfront, defining meaningful human accountability and checkpoints, applying lifecycle controls, and informing users. A charter is one way to record those decisions, but the controls still have to exist outside the document.

1. Separate the Charter, Policy, Inventory, and Release

These records answer different questions:

Record	Main question	Scope
Governance policy	What rules apply across the organization?	Agent program
Inventory	Which agents and workflows exist, and who owns them?	Portfolio
Requirements document	What must the workflow and controls do, and how will each item be verified?	Design and acceptance
Charter	Under which exact conditions may this workflow operate?	One agent workflow and environment
Release record	Which code, configuration, model, context, tools, and controls were approved?	One deployable version
Run evidence	What happened during one execution?	One session or run

The AI agent governance policy template sets common rules. The AI agent inventory template creates a discovery and tracking record. The AI agent requirements document template specifies testable behavior and constraints. The charter applies policy to one inventory row or linked set of rows, and the release record binds the charter to the exact implementation.

Keep stable IDs among these records. Names change, and one agent can support several workflows, so name matching alone weakens review and audit.

2. Start With a Bounded Purpose and Outcome

Write the purpose as one business workflow, user, and intended outcome. “Help the finance team” is too broad. “Draft invoice-exception summaries for an accounts-payable reviewer” names the task and keeps the consequential decision with a person.

The charter should record:

• The business problem and approved workflow
• Allowed users or initiating services
• People or groups affected by outputs or actions
• Allowed environments, schedules, and triggers
• Expected volume, duration, and spend limits
• Success criteria, baseline, target, measurement period, and authoritative outcome source
• Adjacent uses that remain out of scope

An outcome target does not justify wider authority. It gives owners a way to decide whether the workflow remains useful enough to operate, narrow, or retire.

3. Assign Human Ownership and Decision Rights

At minimum, name a business owner and technical owner. Add risk, security, privacy, data, legal, workforce, accessibility, or independent release roles when the workflow requires them.

The charter should state who may:

• Approve the purpose and continued use
• Approve risk and impact decisions
• Change authority, tools, data, or context
• Approve a pilot or production release
• Accept a time-bounded exception
• Suspend the workflow during an incident
• Authorize recovery
• Verify retirement

NIST AI RMF Govern 2.1 calls for documented roles, responsibilities, and lines of communication, while Govern 2.3 assigns responsibility for AI development and deployment risk decisions to executive leadership. A steering group can provide review, but it should not hide who owns daily operation or each approval.

Apply separation of duties when one person approving their own request would make the checkpoint meaningless. Independence should follow the risk and the organization’s policy, not a fixed title list copied into every charter.

4. Define Authority as Enforceable Actions

The authority section should be precise enough for an engineer to implement and a reviewer to test.

For each action, record:

• Organization, tenant, workspace, or account scope
• Operation, such as read, create, update, send, delete, or execute
• Target system and object scope
• Material parameter limits, including amount, recipient, rate, duration, or environment
• Whether a human approval is required
• Enforcement point and control reference
• Evidence source and failure behavior

Avoid labels such as “CRM access” or “medium autonomy.” They do not say whether the agent may read a contact, export a segment, change an owner, send a message, or delete a record.

Record prohibited actions separately. Include actions that the workflow must never perform, attempts to widen its own authority, bypass controls, impersonate a person, delegate beyond its scope, or continue after a stop condition.

The AI agent autonomy levels guide can provide a common vocabulary, but the charter should still split authority across reading, planning, drafting, tool selection, writing, communication, spend, retries, scheduling, persistent state, and delegation.

5. Map the Charter to Identity, Tools, and Credentials

Every operating agent needs an attributable, revocable identity. Each run should also preserve the authenticated person, service, schedule, or parent agent that initiated it.

List systems, tools, APIs, network destinations, and allowed object scopes with stable references. Record the credential mechanism and revocation method, but never put a password, token, private key, recovery code, or secret value in the charter.

The charter records approved intent. It cannot authorize itself. At execution, identity systems, gateways, runtimes, tool adapters, approval services, and target applications should verify current scope. The decision should bind the tenant, initiating principal, agent, workflow, action, target, environment, data, material parameters, time, spend, and delegation state that matter to the request.

The UK’s National Cyber Security Centre advises teams to avoid unrestricted agent access, retain visibility and meaningful human control, apply least privilege, and plan for failure in its agentic AI adoption guidance. A charter makes the intended boundary reviewable, while technical controls make it real.

6. Specify Data and Context Boundaries

List the highest data classes the workflow may receive, create, infer, or send. Point to protected source, retention, deletion, residency, and recipient records instead of copying personal data or sensitive records into the charter.

Context needs its own boundary because it shapes agent behavior. In a provider-agnostic charter, record stable context IDs, assignment types and sources, maintained knowledge or instruction versions, reusable skill packages, the working-memory baseline, update authority, authority and authorized scope, precedence, re-evaluation triggers, and rules for runtime inputs and tool results.

For Alignbase, repository permission, delivery routes, and Knowledge authority are separate. Record Knowledge, Skill, and Memory Resource IDs and direct or Group Always route sources separately from the exact published Knowledge versions, published Skill packages, and current Memory baseline evaluated for release. Knowledge may be informational or must-follow within its authorized scope. AGENTS.md is the familiar combination of must-follow Knowledge and Always routing, not a separate Resource type. Always routes resolve the current published or live version, so a version written in the charter does not pin delivery. Before consequential work, the workflow should compare resolved versions with its release baseline and apply the approved change or re-evaluation rule. A route makes context available in the current-context bundle; it does not prove that a host inserted it into a model session or that the agent consumed it.

Authentication material, secrets, and model private reasoning are not managed context. Untrusted text, files, web content, messages, and tool results also cannot grant themselves authority or become privileged knowledge, reusable skills, or working memory without an authorized decision.

7. Design Human Checkpoints That Can Stop an Action

A useful checkpoint names a trigger, qualified reviewer, information shown, decision expiry, and fail-closed result.

The reviewer may need to see:

• Initiating principal and agent identity
• Purpose and proposed action
• Target, recipient, and material parameters
• Data and context involved
• Policy or risk trigger
• Evidence, uncertainty, and expected effect
• Reversibility and rollback path

The AI agent approval workflows guide explains how to bind approval to the exact action. A chat reply that says “approved” is not an enforcement boundary if the agent can change the target or parameters before execution.

Recheck authorization and reviewer eligibility at execution. Reject changed, expired, or replayed requests, and state what happens when nobody responds.

8. Bind Risk, Tests, and Approval to the Release

The charter should link to the current risk tier, impact determination, required reviews, test plan, acceptance criteria, and immutable release record.

Tests should cover the workflow under representative conditions, including:

• Expected tasks and authoritative outcomes
• Denied actions and least-privilege boundaries
• Tenant and user isolation
• Untrusted input and prompt injection
• Tool errors, timeouts, partial completion, and retries
• Approval denial, expiry, and replay
• Cost, rate, and duration limits
• Stop, rollback, recovery, and duplicate-action prevention

A general benchmark does not approve a specific workflow. Release evidence should identify the exact code, configuration, model deployment, runtime, context versions, Skill packages, Memory policy, tools, schemas, integrations, dependencies, and controls that were tested.

The release authority can then decide whether that exact workflow and environment should proceed, narrow, return for changes, or stop.

9. Define Monitoring and Evidence Before Release

Monitoring should follow the claims and failure modes in the charter. Name the owner, events, measures, thresholds, response targets, authoritative outcome sources, and record-handling rules.

Connect evidence with stable IDs for the tenant, principal, agent, workflow, release, session or run, authorization decision, approval, context versions, tool action, external effect, and outcome where those records exist.

Do not treat all evidence as equal. Record the source and trust level. An owner attestation, client report, application record, gateway decision, and independent test prove different things.

For context, distinguish compilation, response issuance, integration acknowledgment, host-confirmed session injection, and agent consumption. One stage does not prove the next. Consumption needs direct, authenticated attestation from a trusted integration or provider; otherwise it remains unknown.

10. Write and Test the Stop Path

The stop section should cover more than the main process. An agent may have active sessions, child agents, credentials, target-side tokens, queues, schedules, callbacks, pending approvals, delegated grants, integrations, context routes, persistent state, caches, and downstream work.

Record:

• Stop triggers and who can invoke them
• The method for each system boundary
• Expected confirmation and timeout behavior
• Last test date and evidence
• Safe manual or reduced-authority fallback
• Incident evidence preservation
• Recovery criteria and authority
• Reconciliation of completed, pending, and external actions before restart

A prompt instruction to stop cannot revoke a token, empty a queue, cancel a schedule, or undo an external action. Test the complete path under realistic failure conditions.

Record the method, owner, confirmation source, deadline, and fail-closed escalation for each boundary. Missing confirmation is a containment failure to escalate, not proof that the workflow stopped.

The workflow should remain suspended until required controls confirm containment and an authorized reviewer approves a known-good release with current access and applicable retesting.

11. Control Dependencies, Delegation, and Change

List providers, models, hosted runtimes, tools, plugins, MCP servers, integrations, and child agents that can alter the workflow’s risk or behavior. Link to contract, security, data-use, retention, deletion, change-notice, incident, and exit requirements where applicable.

For each agent handoff, preserve the issuer, tenant, audience, identity, exact task and resource scope, expiry, delegation depth, redelegation rule, revocation, context, evidence, and stop capability. Effective authority should be the intersection of the charter, initiating principal, issuer, delegated grant, recipient, and target policy. A receiving agent should not fall back to broader ambient authority for delegated work, and each target system should still enforce its own current authorization rules.

Define material-change triggers in the charter. A change to purpose, users, affected people, authority, data, context, tools, model, runtime, environment, persistence, delegation, controls, or external effects may require impact review, affected tests, approval, staged release, monitoring, and rollback.

Exceptions need exact scope, reason, risk, owner, compensating controls, verification, approver, and expiry. They cannot waive applicable law, contract, or a non-waivable organization rule, and the charter cannot approve its own exception.

12. Review, Reconcile, and Retire the Charter

Set a review cadence based on risk, then add event-driven triggers for incidents, owner changes, control failures, new dependencies, wider access, and exception expiry.

Review should compare the charter with observed state from deployment, identity, integration, schedule, spend, monitoring, and outcome systems. An owner saying the record is current does not resolve a mismatch when system evidence says otherwise.

At retirement, verify:

• Agent identity and credentials are revoked
• Runtimes, schedules, queues, callbacks, integrations, and delegation are stopped
• Context routes and local copies are handled under policy
• Persistent Memory, records, and data follow approved disposition rules
• Pending work and external effects are reconciled
• Required evidence and history remain available
• An authorized reviewer confirms completion

Keep the retired charter and its stable IDs. Old logs, incidents, approvals, and evidence may still refer to them.

Put the AI Agent Charter Template Into Operation

Complete the template with the business owner, technical owner, and the reviewers required by risk. Start with the highest-impact action because it usually determines the strongest control, test, approval, and stop requirements.

Then walk each approved action to its enforcement point and evidence source. If the team cannot show which system blocks an out-of-scope action, which record proves the decision, or how to stop pending work, the charter has found an operating gap before deployment.

Treat conditional approval as blocked work. Record each condition, owner, due date, closure verifier, and evidence, then keep the charter non-effective until every condition is closed. Any required rejection, missing or expired decision, or open condition should block the final activation decision; only the named activation authority should set the status and effective date after every required approval is current.

Store the approved charter as a versioned record, link it to the inventory and release, and route any must-follow agent instructions through the applicable governed context process. Reopen it when the workflow changes, not after the document’s review date has already passed.