Topic starter
09/07/2026 12:35 pm
TL;DR: The article argues that AI safety concerns harmful behavior from a system functioning as intended, while AI security concerns adversaries subverting AI through prompt injection, data poisoning, compromised coding assistants, and malicious MCP servers, according to Knostic. The distinction matters because enterprises need separate ownership, controls, and readiness criteria for harm, attack, and privacy failure paths.
Editorial analysis by NHI Mgmt Group, based on content published by Knostic: “AI Safety vs. AI Security: Explaining the Differences”.
Key questions
Q: How should security teams separate AI safety failures from AI security failures?
A: Treat safety as a question of whether the system’s intended behaviour is acceptable, and security as a question of whether an attacker can redirect that behaviour.
Q: Why do AI coding assistants increase AppSec governance risk?
A: They increase risk because they optimise for speed and plausible output, not for context-aware security validation.
Q: What breaks when AI security is treated only as model security?
A: Model-only security misses the part of the system that actually touches tools, data, and workflows in production.
Practitioner guidance
- Separate safety sign-off from security sign-off Create distinct approval criteria for harmful intended behaviour and adversarial compromise, then assign each to a named owner before production use.
- Inventory AI-connected tools and credentials Map every assistant, agent, MCP server, and extension to the data and systems it can reach, including secrets and service accounts.
- Constrain delegated permissions for AI systems Limit AI tool access to the minimum scope needed for the task, and review whether the identity used by the system is tightly bounded.
Bottom line: AI safety and AI security fail in different ways, so they need different ownership, controls, and sign-off criteria.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 12:40 pm
AI safety and AI security must be governed as distinct risk classes: conflating them creates false confidence and broken ownership. Safety asks whether an approved system can still cause unacceptable harm, while security asks whether an attacker can redirect that system through hostile inputs, poisoned data, or compromised tools. Organisations that merge the two end up with vague accountability and inconsistent readiness criteria. The practical conclusion is that safety and security need separate control objectives, even when they share the same platform.
A few things that frame the scale:
- Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
A question worth separating out:
A: They should treat those agents as governed non-human identities. Inventory their permissions, separate creation from approval, and limit their access to the smallest set of repositories, registries, and deployment paths needed for the task.
👉 Read our full editorial: AI safety and AI security are not the same governance problem