AI Agent Inventory: Ownership and Authority Schema
Build an AI agent inventory that records accountable owners, models, tools, data, credentials, delegated authority, policies, evidence and lifecycle state.
An AI agent inventory should record what the agent can affect, not only its name, model and owner. Include tools, protected actions, data classes, credentials, delegated authority, policy versions, evidence coverage, dependencies and lifecycle state. This makes the inventory usable for release decisions and incidents.
Agent Trust sets the wider governance boundary. The schema below supplies the inventory spine that lets security, platform and business owners enforce it.
Use stable IDs and explicit owners
type AgentInventoryRecord = {
agentId: string;
displayName: string;
tenantId: string;
businessOwnerId: string;
technicalOwnerId: string;
incidentOwnerId: string;
lifecycle: 'proposed' | 'sandbox' | 'pilot' | 'production' | 'suspended' | 'retired';
modelRefs: Array<{ provider: string; model: string; purpose: string }>;
tools: Array<{ serverId: string; tool: string; riskClass: string }>;
dataClasses: string[];
credentialRefs: string[];
grantIds: string[];
policyDigests: string[];
evidenceProfile: string;
killSwitch: string;
lastReviewedAt: string;
};
Store secret references, never secret values. Keep the agent identity distinct from a deployment instance and workload credential so rotation does not create a new business record.
Derive useful governance queries
The inventory should answer:
- Which production agents can initiate value movement?
- Which agents use a tool whose schema changed this week?
- Which material agents have no active business owner?
- Which grants outlive the agent review date?
- Which agents cannot produce the required evidence profile?
- Which protected services still have a direct route around the gateway?
If the database cannot answer these without spreadsheets and manual interviews, the schema is incomplete.
Validate stale ownership
case: owner-left-organization
given:
business_owner_status: inactive
agent_lifecycle: production
risk_class: material-write
then:
new_authority_grants: blocked
existing_grants: review_or_suspend_by_policy
alert_owner: enterprise-ai-governance
Also test a retired tool, changed model, expired review and missing kill switch. Inventory drift should affect runtime admission for material actions rather than create a dashboard warning only.
Connect inventory to enforcement
An inventory is most reliable when runtime systems consume its stable identifiers. The gateway can deny a suspended agent, quarantine an unreviewed server version and select a policy profile from the action risk class. Keep this integration narrow: the inventory should not become a synchronous dependency for every field if a signed, expiring deployment snapshot can provide the same enforced state.
Record relationships rather than copying mutable facts. A grant reference should point to the authority system. A server reference should point to its admission and provenance record. Copying full objects into several catalogs creates disagreement during revocation and incident response.
Create freshness rules. An owner record may require annual review, while a material tool schema change requires review before the next call. A credential reference should carry a rotation status, not the credential. A production agent with an overdue critical review should move to a defined restriction or suspension state.
Inventory access also needs control. The graph reveals valuable information about privileged tools, data sources and operational dependencies. Separate broad discovery from sensitive credential, policy and incident details, and record access to high-risk views.
NIST's AI Risk Management Framework emphasizes contextual mapping and defined roles. OWASP's Agentic Security Initiative helps expand the tool, identity and supply-chain fields.
Use the governance operating model for role definitions and the governance dashboard for derived measures. Intelliger's Agent Trust layer can be evaluated as an enforcement and evidence source, not as the only system of record.
OATI is a developer preview. Inventory connectors, HR lifecycle integration and production enforcement remain environment-specific implementation work.
Inventory design questions
Is a CMDB enough?
A CMDB can hold services, owners and dependencies, but it may not represent agent purpose, tool semantics, delegated authority, model role, evidence profile or lifecycle. Extend it or link a dedicated registry rather than creating a disconnected spreadsheet. Keep stable cross-system identifiers so incidents can join records.
How are dynamic agents inventoried?
Register the approved template, orchestrator, creation policy and parent authority. Give each material runtime or delegation a stable identifier and expiry. Ephemeral does not mean ungoverned. The inventory can aggregate short-lived instances while preserving the individual transaction and authority evidence needed for investigation.
What is the owner of record?
Use an active enterprise identity or accountable organizational role, not a free-form team name. Record business, technical and incident ownership where they differ. Integrate owner status with identity lifecycle and define reassignment or suspension when a person leaves or a team dissolves.
How should tool risk be recorded?
Classify the business action, data and reversibility, not only the protocol tool name. update_record may be low risk for a draft and material for a supplier destination. Map each tool and resource combination to an action class and required policy profile.
What change should trigger review?
Trigger on new side effects, broader data, changed endpoint or publisher, new credential, changed delegation, owner loss, model role change and material policy update. Store the before-and-after digest and affected tests. A description edit can also matter when it changes how the model selects a tool.
How is inventory accuracy measured?
Discover agents and credentials from runtime, gateway, identity, cloud and domain-system records, then compare with the registry. Track unknown activity, stale records and owner response. Self-registration alone misses shadow deployments; discovery alone lacks accountable intent. Use both.
Reconcile at the action level. A registered agent may use an unregistered service account, and a known service account may be shared by several agent versions. Join gateway traffic and domain writes to agent, workload, grant and owner records. When a link cannot be resolved, keep the operation in an unknown population and restrict material use according to policy. Do not create a plausible owner from repository metadata or the last person who edited a prompt.
Inventory history matters during an incident. Preserve when an owner, tool, model role, policy or credential reference changed. A current snapshot cannot show whether the agent was approved for the action at event time. Keep changes versioned and searchable without retaining secret values or unnecessary model context.
Give every unknown record a route to resolution. Assign it to the service, identity or cloud owner most likely to identify the runtime, set a deadline and define the restriction that applies meanwhile. An unknown label without operating consequences becomes another permanent inventory category.