How should security teams govern AI use when the same model creates different risk in different contexts?

Why This Matters for Security Teams

The same model can be low risk in one workflow and unacceptable in another because context changes the blast radius: who is invoking it, what data it can touch, and what downstream action it can trigger. That is why governance has to move beyond model approval and into runtime control of Top 10 NHI Issues such as over-privilege, weak monitoring, and poor secret hygiene. Current guidance also aligns with the NIST Cybersecurity Framework 2.0 emphasis on continuous risk-based outcomes rather than static trust. For AI agents and other autonomous workloads, this becomes even more important because behaviour is goal-driven, not pre-scripted.

Security teams often get this wrong by assigning one blanket policy to a model or by equating model safety with operational safety. That fails when the same API call is harmless in a drafting tool but dangerous in a finance workflow, or when an agent can chain tools, retrieve secrets, and act on behalf of a privileged workload. The practical question is not whether the model is “allowed,” but whether the specific request is authorised for this identity, this purpose, and this data class.

In practice, many security teams encounter privilege misuse only after an autonomous workload has already crossed a contextual boundary, rather than through intentional governance design.

How It Works in Practice

Effective governance starts with classifying each AI request at runtime. Security controls should evaluate the invoking identity, the declared intent, the target system, and the sensitivity of the data involved before granting access. That means moving from coarse RBAC toward intent-based authorisation, where the policy engine decides whether the request is acceptable in the current business context. For autonomous systems, that often includes workload identity, short-lived credentials, and per-task secrets rather than standing access.

Practitioners should treat policy as code and enforce it at request time, not only during onboarding. A workflow that drafts marketing copy may be permitted to use a foundation model, while the same model driving an agent that can approve payments or retrieve customer records needs tighter gates, stronger logging, and JIT credential issuance. This is consistent with the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which frames identity lifecycle discipline as a control plane problem, not a one-time setup task. It also maps cleanly to NIST Cybersecurity Framework 2.0 categories around protect, detect, and respond.

• Issue JIT credentials with tight TTLs for a single task or session.
• Use workload identity as the primary proof of what the agent is.
• Attach policy decisions to data classification and business purpose.
• Log the full chain of action for review, revocation, and audit.

For teams building agentic controls, the relevant design patterns are also covered in OWASP NHI Top 10 and the emerging CSA MAESTRO guidance, both of which treat autonomous behaviour as a security boundary. These controls tend to break down in multi-tenant environments where a single runtime can switch users, tools, and data scopes faster than the policy layer can re-evaluate context.

Common Variations and Edge Cases

Tighter runtime control often increases latency and operational overhead, so organisations have to balance strong contextual checks against usability and automation speed. There is no universal standard for this yet, but current guidance suggests using a tiered model: low-risk requests can pass with lightweight checks, while high-impact actions require stronger approvals, more logging, or human-in-the-loop review.

Some edge cases need special handling. Shared models embedded in SaaS tools may not expose enough telemetry for fine-grained decisions, which makes runtime authorisation hard to enforce. Long-lived service accounts are another weak point because they outlast the context that justified them. In those environments, Ultimate Guide to NHIs — Regulatory and Audit Perspectives becomes especially relevant, because auditors will ask not only who approved the model, but who controlled the identity, data, and secret scope at the time of use.

The same logic applies to compromised secrets and exposed workloads. NHIs are often the real failure point, not the model itself, and the DeepSeek breach is a reminder that secrets leakage and exposed records can turn an AI deployment into a broader identity problem. In practice, the hard part is not deciding that context matters. It is proving that the policy engine, identity plane, and secret lifecycle all move quickly enough to match the context.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern AI agents that use Model Context Protocol?
• How should security teams govern Cursor-like AI coding tools in the enterprise?
• How should security teams govern AI agent context windows?