How should security teams govern AI agents that were never formally provisioned?

Why This Matters for Security Teams

AI agents that were never formally provisioned often show up first in logs, SaaS audit trails, or production traffic, not in the identity system. That gap matters because an unregistered agent can still read data, invoke tools, chain actions, and create a real blast radius without a clear owner or approval path. Current guidance suggests treating this as an identity and control failure, not merely an inventory problem.

NHIMG research on AI Agents: The New Attack Surface notes that 80% of organisations report AI agents have already acted beyond intended scope, while only 44% have implemented policies to govern them. That combination creates a predictable blind spot: security teams may believe the environment is controlled because directory records are clean, even while agentic workloads are operating outside formal oversight. The most dangerous cases are the ones that look like normal service activity until a data access review or incident response reveals otherwise. In practice, many security teams encounter the governance problem only after an agent has already accessed systems that no one realised it could reach.

How It Works in Practice

Governance starts with runtime discovery. Teams need to identify agents from API calls, workload telemetry, service-account usage, and tool invocation patterns, then map each one to a business owner and a documented purpose. That is why static, role-based IAM is a weak fit: autonomous systems do not behave like human users with stable, predictable access patterns. Instead, authorisation must be evaluated at request time based on what the agent is trying to do, the context of the task, and the system it wants to reach.

Best practice is evolving toward workload identity, short-lived secrets, and policy-as-code. A provably identified agent should present cryptographic workload identity, such as SPIFFE/SPIRE-style identity or short-lived OIDC credentials, then receive just-in-time access only for the specific task. That access should expire automatically and be revoked on completion. This model aligns with the direction outlined in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, both of which emphasise context, accountability, and controlled behaviour over static trust.

• Discover unknown agents from logs, tokens, orchestration traces, and tool-use telemetry.
• Assign a human owner, purpose, and data boundary before granting durable access.
• Use short-lived credentials and runtime policy decisions instead of permanent entitlements.
• Log every tool call, dataset access, and downstream action for auditability.

NHIMG’s NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforce the same operational principle: if identity cannot be provisioned normally, it still must be governed as if it were. These controls tend to break down when agents are embedded in vendor-managed platforms or shadow IT automations because the organisation cannot reliably intercept issuance, rotation, and revocation events.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance automation speed against investigation quality and approval friction. That tradeoff is especially visible in multi-agent workflows, where one agent may delegate to another or spawn tool-specific sub-agents. There is no universal standard for this yet, so current guidance suggests using the minimum policy structure needed to preserve traceability without blocking legitimate execution.

One common edge case is a service account that appears to belong to a traditional application but is actually driven by an LLM orchestration layer. Another is an agent launched by a developer workstation, CI pipeline, or low-code platform, where the identity is indirect and the real control point is the workload token rather than the user account. In those environments, teams should combine behavioural baselines, network restrictions, and explicit allowlists for tools and data domains. The CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix are useful references when the agent can chain actions or adapt its route to a goal.

NHIMG research on Ultimate Guide to NHIs — Regulatory and Audit Perspectives is a reminder that audit teams will still ask the same question after the fact: who owned it, what was it allowed to do, and when was access removed? In environments with outsourced automation, shared tenants, or rapidly changing toolchains, those answers are hardest to reconstruct after the agent has already moved on.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that use OAuth access?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams manage permissions for AI agents?