What breaks when organisations rely only on provisioning records for AI agents?

What breaks is the assumption that the official catalog reflects the real attack surface. Shadow AI, unofficial integrations, and unmanaged agents can operate outside formal workflows, so they never appear in the normal inventory. If discovery stops at provisioning, security teams will undercount active identities and miss the ones most likely to be overlooked.

Why This Matters for Security Teams

Provisioning records are useful for change control, but they are not a reliable security inventory for AI agents. Agents can be created through automation, embedded in workflows, or spun up for a single task without ever being cleanly reflected in a central catalog. That creates blind spots in discovery, ownership, and revocation, which is exactly where attackers look for unmanaged access paths. Guidance from the NIST AI Risk Management Framework and NHIMG research on the OWASP NHI Top 10 both point to the same operational problem: if identity governance starts and ends with provisioning, it will miss the identities that matter most.

This becomes more severe when AI agents hold secrets, invoke tools, or chain actions across multiple systems. A provisioned record may show that an agent exists, but not whether it is still active, what it can reach, or whether a shadow integration has bypassed approval entirely. In practice, many security teams encounter privilege exposure only after an agent has already been used as a pivot point rather than through intentional discovery.

How It Works in Practice

Provisioning records answer a narrow question: what was formally issued? Security teams also need to answer what is actually running, what is still authenticating, and what has quietly drifted out of governance. For AI agents, that means combining provisioning data with runtime telemetry, workload identity, and secrets usage signals. Current guidance suggests treating the agent’s workload identity as the authoritative primitive, not the ticket or catalog entry. Standards such as the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework emphasize that agents are dynamic workloads, so access decisions must be evaluated in context, at request time.

In practical terms, that means:

• Discovering agents from runtime signals, not only provisioning workflows.
• Mapping each agent to a workload identity and the secrets or tokens it can use.
• Using short-lived credentials and JIT access so standing access does not outlive the task.
• Rechecking tool access when the agent changes scope, model, or execution path.
• Revoking or isolating identities that are active but have no current owner.

NHIMG research on the NHI Lifecycle Management Guide shows why lifecycle control matters here: identity state changes faster than most administrative records do, especially in agentic environments. Provisioning is only the beginning of the control plane, not the proof that the identity is governed. These controls tend to break down when agents are instantiated by CI/CD, orchestration layers, or user-facing copilots because the operational path that creates access is different from the path that records it.

Common Variations and Edge Cases

Tighter discovery often increases operational overhead, requiring organisations to balance visibility against agent sprawl and faster deployment cycles. That tradeoff is real, especially where teams rely on ephemeral agents, third-party copilots, or multiple model runtimes. There is no universal standard for this yet, but current practice is moving toward continuous discovery and policy-as-code rather than periodic inventory reconciliation.

shadow ai and unofficial integrations are the hardest cases because they may never touch the formal provisioning system at all. A workflow can create an agent, attach a token, and start calling APIs before any governance record is updated. NHIMG analysis in AI LLM hijack breach and the Moltbook AI agent keys breach illustrates the risk of unmanaged keys and agent sprawl: the security issue is not just that the record is missing, but that the live control path is missing too.

Where organisations need a hard operational rule, the safest one is simple: if an agent can authenticate, invoke tools, or persist secrets outside the provisioning record, it should be treated as an active identity until proven otherwise. This is especially important for environments with decentralized development, delegated admin rights, or fast-moving LLM integrations, because those conditions create the most persistent inventory gaps.

Related resources from NHI Mgmt Group

• What breaks when organisations deploy AI agents without lifecycle governance?
• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?
• How should teams govern AI agents that rely on business context from data platforms?