Governance & control evidence
Minimum Viable AI Agent Register & Control Evidence Schema
An organization cannot govern an AI agent it cannot name, assign, bound, observe, and retire. This ungated register provides one structured record for those decisions: who owns the agent, what it may do, which data and tools it can reach, whose identity and authority it uses, when a human must approve an action, how it is evaluated and monitored, and where the evidence lives. This is an Implement Agentic proposal, not a NIST, OWASP, IMDA, ISO, legal, audit, or regulatory requirement — an operational starting point assembled from public guidance, to be adapted to your risks, sector, jurisdictions, contracts, and existing system-of-record conventions.
- Author
- Implement Agentic Research
- Published
- Published · Updated
- Reading time
- 13 min read
- Data currency
- Public source review current through 2026-08-10
Key findings
- Use one row per logical agent and environment combination. Production and sandbox versions should be separate when identities, permissions, models, data, or approval rules differ.
- Assign a stable `agent_id`; names and vendors will change.
- Store links to evidence, not credentials, secrets, personal data, raw prompts, or sensitive logs.
- Make risk boundaries machine-readable where possible: allowlisted tools, egress policy, privilege summary, autonomy level, approval-required actions, runtime limits, and spend limits.
- Update the record before deployment, after any material change, on an incident, at periodic review, and at decommissioning.
- Treat a completed row as an inventory assertion — not proof that a control works. Evaluation results, IAM exports, traces, policies, approvals, incident records, and retirement tickets remain the evidence.
What the register is designed to answer
A useful register should let a business owner, security reviewer, engineer, auditor, or incident responder answer five questions without reconstructing the system from chat messages:
- What is this agent for, and what is explicitly out of scope?
- What capability does it possess? That includes models, code execution, data, tools, network access, memory, identities, credentials and delegated privileges.
- Who remains accountable? Name business, technical and risk owners, plus the human or service principal on whose behalf it acts.
- How is it controlled and tested? Record autonomy limits, human checkpoints, release gates, monitoring, alerts, incident response and kill-switch evidence.
- Where is the current proof? Link versioned evidence and review dates rather than relying on a self-attested “approved” status.
How the schema maps to current guidance
The sources below influenced the field selection; none publishes this exact schema.
The February 2026 NCCoE document is a draft concept paper, not a final standard. NIST states that AI RMF 1.0 is voluntary and is being revised. OWASP is a security-risk taxonomy. IMDA’s document is a model governance framework. A field’s presence therefore does not establish compliance with any of them.
None of these organizations publishes this schema. The mapping records influence on field selection only — it is not an alignment, conformance, or compliance claim.
| Guidance | What it contributes | Register coverage |
|---|---|---|
| NIST NCCoE software- and AI-agent identity and authorization concept paper (draft) | Questions about agent metadata, authentication, key lifecycle, least privilege, dynamic authorization, delegation, human binding, auditability, non-repudiation and prompt injection | Non-human identity, identity provider, credential lifecycle, delegating principal, privileges, approval role, logs, monitoring and evidence links |
| OWASP Top 10 for Agentic Applications 2026 | Risks spanning goal hijack, tool misuse, identity and privilege abuse, supply chain, code execution, memory poisoning, inter-agent communication, cascading failures, human-agent trust and rogue behavior | Purpose bounds, tools, privileges, dependencies, runtime, memory, other agents/protocols, approvals, evaluation, monitoring and fail-safe controls |
| IMDA Model AI Governance Framework for Agentic AI, and the May 2026 update | Four dimensions: assess and bound risk; meaningful human accountability; lifecycle technical controls; end-user responsibility. The update adds multi-agent, third-party-agent and automation-bias practices | Risk tier and bounds, accountable owners, human checkpoints, lifecycle dates, technical evidence, third-party review and intended-user fields |
| NIST AI Risk Management Framework and Generative AI Profile | Voluntary lifecycle framing for governing, mapping, measuring and managing AI risk | Owners, impact, evaluation, monitoring, incidents, reviews and evidence |
The minimum schema, by control question
Not every field applies to every agent. Keep typed fields machine-readable: dates use `YYYY-MM-DD`, day/count fields use non-negative integers, URLs contain URLs, and yes/no fields use the documented tokens. Leave a typed value empty when it has not occurred or is not applicable, and record the reason in the associated status, exception, or notes field. Use `not_applicable — reason` only in free-text fields; reserve an unexplained blank for information that is genuinely unknown and track that gap as an exception.
CSV conventions: this release uses `schema_version` `IA-MVAAR-1.0`; ISO `YYYY-MM-DD` dates; lowercase `yes`/`no` for binary fields; `L0_advise_only`, `L1_read_and_draft`, `L2_approval_gated_action`, `L3_bounded_autonomous_action`, or `L4_expanded_autonomy` for `autonomy_level`; semicolons for multiple free-text items; and ` | ` between multiple URLs. Do not place spreadsheet formulas, executable links, credentials, or secret values in any field.
| Field group | Decision the record should make | Representative CSV fields |
|---|---|---|
| Record and lifecycle | What is the durable identifier, state and environment? | agent_id, record_status, lifecycle_stage, environment, deployment/review/retirement dates |
| Accountability | Who can accept risk, change the system and respond? | business_owner, technical_owner, risk_owner, vendor_or_builder |
| Purpose and bounds | What may the agent do, for whom, and with what consequence? | purpose, in_scope_tasks, prohibited_tasks, success_kpi, risk_tier, impact_if_wrong, reversibility |
| Model and runtime | Which version actually runs, and where? | model_provider, model_name_version, orchestration_runtime, hosting_location, execution_environment, code_execution_allowed |
| Data | What can enter, leave or persist? | data_sources, data_classification, personal_or_sensitive_data, data_residency, data_retention_policy |
| Tools and network | Which actions and destinations are reachable? | tool_or_api_inventory, tool_allowlist_policy, network_egress_policy |
| Identity and privilege | What identity acts, how is it authenticated, and whose authority is delegated? | non_human_identity_id, identity_provider, credential_type, credential expiry/rotation, delegating_principal, privilege_summary, privilege review date |
| Memory | What state persists, who can write it, and when is it deleted? | memory_type, memory_store, memory_scope, memory_write_policy, memory_retention_days |
| Autonomy and approvals | Which actions are automatic, bounded, approved or prohibited? | autonomy_level, runtime limits, value/spend limit, approval_required_actions, approval_role, fail_safe_or_kill_switch |
| Evaluation | What must pass before release and after change? | evaluation_suite_url, evaluation_status, last_evaluation_date, release_gate |
| Monitoring and incidents | Can operators reconstruct behavior and stop harm? | trace URL, alerts, log retention, incident runbook, last incident, open exceptions |
| Cost | Who owns spend, and what stops runaway execution? | cost_owner, monthly_cost_limit, cost_monitoring_url |
| Dependencies | Which services, agents, protocols and suppliers can change the risk? | upstream/downstream dependencies, other_agents_or_protocols, third_party_dependency_review |
| Evidence | Where are the current, versioned artifacts? | decommissioning evidence, control_evidence_urls, source_framework_mappings, framework_source_urls |
A proposed autonomy scale
The CSV uses a simple Implement Agentic scale. It is proposed, not an official maturity model:
Autonomy is not a label for intelligence. It describes the effective authority created by the combination of tools, credentials, memory, delegation and approval logic.
- L0 — advise only: no tools; a human decides and acts.
- L1 — read and draft: the agent may read approved sources and create a draft only in an isolated workspace; it cannot communicate externally or write to a production or authoritative system of record.
- L2 — approval-gated action: the agent may propose an external or system-of-record action, but execution is blocked until a named human approves it.
- L3 — bounded autonomous action: low-impact, reversible actions may execute within explicit scope, limits and continuous monitoring; higher-risk actions remain approval-gated.
- L4 — expanded autonomy: material or hard-to-reverse actions can occur without per-action approval. This is outside the minimum baseline and should trigger enhanced assurance, executive risk acceptance and jurisdiction-specific review.
How to operate the register
The register should never contain secret values, bearer tokens, private keys, passwords, raw sensitive prompts, or unrestricted log exports. Record secret-manager references and policy evidence instead.
- Create the record at intake. Do not wait until production. Unknown fields reveal the work required before a pilot.
- Review capability, not the demo. Walk from goal to model, data, tool, identity, privilege, memory and downstream consequence. A harmless-looking chat interface may sit over a powerful service principal.
- Link evidence. Useful artifacts include an architecture diagram, data-flow map, IAM policy export, secrets-rotation policy, tool allowlist, egress rule, model/version manifest, dependency inventory, eval report, trace dashboard, approval workflow, incident runbook and retirement ticket.
- Gate material changes. Re-review model swaps, new tools, wider data, new memory, privilege changes, new agent-to-agent links, increased autonomy, changed approval logic and new jurisdictions.
- Use triggered and scheduled reviews. The template records both `last_review_date` and `next_review_date`. Set the cadence from risk; do not mistake a calendar review for continuous monitoring.
- Close the lifecycle. Decommission the runtime, revoke identities and credentials, remove schedules/webhooks, dispose of retained data and memory, update dependencies, and link proof.
Download the data
Machine-readable CSV files behind the tables above. Cite this page as the source.
- Minimum viable agent register — blank CSV template (79 columns) (CSV download)Ungated blank template: the 79-column header row of the IA-MVAAR-1.0 schema with no data rows. Covers record and lifecycle, accountability, purpose and bounds, model and runtime, data, tools and network, identity and privilege, memory, autonomy and approvals, evaluation, monitoring and incidents, cost, dependencies and evidence. Dates use YYYY-MM-DD, binary fields use lowercase yes/no, autonomy_level uses L0_advise_only through L4_expanded_autonomy, semicolons separate free-text items and ' | ' separates URLs. Never store credentials or secret values in it.CSV · 0 rows
- Filled fictional example — one completed row (79 columns) (CSV download)A single completed row for a fictional, pre-production sandbox invoice-exception triage agent, using the same 79-column schema. Entirely fictional: the roles, systems and example.invalid URLs do not resolve and make no Implement Agentic or client production claim. It demonstrates how to write bounded assertions — an L1_read_and_draft autonomy level, prohibited tasks, privilege summary, approval roles and pending third-party review.CSV · 1 rows
Methodology
- Implement Agentic reviewed the official sources linked in the citations list through August 10, 2026 and mapped recurring control questions into a portable one-row-per-agent CSV.
- We prioritized fields that support ownership, capability bounding, testability, observability, incident response and retirement.
- The schema is an Implement Agentic proposal. None of the cited organizations publishes this schema, and the presence of a field does not establish alignment with, or compliance under, any framework.
- Two artifacts are published: a blank 79-column template (0 data rows) and a single-row fictional example that demonstrates how to write bounded assertions.
Limitations
- This is an Implement Agentic proposal, not a NIST, OWASP, IMDA, ISO, legal, audit, or regulatory requirement.
- The L0–L4 autonomy scale is proposed by Implement Agentic; it is not an official or industry-standard maturity model.
- The schema is deliberately cross-sector and cannot encode every obligation. It does not replace a legal analysis, privacy impact assessment, threat model, model/system card, vendor assessment, architecture review, safety case, sector control set or incident plan.
- It does not score control effectiveness. A completed row is an inventory assertion, not proof that a control works.
- Organizations should add jurisdiction, regulatory, records-management, labor, accessibility, safety and sector overlays as appropriate.
- The filled example is entirely fictional and pre-production. It demonstrates how to write bounded assertions without implying that Implement Agentic or a client operates the system described. Its example.invalid URLs intentionally do not resolve.
Sources
- Accelerating Adoption of Software and AI Agent Identity and Authorization (concept paper, draft) (opens in a new tab)NIST NCCoE · February 2026Cited for: Identity, authentication, key lifecycle, least privilege, delegation, human binding, auditability and prompt-injection questions. A draft concept paper, not a final standard.
- OWASP Top 10 for Agentic Applications 2026 (opens in a new tab)OWASP GenAI Security ProjectCited for: Agentic risk taxonomy informing the purpose-bounds, tools, privilege, memory, dependency and fail-safe fields. A security-risk taxonomy, not a control requirement.
- Model AI Governance Framework for Agentic AI (opens in a new tab)IMDA (Infocomm Media Development Authority, Singapore)Cited for: Four dimensions: assess and bound risk; meaningful human accountability; lifecycle technical controls; end-user responsibility.
- Updated Model AI Governance Framework for Agentic AI (factsheet) (opens in a new tab)IMDA · May 2026Cited for: Multi-agent, third-party-agent and automation-bias practices reflected in the dependency and intended-user fields.
- AI Risk Management Framework (opens in a new tab)NISTCited for: Voluntary lifecycle framing for governing, mapping, measuring and managing AI risk. NIST states AI RMF 1.0 is voluntary and is being revised.
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (opens in a new tab)NISTCited for: Generative-AI lifecycle risk considerations informing evaluation, monitoring, incident and review fields.
Frequently asked
- Does NIST require an AI-agent register?
- No. The NCCoE source is a draft concept paper posing identity and authorization questions, while the AI RMF is voluntary. This template is our proposed way to make many of those questions operational and auditable.
- Should each runtime instance have its own row?
- Usually no. Use one row per logical agent/environment configuration. Create separate rows when production, test, tenant or regional deployments materially differ in identity, privilege, data, model, tools, approvals or evidence.
- Should third-party SaaS agents be included?
- Yes, when they can access organizational data, invoke tools, communicate with other agents or take action on the organization’s behalf. Identify the internal accountable owner even when the vendor builds and hosts the agent.
- Where should credentials be stored?
- Never in this CSV. Record the non-human identity, authentication method, secret-manager or workload-identity reference, rotation/expiry rule and review evidence. Keep credential values in the authorized secrets system.
- Does an “approved” record prove the agent is safe?
- No. Approval records a decision at a point in time. Evidence from evaluations, permissions, runtime traces, incidents and change reviews is what supports that decision.
- How often should records be reviewed?
- Review before release and after material change or incident. Add a risk-based periodic date as a backstop. Higher autonomy, sensitive data, broad tools, persistent memory and harder-to-reverse impacts justify shorter intervals.
Start with one real agent
Download the template, register one pilot, and ask each owner to challenge the boundaries and evidence. If you want a peer review, bring the row—not a slide deck—to an AI Workflow Assessment. We will help identify missing units, privileges, approval points and evidence without requiring a platform purchase.