How should security teams govern AI agents when they use open-source models across different workloads?

Security teams should treat model choice as a governance decision, not just an engineering preference. The control plane should enforce identity-aware access, observability, cost controls, and runtime security consistently across agents, while allowing each agent to use the model best suited to its task. That approach reduces ad hoc permissions, improves accountability, and keeps security controls attached to the workload rather than the model brand.

Model choice is a governance decision, not a branding choice

When security teams let every agent pick any open-source model freely, they usually lose consistent control over who can act, what data can be exposed, and how actions are reviewed. The governance problem is not the model name itself, but the combination of workload, permissions, and runtime context. A secure program keeps those controls attached to the agent and its task, not to a particular model family.

That is why workload-based policy matters more than model-based preference. An agent doing low-risk summarisation can use a different model from an agent handling customer data or privileged operations, but both should inherit the same governance model, approval rules, and audit expectations where the risk is equivalent.

Open-source model diversity also creates a hidden control problem: different models may be deployed through different inference endpoints, gateways, or wrappers, which can fragment logging, policy enforcement, and cost visibility. If those paths are not standardised, teams end up governing the model catalog instead of the actual operational boundary that matters.

What should stay consistent across agents, even when models differ?

The minimum control set should be defined at the control plane level. Identity-aware access should determine which agent can call which tools, reach which data, or use which model endpoint. Observability should make every significant action attributable to a workload, a principal, and a task context. Cost controls should constrain runaway usage, but they should not become the only safeguard because they do not address misuse or privilege spread.

A useful policy model is to separate the SPIFFE workload identity specification idea of workload identity from model selection, then bind access decisions to the workload rather than the model brand. That lets teams swap models as capabilities change without reopening authorization design each time.

Security teams should also standardise how agents request and receive permission. The AI Agent Authorisation Guide is useful here because it frames least privilege, task-scoped access, and per-action decisions as the core governance pattern. A model can change, but the permission boundary should remain stable unless the workload itself changes.

How do runtime controls and open-source model risk affect governance?

Open-source models are often attractive because they are flexible, portable, and easier to self-host, but that flexibility shifts responsibility onto the security team. You have to govern the deployment path, the runtime permissions, the telemetry, and the supply chain around the model artifact and its serving stack. The practical question is not whether the model is open source, but whether the workload using it is still governed at runtime.

For agent-heavy environments, this is where threat modelling becomes essential. Agentic AI Security Guide and OWASP Agentic AI Top 10 both reflect the same operational reality: the agent’s identity, tools, and context are usually more important than the model label when judging abuse paths such as tool misuse, identity abuse, or unwanted code execution.

Security teams should also account for discovery and drift. The Shadow AI and AI Agent Discovery Guide is relevant because multi-model sprawl often begins as unsanctioned experimentation, then turns into hidden grants, hidden endpoints, and hidden cost centres. Governance should therefore include inventory, ownership, and lifecycle controls, not only model approval.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST AI RMF	GV.1 — Govern	AI model choice and agent oversight are governance decisions for AI systems.
Recommendation — Establish AI governance roles and policies before allowing varied models across agent workloads.
NIST CSF 2.0	GV.OC-01 — Organizational Context	Different workloads need policy aligned to business context, not model branding.
	PR.AA-01 — Identities and Credentials Are Issued, Managed, Verified, Revoked, and Audited	Agent governance depends on workload identity and lifecycle control for access decisions.
Recommendation — Define the business context and risk posture for each agent workload before approving model use. Issue and audit identities for each agent workload and revoke them when the workload changes or retires.
NIST SP 800-53 Rev 5	IA-9 — Service Identification and Authentication	Agents and model services must authenticate at runtime across workloads and endpoints.
	AC-6 — Least Privilege	Agents need task-scoped permissions regardless of which model they use.
Recommendation — Require strong service authentication for each agent-to-model and agent-to-tool interaction. Limit each agent to the minimum permissions required for its workload and model path.

Practitioner Guidance

What to prioritise: Define a common control plane for identity, logging, policy, and cost before you approve multiple models for agent workloads. If each team can attach a model directly to a production agent without central enforcement, governance will fragment quickly.

Decision rule: If two agents perform materially different work, let them use different open-source models only when the same workload-level controls still apply, including approval thresholds, logging, and access boundaries. If the security posture changes because the model changed, the architecture is too model-centric.

What to verify: Confirm that every agent can be traced to an owner, a workload identity, a policy set, and a runtime log trail. You should be able to answer which agent used which model, against which data, with which tool permissions, and under what exception process.

Common mistake: Treating open-source flexibility as a reason to decentralise governance. That usually produces inconsistent permissions, duplicated review processes, and blind spots in observability, even when the model itself is technically well chosen.

Practitioner takeaway: Govern the agent and its workload first, then allow model diversity only inside that boundary. The goal is not to standardise on one model, it is to standardise the controls that make model choice safe.