What is the difference between securing AI at development time and protecting it at runtime?

Development-time security focuses on finding weaknesses before deployment, such as unsafe prompts, poisoned datasets, and misconfigurations in the build pipeline. Runtime protection focuses on active defense while the model is serving users, including inspection of inputs, enforcement of policy, and blocking harmful actions. Both are necessary because threats exist before launch and during live use.

Why Development-Time and Runtime Defences Solve Different AI Problems

Securing AI at development time is about reducing the chance that a flawed model, unsafe prompt path, poisoned training asset, or insecure build step ever reaches users. Runtime protection is about containing whatever still slips through once the system is live, when inputs are unpredictable and the model can be pushed into unsafe behaviour by real traffic. That distinction matters because a control that looks strong in the lab may still fail under adversarial use, while runtime filters cannot reliably compensate for a compromised supply chain or a poorly governed model build process.

For teams formalising their AI security programme, the practical lesson is to treat these as complementary control layers rather than interchangeable options. NIST Cybersecurity Framework 2.0 is useful here because it reinforces that governance, protection, detection, response, and recovery all need to work together across the system lifecycle, not only after deployment. In practice, many teams discover the gap only after a model has already been exposed to users, rather than by testing how build-time assumptions behave under live abuse.

How the Two Control Layers Work in Practice

Development-time security is the discipline of making the AI artefact safer before it is published. That usually means reviewing datasets, training artefacts, evaluation prompts, tool integrations, model cards, and pipeline permissions for weaknesses that can become security failures later. It also includes checking whether the model was trained or tuned on untrusted material, whether output constraints were validated, and whether release criteria are strong enough to catch unsafe behaviour before production. The goal is not perfection, but reducing the number of avoidable defects that runtime controls must absorb.

Runtime protection sits one layer closer to the user and the adversary. It inspects live prompts, enforces policy on tool use, constrains outputs, monitors anomalous behaviour, and blocks or delays actions when the model is asked to cross a trust boundary. In practice, this can include input validation, content filtering, rate controls, step-up approval for high-impact actions, and logging that supports detection and investigation. Runtime controls are essential because attackers do not interact with the model as a static artifact. They probe it, adapt to it, and try to exploit the exact conditions that development testing did not anticipate.

Development-time work answers, “What defects are we shipping?”
Runtime protection answers, “What do we do when the live system is tested by hostile or messy reality?”
Strong programmes connect the two through release gates, monitoring feedback, and rollback criteria.

The most reliable operating model is to define which failures must be prevented before deployment and which must be detected or contained after deployment. Where teams blur that line, they usually overtrust pre-release testing or overburden production filters. The guidance breaks down when the AI system is tightly coupled to external tools and business actions, because then a weak release review and a weak runtime guardrail fail together.

Where the Boundary Blurs in Real Deployments

Tighter AI controls often increase latency, operational overhead, and review burden, so organisations have to balance faster release cycles against stronger assurance. That tradeoff becomes visible when a model update changes prompt behaviour, tool invocation patterns, or output style without a corresponding security review.

One common edge case is a system that appears to be a development-time issue but actually behaves like a runtime one because the risk is created by live context. Prompt injection, for example, may be discovered in testing, but its real impact depends on how the deployed model handles untrusted user input and downstream actions. Another edge case is model drift: a model that passed pre-launch checks can become less safe after configuration changes, tool additions, or policy updates. In those cases, the operational question is not whether development-time security was done, but whether runtime protection can detect when the system has moved outside its approved envelope.

There is also a consensus gap in the industry about how much runtime filtering can compensate for weak upstream controls. Our view is that it cannot, because runtime protection is a containment layer, not a substitute for secure development. The same is true in reverse: strong build-time assurance does not remove the need for live monitoring, because adversarial use only emerges after the system is exposed. The boundary matters most where the model can trigger external actions, because then a missed control can turn a text response into an operational incident.

Standards & Framework Alignment

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

MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST AI RMF	GOVERN — Govern	Covers AI risk governance across the full lifecycle, including build and live operation.
Recommendation — Define lifecycle AI risk ownership and release gates for both pre-deployment assurance and runtime control.
NIST CSF 2.0	GV — Govern	The question is about lifecycle security governance and control separation.
Recommendation — Align development and runtime AI controls to lifecycle governance, then assign clear accountability.
CIS Controls v8	16 — Application Software Security	Applies to secure build, testing, and release practices for AI-enabled software.
	8 — Audit Log Management	Runtime protection depends on monitoring and evidence for live AI behaviour.
Recommendation — Embed security testing and release checks into the AI development pipeline before deployment. Collect and review runtime logs to detect unsafe AI inputs, outputs, and actions.
MITRE ATLAS	AML.TA0001 — Reconnaissance	Adversarial AI testing and probing at runtime maps to attacker discovery behaviour.
Recommendation — Hunt for probing patterns that show an adversary is testing the model’s runtime defences.

Practitioner Guidance

What to prioritise: Separate pre-deployment assurance from live containment in your control design, and assign explicit owners for each. Development teams should own dataset hygiene, secure build pipelines, evaluation gates, and release approval, while platform or security teams should own input controls, policy enforcement, monitoring, and escalation paths.

What to verify: Check that the runtime layer is not quietly expected to compensate for known build-time weaknesses. If the same unsafe behaviour appears in offline testing and live traffic, treat it as a release-quality failure first and a filtering problem second.

What good looks like: A mature programme can show which risks are removed before deployment, which are tolerated but constrained in production, and which conditions trigger rollback, human review, or emergency disablement.

Practitioner takeaway: The key judgement is to stop treating AI safety as a single control problem, because secure development reduces what enters production and runtime protection limits the damage from what still gets through.