The AI Agent Register: A Cross-Platform Inventory Template for Copilot, Agentforce, and Custom Agents

What the AI Agent Register controls¶

Use the register as the organization’s reconciled list of agent systems and their operating boundaries. Each record connects a stable agent identifier to a business purpose, accountable owners, current release, delegated authority, approval path, evidence, and review state. The register supports four recurring questions: which agents exist, who answers for them, what can they do, and what record proves the answer.

The useful unit is one deployed or deployable agent configuration with a distinct identity or authority boundary. Create separate records when two environments, identities, releases, or business processes carry different permissions or approval rules. Grouping them under one brand name hides the boundary that an access reviewer or incident responder needs.

Include active, pilot, draft, suspended, and retired agents while their records remain relevant. Record copilots that recommend or draft, agents that call tools or APIs, scheduled agent workflows, vendor agents available to employees, and custom orchestrators that can select or sequence actions. Record the system even when classification is uncertain; use the limitations field to preserve the uncertainty.

• In scope: vendor-built agents, employee-built agents, custom agents, embedded agents, agent workflows, and agentic applications with a distinct purpose or authority boundary.
• Separate records: production and test instances with different data, identities, tools, owners, or approval policies.
• Lifecycle states: proposed, draft, pilot, active, suspended, retired, and unknown.
• Open gaps: missing identity, unresolved owner, incomplete tool list, unavailable trace data, and unverified vendor metadata.

Download and start the register¶

The AI Agent Register CSV opens in spreadsheet tools and imports into common governance, asset-management, data, and ticketing systems. The first data row is synthetic and clearly marked EXAMPLE-001. Copy it to learn the expected level of detail, then delete it before publishing your population.

Keep one value per field where possible. Use stable IDs, canonical system names, ISO dates, durable evidence links, and named roles. Record the deployment boundary in environment. Record the role or person who completed the review in reviewed_by, alongside last_reviewed_at. When a value is unknown, write unknown, assign an owner for the gap, and use next_review_due to set a closure date. An empty cell can look complete after a bulk import.

Version 1.0 of the template includes the six required control fields plus discovery, environment, review attestation, identity, release, monitoring, revocation, retention, and claim-boundary fields. Add organization-specific columns after the standard set so future vendor exports and business-unit submissions remain comparable.

The six required control fields¶

A record is review-ready when these six fields contain operational answers. A job title, product name, or policy link may contribute to an answer; it rarely completes one. Name the person or team that operates the control and the exact boundary they own.

Use an operational autonomy scale¶

Autonomy belongs in the register because it changes the control design. Use the five-level scale below as an internal operating shorthand and preserve the plain-language definition beside the level. A level alone cannot describe a complex workflow.

This scale is a governance convention for triage. It carries no legal classification, safety conclusion, or certification. An A1 agent that drafts a consequential decision may require stronger review than an A3 agent performing a reversible maintenance action. Evaluate impact, reversibility, affected people, data sensitivity, and authority with the level.

Record permissions as an authority chain¶

Start with the agent identity: service principal, workload identity, agent user, OAuth client, API key owner, or end-user delegated session. Then name each tool and action, the resource scope, the data boundary, the credential source, the time or purpose constraint, and the policy that allows use. The AI agent permissions guide provides the deeper access-review method.

Keep assigned and observed authority in separate fields. Assigned authority comes from IAM, permission sets, connector configuration, policy repositories, tool manifests, and approval rules. Observed authority comes from executions, traces, API gateway records, database audit logs, message delivery records, and downstream state changes. Differences between the two become review findings.

The register summarizes current authority and points to its sources. IAM, policy, source control, and runtime records retain their own authority. Refresh the summary after a grant, tool, identity, model, prompt, data, deployment, or workflow change.

• Identity: stable ID, identity type, issuer, credential owner, and environment.
• Tool authority: tool or API, allowed actions, resource constraints, and denied actions.
• Data authority: datasets, fields, jurisdictions, sensitivity, retention, and export boundaries.
• Delegation: sponsoring principal, purpose, scope, duration, and revocation path.
• Observed use: trace period, last observed timestamp, actions exercised, and untested grants.

Map systems touched and downstream effects¶

List every system the agent can read, change, notify, or cause another component to change. Include the visible business application and the less visible path through search indexes, vector stores, queues, schedulers, tool servers, gateways, file stores, databases, email, chat, and external APIs.

Record effects at the action level. “CRM access” hides whether the agent reads a case, changes an entitlement, issues a credit, or sends a customer message. The action determines approval, monitoring, evidence, and rollback requirements.

Link cross-agent delegation explicitly. When one agent asks another agent or workflow to act, record both systems and the authority passed between them. The upstream record should identify the delegated action; the downstream record should identify the principal and policy that accepted it.

Write approval rules that can run¶

An approval field needs the action, trigger condition, required approver, response window, and result. “Human in the loop” leaves each part unresolved. Write rules such as: “Refunds above EUR 250 pause before execution; a Customer Operations Team Lead approves or rejects; the request expires after four hours; rejection creates no downstream change.”

Name the human oversight owner for the workflow and the authorized decision roles for each gate. Record what the reviewer sees, which alternatives they can choose, how they stop the workflow, and how overrides are logged. Preserve the decision, rationale, policy version, agent release, input references, timestamps, and downstream result in the evidence location.

Approval protects the action only when the agent cannot bypass the gate. Verify the execution path and test rejection, timeout, revocation, duplicate requests, and downstream failure. A policy statement alone cannot demonstrate enforcement.

Choose evidence locations that survive review¶

Point each record to durable evidence for the named release and period. Useful sources include identity and grant snapshots, approved configuration, policy decisions, approval records, tool-call traces, before-and-after state, incident records, change reviews, access reviews, and retention or deletion results.

Use references that an authorized reviewer can retrieve after the operating team changes. Record the system of record, object or query identifier, retention period, integrity mechanism, access owner, and known collection gaps. A dashboard URL without a stable query or period creates avoidable reconstruction work.

KLA can maintain the operational record in the Agent Registry, connect declared capabilities through the Tool Catalog, route consequential decisions through the Decision Desk, trace effects in the Lineage Explorer, and retain review artifacts in the Evidence Room. Coverage still depends on the systems integrated, evidence collected, and controls configured. The register provides no certification or legal conclusion.

Populate Microsoft Copilot and Agent Builder records¶

Begin with the Power Platform inventory for Copilot Studio and Microsoft 365 Copilot Agent Builder resources built on Power Platform. Export the inventory and map display name, platform ID, environment, creator or owner, publication state, authentication, connectors, connector operations, channels, and capabilities into the common schema.

Reconcile that export with the Microsoft 365 admin-center agent view, Entra identities and grants, deployment records, and execution evidence. Microsoft explains that the two administration surfaces answer different population questions: Power Platform inventory covers agents built on Power Platform, including drafts; the Microsoft 365 view covers agents available to tenant users across a wider set of sources.

Preserve Microsoft’s documented limitations in limitations_and_open_questions. The Copilot Studio inventory schema excludes classic V1 agents, may omit identity fields, reflects published configuration when a newer draft exists, and caps detailed capability resources. Those boundaries make reconciliation part of the control.

• Export Power Platform inventory with stable IDs and environment fields.
• Export or review agents available through the Microsoft 365 admin center.
• Join Entra application or agent identities, grants, owners, and credential controls.
• Resolve connector operations to business actions and data boundaries.
• Compare assigned connectors and grants with recent execution traces.
• Add classic, custom, third-party, draft, and inaccessible records as explicit gaps.

Populate Salesforce Agentforce records¶

Use Setup and Agentforce Studio to list agent definitions and stable IDs. Salesforce documents how to retrieve an Agentforce agent ID, including the BotDefinition object used by current agents. Join each definition to its environment, lifecycle state, topics or actions, data access, deployment, and business purpose.

Record the Agentforce agent user, profile, permission sets, connected-app or API context, and every invoked action. Reconcile administration data with Agentforce DX source metadata, release changes, audit records, and runtime interactions. Source metadata helps identify the declared design; identities, permissions, and traces show the operating boundary.

Keep Salesforce and Microsoft records in the same six-field control schema. Platform-specific IDs and configuration remain valuable, while the normalized fields let an owner review agents across business processes and vendors.

Find custom agents and shadow AI¶

Custom and employee-built agents rarely arrive through one inventory endpoint. Build the candidate population from repositories, deployment platforms, workload identities, API gateways, model-provider accounts, tool and MCP server catalogs, schedulers, queues, secrets managers, observability data, browser or collaboration integrations, procurement, expenses, SSO applications, support tickets, and architecture records.

Search for operating signals: model API calls combined with tool calls, non-human identities calling business systems, scheduled LLM jobs, agent SDK dependencies, tool manifests, agent cards, prompts with action instructions, and recurring approval messages. Validate candidates with the technical and business owners before assigning lifecycle and autonomy.

The shadow AI risk guide covers intake and response for undeclared systems. Keep the initial record even when the owner is unknown. The unresolved owner, identity, permission, and evidence fields define the containment and investigation backlog.

Run a reproducible population cycle¶

A register becomes dependable through reconciliation. Keep the extraction date, source, query or export method, record count, exclusions, joins, duplicate rules, reviewer, and unresolved differences for each cycle.

• 1. Define scope. Name environments, business units, platforms, custom stacks, lifecycle states, and the as-of date.
• 2. Extract. Preserve raw vendor, IAM, repository, procurement, gateway, and runtime source files with timestamps.
• 3. Normalize. Map stable IDs and platform fields into the common template without discarding source IDs.
• 4. Match. Join platform definitions to identities, owners, deployments, tools, systems, policies, and evidence.
• 5. Deduplicate. Keep separate records where environment, authority, approval, or release boundaries differ.
• 6. Verify. Ask business and technical owners to confirm purpose, impact, current state, and unresolved gaps.
• 7. Observe. Compare assigned authority with a defined period of tool calls and downstream effects.
• 8. Remediate. Assign missing owners, excessive grants, absent approvals, unknown systems, and evidence gaps.
• 9. Attest. Record the reviewer in reviewed_by, the date in last_reviewed_at, sources, exceptions, and the next review or change trigger.

Set review cadence and change triggers¶

Choose a risk-based maximum review interval and reopen the record when a material change occurs. High-impact or high-autonomy workflows may need continuous population checks and frequent owner review. Stable draft-only assistants may justify a longer interval.

Use event triggers for owner departure, new environment, model or release change, identity or permission change, new tool or data domain, changed approval threshold, new external communication, policy exception, incident, unexplained behavior, vendor capability change, and retirement. Record the trigger and reviewer response.

Retirement requires a final control pass: disable deployments and schedules, revoke identities and credentials, remove tool grants, preserve required evidence, update dependencies, and assign deletion or retention actions. Keep the retired record discoverable for the applicable evidence period.

Keep EU AI Act duties and register claims precise¶

An internal AI agent register supports governance and may support work performed for the EU AI Act. It is a separate artifact from formal registration in the EU database. Article 71 governs the EU database for specified high-risk AI systems, with role- and system-specific registration data. Confirm any Article 49 or Article 71 duty through the current legal text and qualified counsel.

Article 26 sets duties for deployers of high-risk AI systems. Relevant records can include instructions for use, assigned human oversight, input-data controls, monitoring, logs under the deployer’s control, incident or risk notices, worker information, and cooperation. Applicability depends on the system, role, and facts.

Use article_26_applicability to capture a qualified assessment or review required. The field itself proves no classification or compliance. Follow the Article 26 deployer checklist for the obligation-level review and keep the completed checklist with the register evidence.

Claim boundaries for the completed register¶

Describe the completed result as a reconciled population for the sources, environments, business units, and date tested. State the extraction methods, known blind spots, unresolved records, and percentage of records with verified owners, identities, permissions, approval rules, and retrievable evidence.

Avoid “complete enterprise inventory” unless independent reconciliation supports that exact scope. Vendor exports have documented boundaries. Runtime observation has a time window. Dormant agents may produce no trace. Shared identities can obscure attribution. Employee-built and externally hosted agents may remain outside managed discovery paths.

The template organizes governance work. It supplies no security assurance, conformity assessment, statutory registration, or legal advice. Those conclusions require their own criteria, evidence, testing, and accountable reviewers.