Declarative controls inspect static artefacts, so they can find bad configs but not live misuse. AI attacks often happen when a prompt changes agent behaviour, a tool call crosses a privilege boundary, or data moves through an allowed API in an unsafe way. Those signals only exist at runtime.
Why This Matters for Security Teams
Declarative controls are useful for proving what should exist, but they rarely show what an AI system actually did at runtime. That matters because many AI attack paths are behavioural: prompt injection, unsafe tool invocation, data exfiltration through an allowed connector, or policy drift after a model update. These are not always visible in static configuration reviews or compliance checklists.
Security teams often assume that a clean policy file, a hardened prompt template, or a reviewed access matrix means the system is safe. Current guidance suggests that is incomplete. Runtime governance must account for model input, tool selection, retrieval sources, and output handling, especially where an AI agent can trigger actions in other systems. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls helps with control design, but it does not remove the need for behavioural monitoring.
In practice, many security teams encounter AI misuse only after a tool call, data leak, or unauthorized action has already occurred, rather than through intentional runtime detection.
How It Works in Practice
Declarative controls describe the intended state of an AI system. They are effective for questions such as whether a tool is approved, whether a connector is enabled, or whether a model is pinned to a known version. The problem is that AI attacks often emerge between those states: a prompt can redirect an agent, a retrieved document can poison downstream reasoning, or an apparently legitimate API call can become harmful when the context changes.
Operationally, teams need layered controls that observe the interaction chain, not just the configuration baseline. That usually means logging prompts, tool calls, retrieved content, and model outputs; enforcing allowlists for high-risk actions; and correlating AI events with identity, session, and endpoint telemetry. The attack pattern should be mapped in the same way defenders map classic intrusion paths using the MITRE ATT&CK Enterprise Matrix, while AI-specific patterns are better captured through the MITRE ATLAS adversarial AI threat matrix.
- Validate prompts and retrieved context before they reach the model or agent.
- Restrict tool permissions to the minimum needed for the task.
- Monitor for sensitive data in prompts, outputs, and agent memory.
- Correlate model activity with identity, privilege, and change events.
- Re-test controls after model, prompt, connector, or policy changes.
Threat intelligence should also inform detections, because real-world attacker tradecraft changes quickly; CISA advisories and incident reporting can reveal how AI-enabled abuse is being operationalized. The Anthropic report on the first reported AI-orchestrated cyber espionage campaign is a reminder that agentic misuse can look ordinary at the control plane while being dangerous at execution time.
These controls tend to break down in highly dynamic environments where prompts, tools, and data sources change faster than monitoring rules can be updated.
Common Variations and Edge Cases
Tighter runtime control often increases latency, review effort, and engineering overhead, so organisations need to balance detection depth against user experience and operational cost.
There is no universal standard for this yet, especially for agentic systems that can chain multiple actions across SaaS, cloud, and internal APIs. In some environments, declarative controls are still the right first layer for low-risk use cases, while high-impact workflows need runtime policy enforcement, human approval gates, or step-up verification. The right answer depends on the blast radius of the model, not the popularity of the framework.
Edge cases appear when an AI system has indirect access through a service account, when retrieval sources are trusted but stale, or when the “approved” action becomes unsafe because context is manipulated. In those cases, best practice is evolving toward continuous validation rather than one-time signoff. Security leaders should treat AI output as untrusted until it is checked against business rules, identity context, and downstream effect.
For broader operational context, the CISA cyber threat advisories and the lessons in the Anthropic campaign report are useful when deciding where static controls stop and runtime defenses must begin.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS and OWASP Agentic AI Top 10 address the attack surface, NIST AI RMF and NIST AI 600-1 set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF addresses governing risk across the full AI lifecycle, not just static config. | |
| MITRE ATLAS | ATLAS models adversarial AI tactics that bypass static controls at runtime. | |
| OWASP Agentic AI Top 10 | Agentic AI risks center on tool misuse, prompt injection, and unsafe autonomy. | |
| NIST AI 600-1 | GenAI guidance is relevant where model behavior changes at inference time. | |
| EU AI Act | The AI Act requires risk-based governance for higher-impact AI systems. |
Classify AI risk and add monitoring, documentation, and oversight where impact is higher.
