How should enterprises govern both traditional ML and agentic AI on the same infrastructure?

Why This Matters for Security Teams

When traditional ML and agentic ai share the same infrastructure, the risk is no longer limited to model accuracy or data leakage. Teams must also govern tool use, decision autonomy, telemetry, and downstream actions taken by agents. That changes the control problem from simple model hosting to full operational governance across inference, orchestration, and identity-linked access. The NIST AI Risk Management Framework is useful here because it treats AI risk as a lifecycle issue, not a deployment checkbox.

Practitioners often miss the fact that a shared platform can blur responsibility between data science, platform engineering, and security operations. Traditional ML may only need guardrails around training data, model approval, and inference monitoring. Agentic AI adds execution authority, so the same environment now also needs policy over prompts, tool calls, secrets, and action boundaries. That is why governance has to cover both model behaviour and the identity of the system acting on its behalf.

In practice, many security teams encounter this only after an agent has already used legitimate infrastructure access in an unintended way, rather than through intentional governance design.

How It Works in Practice

The most workable pattern is a single control plane with distinct policy layers for model workloads and agent workloads. The infrastructure can be shared, but the governance model should separate what is being controlled: model endpoints, training jobs, retrieval pipelines, agent runtimes, and tool connectors. That lets teams apply one observability stack while still enforcing different risk thresholds for prediction, generation, and action.

For traditional ML, the core controls usually focus on provenance, dataset integrity, versioning, and output validation. For agentic AI, the emphasis shifts to constrained execution, approval gates, session scoping, and tool-level authorization. This is where identity becomes central. An agent should not inherit broad platform permissions simply because it runs in the same cluster as a model service. Instead, each agent needs a bounded identity, short-lived credentials where possible, and explicit allowlists for what it can read, write, call, or trigger.

Security teams should also normalize telemetry across both classes of workload so that governance decisions can be made from one place. Useful signals include:

• Model version and training lineage for ML services
• Prompt, tool, and response logs for agent sessions
• Secret access events and token issuance records
• Policy denials, escalations, and human approvals
• Cost and usage anomalies that may indicate runaway agent behaviour

For threat modeling, the MITRE ATLAS adversarial AI threat matrix and the CSA MAESTRO agentic AI threat modeling framework help teams distinguish classic model attacks from agent-specific abuse paths such as prompt injection, tool hijacking, and chained misuse of legitimate actions. These controls tend to break down when legacy MLOps and agent orchestration are deployed in separate pipelines but still share the same data plane, because accountability and logging become fragmented.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance speed of experimentation against stronger review, audit, and approval gates. That tradeoff is real, especially where product teams want rapid iteration across both ML and agentic AI.

Best practice is evolving around whether one policy engine should govern all AI workloads or whether separate rule sets should exist under one supervisory layer. There is no universal standard for this yet, but current guidance suggests keeping common controls for identity, telemetry, and risk scoring while allowing workload-specific rules for model access, agent autonomy, and human approval thresholds.

Edge cases usually appear in environments with shared secrets, shared service accounts, or multi-tenant clusters. If an ML job and an agent both use the same namespace, a weak boundary can let an agent inherit privileges intended only for batch inference. That is also where agentic security guidance from the OWASP Top 10 for Agentic Applications 2026 becomes especially practical, because it highlights abuse patterns that ordinary model governance does not cover. In higher-risk environments, teams should treat agent identities as first-class security objects and map them to zero standing privilege wherever feasible.

For organisations operating in regulated sectors, the governance model should also align to operational resilience and incident response expectations. That is especially important when AI workloads can trigger business actions, interact with sensitive systems, or create cascading effects across platforms.

Related resources from NHI Mgmt Group

• How should organisations govern agentic AI and NHI access in the same programme?
• What breaks when enterprises try to govern agentic AI with network monitoring only?
• Why do agentic AI systems need different monitoring from traditional ML models?
• What is Agentic AI and how does it differ from traditional generative AI?