Notifications
Clear all
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.
NHIMG editorial — based on content published by Knostic: AI safety and AI security are not the same governance problem
Questions worth separating out
Q: How should security teams govern AI assistants that can access enterprise tools?
A: Treat AI assistants as privileged systems, not as simple interfaces.
Q: Why do AI systems create both safety and security risk?
A: AI systems can cause harm even when they behave as designed, which is a safety issue, and they can also be manipulated by attackers, which is a security issue.
Q: What do organisations get wrong about AI security governance?
A: They often assume model hardening is enough, while the real exposure sits in tool access, delegated credentials, logging, and approval paths.
Practitioner guidance
- Separate safety gates from security gates Define distinct approval criteria for harmful-output risk and adversarial misuse risk before any AI system reaches production.
- Restrict AI tool access by workflow Limit MCP servers, coding assistants, and connected tools to the smallest set of repositories, secrets, and actions required for each use case.
- Treat AI connectors as privileged integrations Log every tool invocation, credential use, and data retrieval event for systems that can act on behalf of users or services.
What's in the full article
Knostic's full research covers the operational detail this post intentionally leaves for the source:
- Specific examples of where AI safety and AI security diverge in enterprise governance decisions
- Practical discussion of how coding assistants, MCP servers, and agentic workflows expand the attack surface
- Why the organisation's RACI often fails when legal, product, security, and data teams split ownership
- Implementation context for balancing model behaviour, delegated access, and accountability
👉 Read Knostic's analysis of where AI safety and AI security diverge →
AI safety vs. security: where does governance actually split?
Explore further
09/07/2026 12:40 pm
AI safety and AI security should be treated as separate governance domains. Safety evaluates whether a system can cause harm while still operating as intended. Security evaluates whether an adversary can bend that system off its intended path. Enterprises that collapse the two usually misassign ownership and misjudge readiness. The practical consequence is weak accountability across legal, product, and security functions.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
A question worth separating out:
Q: Who should be accountable for AI safety and AI security decisions?
A: Accountability should sit with a clearly named owner who can coordinate security, legal, product, and operational decisions. Safety and security should not be split into disconnected silos because the same AI system can create harm, compliance risk, and adversarial exposure at once. The accountable owner must control change approval and escalation.
👉 Read our full editorial: AI safety and AI security are not the same governance problem
