They should pause expansion of those workloads, classify their runtime role, and map the service account or token each one uses before granting broader access. The immediate goal is containment through visibility and identity mapping, because an undiscovered agent cannot be safely authorised until its actual behavior is understood.
Why This Matters for Security Teams
Unknown AI workloads are a visibility problem first and an access problem second. If runtime discovery surfaces a workload that is already executing, the immediate question is not whether it is “approved” in abstract terms, but what identity it is using, what data it can reach, and whether its tool access matches the task it is actually performing. That is why current guidance around AI governance and runtime control increasingly emphasizes containment, provenance, and least privilege rather than retrospective approval. The SPIFFE workload identity specification is useful here because it frames workload identity as something that should be explicit, attestable, and machine-verifiable.
Security teams often get caught out by assuming that an AI workload can be reviewed like a normal application after deployment. In practice, agentic systems can spawn transient services, call external tools, and exchange tokens in ways that are invisible to standard CMDB or app inventory processes. That makes runtime discovery valuable, but only if it triggers a disciplined response: stop any further privilege expansion, identify the workload’s purpose, and trace the credentials or tokens behind it. In practice, many security teams encounter the real blast radius only after an undisclosed workload has already inherited broad access from the surrounding platform.
How It Works in Practice
The operational response should be staged. First, isolate the workload from non-essential egress and block any new privilege grants while preserving telemetry. That does not always mean termination, especially if the workload supports critical operations, but it does mean freezing entitlement changes until the identity picture is clear. Then classify the workload by function: is it a batch inference job, a retrieval-augmented workflow, an autonomous agent, a model evaluation service, or a temporary orchestration component? That classification determines whether the issue is a shadow deployment, an unmanaged integration, or a risky but legitimate service.
Next, map the workload to the identity artifacts it uses. Look for service accounts, API keys, OAuth tokens, certificates, node identities, and any federated trust path that may allow it to call internal or external systems. This is where identity governance intersects with AI security: a workload is not safe to authorise until its execution authority is understood. NIST’s AI risk guidance and OWASP guidance for LLM applications both support this emphasis on tracing how an AI system behaves, not just what it was intended to do.
- Preserve runtime logs, model prompts, tool calls, and network flows for evidence.
- Inventory the workload’s calling identity and rotate any exposed secrets if provenance is unclear.
- Check whether the workload can read, write, or exfiltrate sensitive data beyond its task scope.
- Require an owner before re-enabling broader access, especially for autonomous agents.
If the workload is part of an AI supply chain, also verify model provenance, container provenance, and whether the runtime image matches the approved build. These controls tend to break down when workloads are dynamically created by orchestration layers, because the identity of the agent, the identity of the service account, and the identity of the human approver are often recorded in different systems and not reconciled in time.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance speed of investigation against service continuity. That tradeoff is especially visible in production AI environments where ephemeral jobs are normal and some level of dynamic provisioning is expected. There is no universal standard for this yet, but best practice is evolving toward treating unknown AI workloads as untrusted until they are classified, attributed, and constrained.
Some edge cases need special handling. A workload discovered in a sandbox or experimentation cluster may be low risk if it is truly isolated, but the same pattern in a production namespace suggests shadow IT or an uncontrolled agent rollout. Likewise, a workload that appears “unknown” to security tooling may still be legitimate if the deployment pipeline lacks identity metadata, which is a governance failure rather than an active compromise. In agentic environments, the most important distinction is between a workload that is merely undocumented and one that is using unapproved authority.
Teams should also be careful not to overcorrect. If an AI service depends on a shared platform identity, immediate revocation can break multiple applications and obscure root cause. The safer approach is to scope restriction to the discovered workload first, then trace dependency chains before changing shared credentials. For deeper technical alignment, the MITRE ATLAS knowledge base helps teams think about how adversaries target AI systems, while the NIST AI Risk Management Framework supports structured governance for classification and oversight.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS and OWASP Agentic AI Top 10 address the attack surface, NIST AI RMF and NIST AI 600-1 set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF supports classifying unknown workloads and managing their risk before authorisation. | |
| MITRE ATLAS | ATLAS helps teams think about how attackers abuse AI runtime behavior and identity paths. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance is relevant when unknown workloads can act autonomously or call tools. | |
| NIST AI 600-1 | GenAI profile guidance supports governance of runtime AI behavior and control mapping. | |
| EU AI Act | The AI Act reinforces accountability, documentation, and oversight for deployed AI systems. |
Validate tool access, output boundaries, and escalation paths before allowing autonomous execution.
Related resources from NHI Mgmt Group
- How should teams govern runtime security for AI systems and cloud workloads?
- How should security teams govern AI agents that can take runtime response actions?
- How should security teams govern AI and workload identities at runtime?
- How should security teams unify IAM for humans, workloads, and AI agents?
