How do organisations decide whether AI security should focus on protecting AI systems or using AI to secure software?

They should do both, because the risk runs in two directions. AI systems introduce new attack surface through models, agents, and connectors, while AI can also improve triage, remediation, and runtime defence. The practical test is whether controls cover both the AI stack and the delivery pipeline without creating unmanaged autonomy.

Why This Matters for Security Teams

Organisations are not choosing between two unrelated problems. They are deciding whether AI is being treated as a new attack surface, a force multiplier for defence, or both. The first risk set includes model endpoints, agent tool use, prompt injection, secret leakage, and unsafe integrations. The second includes faster detection, triage, and remediation across software delivery. NIST Cybersecurity Framework 2.0 treats this as a governance and risk question, not a tooling slogan.

The practical mistake is to fund AI security only as model hardening, while leaving software pipelines, secrets, and access paths unchanged. NHIMG research shows that credential weakness remains central to real-world compromise, and incidents such as the JetBrains GitHub plugin token exposure and the Hard-Coded Secrets in VSCode Extensions case show how quickly AI-adjacent workflows can amplify ordinary credential mistakes. In the State of Non-Human Identity Security, only 1.5 out of 10 organisations were highly confident in securing NHIs, which is a warning sign for any AI program that depends on service accounts, tokens, or agents.

In practice, many security teams discover the gap only after an AI workflow has already touched secrets, code, or production access rather than through intentional governance.

How It Works in Practice

The decision usually starts with mapping where AI sits in the control plane. If the AI system is exposed to users, data, or tools, then the priority is to protect the AI stack itself: prompts, model routing, retrieval layers, connectors, and workload identity. If AI is being used inside security operations or software delivery, the priority is also to make AI a defensive capability that can reduce alert fatigue, speed investigation, and improve code review. Current guidance suggests treating these as linked controls, not separate programs.

For AI systems, organisations should focus on authenticated workload identity, short-lived credentials, runtime policy evaluation, and guardrails around tool execution. That means moving away from static role assumptions and toward context-aware authorisation, where the system checks what the agent is trying to do at the moment of request. Standards discussions such as the CSA MAESTRO agentic AI threat modeling framework and NIST Cybersecurity Framework 2.0 both support this operational split: govern the AI itself while also strengthening the surrounding environment.

For AI as a defensive layer, the question is whether the organisation can safely automate triage and remediation without creating unmanaged autonomy. In practical terms, that means limiting what the AI can execute, requiring approval for high-risk actions, and logging every decision path.

• Use workload identity for agents and services so access is tied to cryptographic proof, not long-lived secrets.
• Issue just-in-time credentials with short time-to-live values and automatic revocation after task completion.
• Evaluate policy at request time using current context, not only pre-defined role mappings.
• Restrict AI defenders to bounded actions such as ticketing, enrichment, or scoped remediation.

This guidance tends to break down in highly integrated environments where agents can chain multiple tools across identity, code, and cloud platforms because the blast radius becomes difficult to predict.

Common Variations and Edge Cases

Tighter AI control often increases operational overhead, requiring organisations to balance faster defence against stronger containment. That tradeoff is most visible in environments that want AI to make decisions in production or to remediate findings automatically. Best practice is evolving, and there is no universal standard for how much autonomy is acceptable in security operations.

One common variation is to protect the AI system first when the model has direct access to proprietary data, secrets, or production APIs. Another is to prioritise AI-for-security first when the organisation has a mature engineering and detection stack but limited staffing. The right answer depends on whether the highest risk is malicious manipulation of the AI, or under-resourced defence in software operations. The former calls for stronger prompt, connector, and agent controls. The latter calls for AI-assisted triage, code scanning, and alert reduction.

Edge cases include vendor-hosted copilots, agentic workflows that span multiple business units, and environments with many third-party OAuth connections. NHIMG research on the State of Non-Human Identity Security shows why this matters: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. That same visibility gap can affect both sides of the question, because the AI tool may be the thing to secure or the thing doing the securing. For broader secret-risk context, the State of Secrets in AppSec also highlights how fragmented secrets management undermines both AI defence and AI containment.

Related resources from NHI Mgmt Group

• How should organisations decide whether to buy AI security tools through procurement channels?
• How can organisations decide whether their AI security workflow is mature enough?
• How do organisations decide whether to standardise on one agentic AI security control model?
• How should security teams decide whether a cheaper AI model is worth using for cyber work?