There\u2019s a pattern playing out inside almost every engineering organization right now. A developer installs GitHub Copilot to ship code faster. A data analyst starts querying a new LLM tool for reporting. A product team quietly embeds a third-party model into a feature branch. By the time the security team hears about any of it, the AI is already running in production \u2014 processing real data, touching real systems, making real decisions.<\/p>\n
That gap between how fast AI enters an organization and how slowly governance catches up is exactly where risk lives. According to a new practical framework guide \u2018AI Security Governance: A Practical Framework for Security and Development Teams<\/a><\/em><\/strong>,\u2019\u00a0 from Mend, most organizations still aren\u2019t equipped to close it. It doesn\u2019t assume you have a mature security program already built around AI. It assumes you\u2019re an AppSec lead, an engineering manager, or a data scientist trying to figure out where to start \u2014 and it builds the playbook from there.<\/p>\n The framework<\/a> begins with the critical premise that governance is impossible without visibility (\u2018you cannot govern what you cannot see\u2019). To ensure this visibility, it broadly defines \u2018AI assets\u2019 to include everything from AI development tools (like Copilot and Codeium) and third-party APIs (like OpenAI and Google Gemini), to open-source models, AI features in SaaS tools (like Notion AI), internal models, and autonomous AI agents. To solve the issue of \u2018shadow AI\u2019 (tools in use that security hasn\u2019t approved or catalogued), the framework stresses that finding these tools must be a non-punitive process, ensuring developers feel safe disclosing them<\/p>\n The framework<\/a> uses a risk tier system to categorize AI deployments instead of treating them all as equally dangerous. Each AI asset is scored from 1 to 3 across five dimensions: Data Sensitivity, Decision Authority, System Access, External Exposure, and Supply Chain Origin. The total score determines the required governance:<\/p>\n It is essential to note that a model\u2019s risk tier can shift dramatically (e.g., from Tier 1 to Tier 3) without changing its underlying code, based on integration changes like adding write access to a production database or exposing it to external users.<\/p>\n The framework<\/a> emphasizes that most AI security failures are due to poor access control, not flaws in the models themselves. To counter this, it mandates applying the principle of least privilege to AI systems\u2014just as it would be applied to human users. This means API keys must be narrowly scoped to specific resources, shared credentials between AI and human users should be avoided, and read-only access should be the default where write access is unnecessary.<\/p>\n Output controls are equally critical, as AI-generated content can inadvertently become a data leak by reconstructing or inferring sensitive information. The framework requires output filtering for regulated data patterns (such as SSNs, credit card numbers, and API keys) and insists that AI-generated code be treated as untrusted input, subject to the same security scans (SAST, SCA, and secrets scanning) as human-written code.<\/p>\n When you deploy a third-party model, you\u2019re inheriting the security posture of whoever trained it, whatever dataset it learned from, and whatever dependencies were bundled with it. The framework<\/a> introduces the AI Bill of Materials (AI-BOM) \u2014 an extension of the traditional SBOM concept to model artifacts, datasets, fine-tuning inputs, and inference infrastructure. A complete AI-BOM documents model name, version, and source; training data references; fine-tuning datasets; all software dependencies required to run the model; inference infrastructure components; and known vulnerabilities with their remediation status. Several emerging regulations \u2014 including the EU AI Act and NIST AI RMF \u2014 explicitly reference supply chain transparency requirements, making an AI-BOM useful for compliance regardless of which framework your organization aligns to.<\/p>\n Traditional SIEM rules, network-based anomaly detection, and endpoint monitoring don\u2019t catch the failure modes specific to AI systems: prompt injection, model drift, behavioral manipulation, or jailbreak attempts at scale. The framework defines three distinct monitoring layers that AI workloads require.<\/p>\n At the model layer, teams should watch for prompt injection indicators in user-supplied inputs, attempts to extract system prompts or model configuration, and significant shifts in output patterns or confidence scores. At the application integration layer, the key signals are AI outputs being passed to sensitive sinks \u2014 database writes, external API calls, command execution \u2014 and high-volume API calls deviating from baseline usage. At the infrastructure layer, monitoring should cover unauthorized access to model artifacts or training data storage, and unexpected egress to external AI APIs not in the approved inventory.<\/p>\n The framework<\/a>\u2019s policy section defines six core components:<\/p>\n Effective policy requires clear ownership. The framework<\/a> assigns accountability across four roles:<\/p>\n The most durable enforcement is achieved through tooling. This includes using SAST and SCA scanning in CI\/CD pipelines, implementing network controls that block egress to unapproved AI endpoints, and applying IAM policies that restrict AI service accounts to minimum necessary permissions.<\/p>\n The framework closes with an AI Security Maturity Model organized into four stages<\/a> \u2014 Emerging (Ad Hoc\/Awareness), Developing (Defined\/Reactive), Controlling (Managed\/Proactive), and Leading (Optimized\/Adaptive) \u2014 that maps directly to NIST AI RMF, OWASP AIMA, ISO\/IEC 42001, and the EU AI Act. Most organizations today sit at Stage 1 or 2, which the framework frames not as failure but as an accurate reflection of how fast AI adoption has outpaced governance.<\/p>\n Each stage transition comes with a clear priority and business outcome. Moving from Emerging to Developing is a visibility-first exercise: deploy an AI-BOM, assign ownership, and run an initial threat model. Moving from Developing to Controlling means automating guardrails \u2014 system prompt hardening, CI\/CD AI checks, policy enforcement \u2014 to deliver consistent protection without slowing development. Reaching the Leading stage requires continuous validation through automated red teaming, AIWE (AI Weakness Enumeration) scoring, and runtime monitoring. At that point, security stops being a bottleneck and starts enabling AI adoption velocity.<\/p>\n The full guide, including a self-assessment that scores your organization\u2019s AI maturity against NIST, OWASP, ISO, and EU AI Act controls in under five minutes, is available for download.<\/a><\/strong><\/p>\n The post Mend Releases AI Security Governance Framework: Covering Asset Inventory, Risk Tiering, AI Supply Chain Security, and Maturity Model<\/a> appeared first on MarkTechPost<\/a>.<\/p>","protected":false},"excerpt":{"rendered":" There\u2019s a pattern playing out …<\/p>\n","protected":false},"author":1,"featured_media":29,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-783","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/connectword.dpdns.org\/index.php?rest_route=\/wp\/v2\/posts\/783","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/connectword.dpdns.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/connectword.dpdns.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/connectword.dpdns.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/connectword.dpdns.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=783"}],"version-history":[{"count":0,"href":"https:\/\/connectword.dpdns.org\/index.php?rest_route=\/wp\/v2\/posts\/783\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/connectword.dpdns.org\/index.php?rest_route=\/wp\/v2\/media\/29"}],"wp:attachment":[{"href":"https:\/\/connectword.dpdns.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=783"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/connectword.dpdns.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=783"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/connectword.dpdns.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=783"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Inventory Problem<\/strong><\/h3>\n
A Risk Tier System That Actually Scales<\/strong><\/h3>\n
\n
Least Privilege Doesn\u2019t Stop at IAM<\/strong><\/h3>\n
Your Model is a Supply Chain<\/strong><\/h3>\n
Monitoring for Threats Traditional SIEM Can\u2019t Catch<\/strong><\/h3>\n
Build Policy Teams Will Actually Follow<\/strong><\/h3>\n
\n
Governance and Enforcement<\/strong><\/h3>\n
\n
Four Maturity Stages, One Honest Diagnosis<\/strong><\/h3>\n