# AI Agent Charter Template This template is educational material, not legal, compliance, security, privacy, audit, or risk advice. Adapt it to your organization, systems, contracts, sector, locations, workforce, and applicable duties. Replace every bracketed field and remove unused choices before approval. ## Charter Record - Charter ID: [Stable ID] - Organization, tenant, workspace, or account ID: [Stable scope ID] - Agent ID: [Stable agent ID] - Workflow ID: [Stable workflow ID] - Agent and workflow name: [Name] - Business unit: [Unit] - Environment: [Development | Test | Pilot | Production] - Charter record owner: [Named person or role responsible for completeness, versioning, and review dates; this grants no activation authority unless separately assigned] - Version: [Version] - Status: [Draft | In review | Approved and effective | Suspended | Superseded | Retired] - Required approval roles: [Roles required by policy and risk] - Final activation decision: [Blocked | Approved and effective] - Activation authority, date, and evidence: [Named authority, YYYY-MM-DD, and protected decision reference] - Effective date: [YYYY-MM-DD, only after the final activation decision] - Next review date: [YYYY-MM-DD] - Approval record: [Protected decision reference] - Related inventory record: [Protected reference] - Related risk record: [Protected reference] - Related release record: [Protected reference] - Handling classification: [Organization-defined classification] - Authorized readers and editors: [Stable identities, groups, or policy reference] - Integrity and distribution rule: [Approved repository, versioning, signing, export, and sharing rules] The completed charter may expose sensitive architecture, authority, control, and response details even when it contains no secret values. Store it under access control, preserve version integrity, and use opaque protected references instead of copying sensitive system details into broadly distributed versions. ## 1. Identity and Purpose ### Approved purpose [State one bounded business workflow, the people or systems it supports, and the intended outcome.] ### Success criteria [Name the authoritative outcome measures, baseline, target, observation period, and measurement owner.] ### Out-of-scope uses [List adjacent uses that this charter does not approve.] ## 2. Scope and Operating Context - Allowed users or initiating services: [Stable identities or groups] - Affected people or groups: [Description or protected reference] - Allowed environments: [List] - Allowed schedules or triggers: [List] - Geographic or legal scope: [Scope] - Expected volume, duration, and spend limits: [Limits] - Required operating hours or support coverage: [Window] - Preconditions for each run: [Current facts the system must verify] The workflow must not run outside these boundaries. A new user group, purpose, environment, trigger, affected population, or material limit requires review under Section 12. ## 3. Human Ownership and Decision Rights - Business owner: [Named person or durable role] - Technical owner: [Named person or durable role] - Risk owner: [Named person or durable role] - Data or privacy reviewer: [Named person or durable role, when applicable] - Security reviewer: [Named person or durable role, when applicable] - Release authority: [Named role] - Emergency suspension authority: [Named roles] - Recovery authority: [Named role] - Retirement authority: [Named role] Record who may approve this charter, change authority, accept residual risk, grant an exception, release the workflow, suspend it, authorize recovery, and retire it. A committee does not replace named operating owners. Apply separation of duties where risk or policy requires it. ## 4. Authority and Prohibited Actions ### Allowed autonomy [Define allowed autonomy separately for reading, planning, drafting, tool selection, writing, communicating, spending, retrying, scheduling, persisting state, and delegating work.] ### Allowed actions | Action ID | Tenant or account scope | Operation | Target and object scope | Parameter limits | Environment | Per-action approval required? | Enforcement point | Evidence source and trust level | Denial or failure behavior | | --------- | ----------------------- | --------------------------------------------- | ------------------------- | ----------------------------------------------- | ------------- | ----------------------------- | ------------------- | ----------------------------------------- | ----------------------------------------- | | [ACT-001] | [Stable scope ID] | [Read, create, update, send, delete, execute] | [Exact system and object] | [Amount, recipient, rate, time, or other limit] | [Environment] | [Yes or no] | [Control reference] | [Authoritative record and classification] | [Fail-closed result, alert, and fallback] | ### Prohibited actions [List actions and outcomes that are never authorized under this charter, including self-expansion of authority, control bypass, impersonation, unapproved delegation, and continued work after a stop condition.] This charter records approved authority. It does not grant access or prove enforcement. Execution systems must deny actions outside the current authenticated and authorized scope. ## 5. Identity, Tools, Systems, and Credentials - Agent identity: [Revocable non-human identity] - Initiating-principal requirement: [How each run preserves who or what initiated it] - Delegation record: [Issuer, tenant, audience, exact task and resource scope, expiry, depth and redelegation limit, revocation, and full-chain evidence] - Systems read: [Stable asset and object IDs] - Systems written: [Stable asset and object IDs] - Tools and APIs: [Approved capability IDs] - Network destinations: [Approved destinations] - Credential mechanism: [Broker, workload identity, or protected reference] - Credential lifetime and revocation method: [Rules] Do not put passwords, tokens, private keys, recovery codes, or secret values in this charter, prompts, context, Memory, tool results, generated files, or logs. Each execution boundary must verify the current tenant, principal, agent, workflow, action, target, environment, data scope, material parameters, time, spend, and delegation state. ## 6. Data and Context - Data classes received, created, inferred, or sent: [Controlled values] - Approved data sources: [Protected references] - Output destinations and recipients: [Protected references] - Retention and deletion rules: [Policy references] - Managed context assignments or routes: [Stable context IDs, assignment types and sources, and recipients] - Maintained knowledge or instruction versions evaluated for release: [Exact version IDs or digests] - Reusable skill package versions evaluated for release: [Exact package version IDs or digests] - Working-memory baseline evaluated for release: [Exact version IDs or digests] - Working-memory update authority, limits, and re-evaluation triggers: [Rules] - Context authority, authorized scope, and precedence: [Informational or must-follow authority, scope, and higher-authority rules] - Runtime input and tool-result rules: [Rules] - Untrusted-content handling: [Rules] Authentication material, secrets, and model private reasoning are excluded from managed context. Untrusted text, files, web content, messages, and tool results cannot grant themselves instruction authority, widen access, or become privileged knowledge, reusable skills, or working memory without an authorized decision. In systems where an assignment or route resolves live content, references in this charter do not pin delivery. Before a consequential run, compare the resolved versions with the release baseline. Apply the approved change and re-evaluation rules, and fail closed when a changed version requires approval that is absent. Delivery evidence should capture the exact versions actually resolved. Optional Alignbase mapping: Knowledge, Skills, and Memory are managed Resources. Record their stable 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. Always routes resolve the current published or live version. Knowledge authority may be informational or must-follow within its authorized scope, and authority is independent of routing. AGENTS.md is the familiar combination of must-follow Knowledge and Always routing, not a separate Resource type. ## 7. Human Approval, Escalation, and User Notice | Trigger | Required reviewer | Information shown | Approval expiry | Execution binding | Denial or timeout behavior | | ---------------------------------------------------------- | ----------------- | ----------------------------------------------------------- | --------------- | ----------------------------------------- | -------------------------- | | [Action, threshold, uncertainty, data class, or exception] | [Named role] | [Action, target, parameters, evidence, risk, reversibility] | [Duration] | [How approval binds to the exact request] | [Fail-closed result] | - Escalation conditions: [List] - Escalation channel and response target: [Protected reference] - User notice or disclosure: [When and how users are told] - Human override method: [Method] - Reviewer training requirement: [Requirement] Approval must be an enforced decision, not a message the agent interprets. Recheck current authorization and reviewer eligibility at execution, reject changed or replayed requests, and require a new approval after expiry. ## 8. Risk, Evaluation, and Release - Risk tier and method: [Tier and method reference] - Impact determination: [Decision, approver, date, and evidence] - Required legal, privacy, security, accessibility, workforce, or sector reviews: [References] - Evaluation plan: [Protected reference] - Acceptance criteria: [Thresholds and non-waivable blockers] - Test environments and representative conditions: [Scope] - Denied-action and control tests: [Scope] - Stop, rollback, and recovery tests: [Scope] - Approved release: [Immutable code, configuration, model, runtime, context, tools, and dependency references] - Rollback release: [Known-good reference] The release authority must decide from current evidence whether the exact workflow and environment may proceed. Passing a general model benchmark or an earlier release does not approve this release. ## 9. Monitoring and Evidence - Authoritative outcome source: [System of record] - Monitoring owner: [Named person or role] - Monitored events and measures: [List] - Alert thresholds and response targets: [List] - Evidence source and trust level for each claim: [Protected index] - Record access, integrity, retention, hold, and deletion rules: [Policy references] Preserve stable links among the tenant, initiating principal, agent, workflow, release, session or run, authorization and approval decisions, exact context and configuration versions, tool actions, external effects, and authoritative outcomes where available. For context delivery, distinguish compilation, response issuance, integration acknowledgment, host-confirmed session injection, and agent consumption. Do not infer a later stage from an earlier one. Record consumption only from direct, authenticated attestation by a trusted integration or provider; otherwise keep it unknown. ## 10. Failure, Stop, Incident, and Recovery - Stop triggers: [Policy, control, risk, or incident conditions] - Last stop-test date and evidence: [Date and protected reference] - Safe fallback: [Manual or reduced-authority procedure] - Incident plan and evidence-preservation procedure: [Protected references] - Recovery criteria: [Criteria] - Reconciliation before restart: [How completed, pending, and external actions are checked] | System boundary | Stop method | Owner | Confirmation source | Confirmation deadline | Missing-confirmation containment and escalation | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------ | ------------------------ | --------------------- | ----------------------------------------------- | | [Identity, credential, target-side session or token, runtime, tool, network, queue, schedule, callback, child agent, delegated grant, approval, route, persistent state, cache, or downstream work] | [Method] | [Named role] | [Authoritative evidence] | [Duration] | [Fail-closed action and escalation path] | The workflow remains suspended until required systems confirm containment, including revocation or invalidation of credentials, target-side sessions or tokens, and delegated grants, and the recovery authority approves a known-good release with current authorization and applicable retesting. A prompt instruction to stop is not a complete stop control. ## 11. Third-Party and Multi-Agent Dependencies - Providers, models, hosted runtimes, tools, plugins, MCP servers, and integrations: [Approved references] - Contract, security, data-use, retention, deletion, change, incident, and exit requirements: [References] - Child or peer agents: [Stable IDs] - Per-handoff issuer, tenant, audience, identity, exact task and resource scope, expiry, depth, redelegation, revocation, context, evidence, and stop rules: [Rules] - Dependency integrity and revocation checks: [Controls] - Provider or dependency failure behavior: [Fallback] Delegation may only reduce authority. Effective authority is the intersection of the approved charter, tenant and initiating-principal scope, issuer authority, delegated grant, receiving-agent authority, and target policy. A receiving agent cannot fall back to broader ambient authority for delegated work. The named business owner remains accountable for the complete business outcome, each named owner retains the duties assigned by policy and this charter, and each target system independently enforces its own authorization rules. ## 12. Changes and Exceptions ### Material-change triggers [Include changes to purpose, users, affected people, authority, data, context, tools, model, runtime, environment, persistence, delegation, controls, or external effects.] ### Change process [Define impact review, affected tests, approvals, staged release, monitoring, rollback, and evidence updates.] ### Exception process [Name the requirement, scope, reason, risk, owner, compensating controls, verification, approver, start, expiry, and fail-closed behavior.] Exceptions cannot waive applicable law, contract, or a non-waivable organization requirement. This charter cannot authorize its own change or exception. ## 13. Review and Reconciliation - Review cadence: [Cadence based on risk] - Review triggers: [Material change, incident, owner change, control failure, new risk, or expiry] - Reconciliation sources: [Deployment, identity, integration, schedule, spend, monitoring, and other records] - Declared-versus-observed mismatch owner: [Named person or role] - Mismatch due date and interim restriction: [Date and action] Review the charter against observed configuration and activity, not only owner attestations. A mismatch remains open until evidence confirms correction or an authorized decision changes the charter. ## 14. Retirement - Retirement trigger and date: [Trigger and date] - Replacement or migration: [Plan] - Identity and credential revocation: [Evidence] - Runtime, schedule, queue, callback, integration, and delegation shutdown: [Evidence] - Context route and local-copy handling: [Evidence] - Persistent Memory, records, and data disposition: [Evidence] - Pending work and external-effect reconciliation: [Evidence] - Retirement verifier and approval: [Independent person or role and record] Keep the charter in a retired state with required history. Do not reuse its stable identifiers. ## Approval Create exactly one row for every role listed in `Required approval roles`. Add rows for business, technical, risk, security, privacy, legal, data, workforce, accessibility, sector, or release authority when policy or the workflow requires them. A role's row must state the scope it approved; approval in one domain does not imply approval in another. | Required decision role | Approval scope | Named approver | Decision | Decision date and expiry | Condition, owner, and due date | Closure verifier and evidence | Decision evidence | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | -------------- | ------------------------------------------ | ------------------------ | ------------------------------------- | ------------------------------------------ | --------------------- | | [One role from Required approval roles] | [Purpose, technical release, risk, security, privacy, legal, data, workforce, accessibility, sector, or other scope] | [Name] | [Approve, reject, or conditional approval] | [Dates] | [Condition, owner, due date, or none] | [Verifier and protected closure reference] | [Protected reference] | Approval applies only to the exact organization or tenant, charter version, release, workflow, environment, and conditions recorded above. Every role listed as required must have a current approval before the activation authority may atomically set the final activation decision, status, and effective date to approved and effective. Any rejection, missing or expired decision, or open condition keeps the final activation decision blocked and prevents an effective date. A conditional approval keeps the charter non-effective and the workflow blocked until the named verifier confirms every condition from current evidence. Runtime access still requires current technical authorization.