How should security leaders structure an AI security programme when offensive and defensive tactics are changing at the same time?

Security leaders should treat AI security as a programme, not a point solution. Start by mapping where AI changes attack paths, where it improves detection or response, and which workflows need redesign. Then align governance, technical controls, and operational playbooks so teams can test new approaches, measure outcomes, and update controls as threat patterns and tooling evolve.

Build the programme around changing attack paths, not around a single model or tool

An effective AI security programme starts with the attack surface, not the hype cycle. Leaders need to map where AI changes credential abuse, prompt or tool abuse, data exposure, automated reconnaissance, and the speed of exploitation, then define which risks are new, which are amplified, and which are simply more visible.

That mapping should also cover defensive uses of AI, because better detection, triage, and response can reduce dwell time even as offensive capability improves. The programme should therefore be organised around use cases, control objectives, and operating assumptions, not around whether the organisation has adopted one particular platform or model.

For AI systems that expose attack paths through tool use or delegated action, align the programme to adversary behaviour and defensive countermeasures using MITRE ATT&CK Enterprise Matrix and MITRE D3FEND. If the AI workload itself is the subject of threat modelling, CSA MAESTRO agentic AI threat modeling framework provides a more specific structure for autonomy, orchestration, and tool-access risk.

Use governance, controls, and operations as one control loop

The programme works when policy, architecture, and operations reinforce each other. Governance should define approved AI use cases, risk appetite, human approval thresholds, and escalation paths, while technical controls constrain data access, tool invocation, logging, and change management. Operations then turn those decisions into playbooks, detection logic, and testing routines.

This matters because AI security failures often arise at the seams: a model is approved, but the surrounding workflow is not, or a control exists, but no one has decided who can override it. Security leaders should treat review, monitoring, and exception handling as part of the system design, not as post-deployment administration.

For broader security control structure, use NIST SP 800-53 Rev 5 Security and Privacy Controls for governance, auditability, and access-control discipline, and NIST Cybersecurity Framework 2.0 for organising the programme across govern, identify, protect, detect, respond, and recover. If the implementation is cloud-heavy, CSA Cloud Controls Matrix is useful for aligning AI work with cloud, IAM, and supply-chain control domains.

Design for continuous change, then test whether the controls still work

AI programmes become fragile when they assume the current threat pattern will remain stable. Offensive techniques, model behaviour, vendor features, and defensive tooling all move quickly, so the real objective is to build an update loop: reassess risks, validate controls, and revise playbooks on a fixed cadence or when material changes occur.

Practically, that means testing new attack paths, measuring whether detections still trigger, and checking whether response teams can contain AI-related incidents using current procedures. Leaders should expect some controls to age out faster than others, especially where AI is embedded into developer workflows, customer-facing systems, or autonomous tooling.

For incident and resilience planning, pair the programme with CISA cyber threat advisories and ENISA Threat Landscape to keep threat assumptions current. Where AI systems depend on secrets, credentials, or external integrations, NHIMG’s Ultimate Guide to Non-Human Identities is a useful reference point for governance, visibility, rotation, and privilege discipline, and the related State of Secrets in AppSec highlights how quickly exposed secrets turn into operational exposure.

Risk and Threat Considerations

AI security programmes fail when leaders treat AI as a single control problem instead of a shifting combination of attack paths, workflow dependencies, and response demands. The risk is not only direct compromise of AI systems, but also faster abuse of surrounding systems, weaker trust in automated decisions, and blind spots when defenders assume yesterday’s control still covers today’s threat.

Failure mechanism: Attackers and defenders both iterate quickly, so the organisation’s assumptions about data access, tool permissions, logging, and human review can become outdated faster than the control environment is refreshed. That creates gaps between approved design and actual operation.

Impact: The result is higher likelihood of misuse, delayed detection, poor containment, and inconsistent governance across teams that build, use, or monitor AI-enabled workflows.

Standards & Framework Alignment

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

MITRE ATT&CK and CSA MAESTRO address the attack surface, NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
MITRE ATT&CK	Tactic/Technique Mapping — Adversary Tactics and Techniques	AI security programmes must map changing attack paths and abuse techniques.
Recommendation — Map AI-related attack paths to ATT&CK techniques and update detections as tactics evolve.
NIST CSF 2.0	GV.AM — Asset Management	AI programmes need inventory of models, workflows, tools, and dependencies to manage exposure.
	GV.RM — Risk Management Strategy	The question is about structuring a programme around evolving offensive and defensive risk.
	DE.AE — Anomalies and Events	AI security programmes need detection tuned to new misuse and abuse patterns.
Recommendation — Inventory AI systems and dependencies so governance decisions reflect actual attack surface. Set an AI risk strategy that is reviewed and updated as threats and tooling change. Tune detections for AI abuse patterns and refresh them when behaviour shifts.
NIST SP 800-63	IAL/AAL/FAL — Identity Assurance, Authenticator Assurance, Federation Assurance	AI workflows often depend on delegated access and authentication strength.
Recommendation — Apply appropriate assurance levels to protect AI-administered access and federation flows.
CIS Controls v8	6 — Access Control Management	AI programmes require least privilege, approvals, and review for tool and data access.
	8 — Audit Log Management	Continuous validation depends on logs that show what AI systems did and why.
Recommendation — Restrict AI-linked access paths to the minimum required privilege and review them regularly. Centralise and retain AI activity logs so control effectiveness can be measured.
CSA MAESTRO	A1 — Agentic Risk Assessment	Agentic AI changes attack and defence dynamics through autonomy and tool use.
Recommendation — Assess autonomous AI use cases for tool-use, orchestration, and delegation risks.

Practitioner Guidance

What to prioritise: Start with the few AI workflows that can create the largest blast radius, typically those with production data, external tools, or automated action authority. Those are the places where weak governance and weak telemetry become material fastest.

What to verify: Confirm that each high-risk AI use case has an owner, a defined approval threshold, logging that is actually reviewable, and a tested rollback or containment path. If any of those are missing, the programme is still a draft, not a control system.

Common mistake: Teams often overinvest in model evaluation and underinvest in operational control. For this question, the decisive issue is whether the organisation can keep pace with changing offence and defence, not whether it has a single impressive policy document.

Practitioner takeaway: The strongest AI security programmes are adaptive control systems, they continuously remeasure risk, revalidate controls, and reassign ownership as both attack techniques and defensive capabilities evolve.