AI Agent Inventory Template: Track Owners, Access, and Risk

What is an AI agent inventory template?

An AI agent inventory template records deployed AI agents, their accountable owners, approved purposes, permissions, data access, risk classifications, and shutdown procedures, following the scope described in Kosmoy’s registry guide. A useful record answers three operating questions: who answers for this agent, what can it read or change, and how does an authorized responder stop it? A list of agent names is not enough.

Copy these columns into your inventory

Start with one record per deployment. Split records when environments, owners, or permissions differ to keep production permissions distinct from test permissions. Kosmoy’s registry guide identifies ownership, approved use cases, models, tools, data access, containment, shutdown, and logs as core information. The proposed template below adds credentials, dependencies, fallback procedures, and review dates as operational guidance.

Keep sensitive evidence out of spreadsheet cells. Link to restricted test reports, deployment manifests, and operating instructions in their controlled locations. Use the inventory as the index, not a second storage location for secrets or documents that require tighter access.

A completed example record

The record below is hypothetical. Names, systems, model labels, dates, risk tier, and retention period show how to complete the fields. They are not a recommended policy or a description of a real deployment.

Who should own each agent, and how should risk change its controls?

Name a business owner with authority to approve the agent’s purpose, accept its operating risk, and authorize changes or suspension. Record the technical responder separately. Use the risk classification to specify testing, human oversight, monitoring, and evidence requirements. If the label changes none of those decisions, reconsider its purpose.

Instead of listing “Operations” or “IT” as the accountable owner, name a person, record their role, and update the entry when responsibility moves. Assign the business owner responsibility for deciding what behavior is acceptable. Assign the technical contact responsibility for maintaining the deployment and carrying out the technical response when that behavior goes wrong.

Use a rationale, not just a risk score

Assess confidentiality, action authority, potential harm, and reversibility together. Compare the sensitivity of read access with the consequences of write access rather than treating either as an automatic risk tier. Do not let the presence or absence of write access decide the tier by itself. Record why the classification fits this deployment.

• Testing: name the behaviors that must pass before release and after material changes.
• Oversight: identify the actions that require approval and the person who reviews exceptions.
• Evidence: locate the test results, approvals, and operating records needed to explain decisions.

Document that reasoning in an AI agent risk assessment. Summarize the decision in the inventory and link to its evidence. Avoid maintaining a second assessment inside the spreadsheet; keep one authoritative assessment for reviewers to update.

How should you record access and shutdown controls?

Record effective permissions by system, operation, and data boundary. Following Kosmoy’s registry guide, separate systems the agent reads from those it writes, and specify shutdown steps and the authorized responder. Reference the credential and service identity without storing secrets. Also explain pending-work handling and manual fallback rather than leaving the instruction at “Contact IT.”

Describe operations, not vague connections

Replace vague descriptions such as “Connected to finance” with verifiable operations, such as “Reads invoices for the assigned business unit; creates review drafts; cannot alter bank details.” Specify restrictions on records, fields, environments, and transaction limits wherever they apply. Ask the system owner to compare the entry with configured permissions.

Record permission and autonomy separately: list the underlying write permissions alongside any requirement for human approval before a write. Verify where the approval requirement is enforced using an agent access control checklist. Include downstream agents and tools in the check rather than treating the first connection as the complete access boundary.

Make the stopping procedure executable

Kosmoy’s registry guide calls for exact shutdown steps and the role authorized to perform them. State whether the responder must disable scheduling, revoke credentials, stop workers, or block invocation. Then verify the sequence in the deployed environment. Do not mark shutdown as ready because someone knows where the pause button is.

Plan for completed writes and pending work as well as stopping future execution. Link the inventory record to an agent incident response plan that assigns reconciliation, investigation, and restart decisions. Name the person responsible for the business task while the agent is stopped, along with the manual process they will use.

A useful inventory tells the responder who owns the agent, what it can change, and how to stop it.

How do you populate and maintain the inventory?

Gather deployments across platforms, match them to approved use cases, and verify each agent’s owner, access, and stopping procedure. Assign review dates under internal risk policy, but update records when deployments change rather than waiting for the calendar. Treat an unverified field as an open task, not evidence that a control exists.

1. Gather deployed agents. Ask platform administrators and business teams for deployments, scheduled runs, service identities, and agent-to-agent dependencies. Include paused deployments that still have access. Record the discovery scope so the next reviewer can see which platforms and teams were checked.
2. Reconcile approved purposes. Match every deployment to an authorized use case and accountable owner. Flag unmatched deployments for investigation. Finding an agent in production does not approve its presence there; keep discovery and authorization as separate decisions.
3. Verify effective access. Compare inventory entries with configured tool permissions and credential scopes. Confirm read and write boundaries with the system owner, including downstream access and environment restrictions. Record the permissions that exist, not just the permissions requested.
4. Check containment and fallback. Have an authorized responder verify shutdown instructions and pending-work handling. Ask the business owner to confirm the manual replacement process. Identify where the responder can find operating evidence without having to search during an incident.
5. Capture a versioned baseline. Record the deployment release, model version, permissions, evidence links, and verification date. Preserve change history so reviewers can reconstruct the previous operating state instead of seeing only the latest spreadsheet entry.
6. Review changes and exceptions. Update the record after changes to ownership, model, tools, permissions, or purpose. Set the next review under internal policy. Investigate differences between the approved record and deployed behavior rather than editing the record to make the discrepancy disappear.

Check for differences between the approved record and the deployment rather than expecting a manually maintained spreadsheet to detect changes. Connect agent monitoring to the inventory through stable agent identifiers, named exception owners, and links to operating evidence. Give reviewers a path from an alert to the responsible person and deployment.

How does an agent inventory differ from other registries?

Kosmoy’s registry guide distinguishes agent records from a broader AI-system inventory and from model registries. The agent record covers ownership and operation; the broader inventory includes non-agent AI systems; model registries track model versions and lineage. A Survey of AI Agent Registry Solutions examines discovery approaches for finding and connecting to capabilities. Keep these purposes distinct when organizing your records.

TrueFoundry’s registry guide describes agent cards with identification, version, endpoint, and capability metadata. You can keep agent and model records in an AI-system inventory spreadsheet. Label the record type explicitly, though: do not use a model identifier as a substitute for identifying an accountable agent deployment.

Where MCP, Agent Cards, and AgentFacts fit

A Survey of AI Agent Registry Solutions examines discovery approaches including Model Context Protocol, or MCP, metadata; Agent-to-Agent, or A2A, Agent Cards; and NANDA AgentFacts. These describe interfaces, capabilities, and discovery information. Use them alongside governance records, not instead of them. Check business ownership, approved purpose, and shutdown readiness separately from connection metadata.

When a spreadsheet stops being enough

Move beyond manual records when your process cannot reliably maintain discovery, deployment tracking, drift detection, versioning, or health monitoring. Evaluate each requirement separately, including registration and invocation controls, which TrueFoundry discusses in its registry guide. Check catalog search and access enforcement separately rather than treating one as proof of the other.

How Cogniver helps teams keep workflow agents accountable

Cogniver gives every workflow its own isolated AI agent. Conversation memory stays separate across workflows and companies, and org admins train each agent on that workflow’s rules and configuration. The agent answers questions, routes requests, and chases approvers within that defined workflow context.

Use the visual builder to create purchase, leave, and document approval paths with branches and multi-step approval chains. AI Routers read form and uploaded-document values to select exactly one branch. Each router requires a default branch, so an uncertain request follows a defined path instead of a guessed decision.

Place human decisions at explicit approval steps. Approvers can enter verified values that determine later routing; copilot-proposed actions require a person to execute them. Document those rules alongside your inventory’s named owner, approved purpose, and review dates so the record describes how the workflow actually operates.