On October 19, 2026, the AICPA and the Artificial Intelligence Underwriting Company (AIUC) announced a joint assurance offering that bundles a SOC 2 report with an AIUC-1 certification in one CPA-led engagement. A few CPA firms are already running pilots. The full launch is set for early 2027. If you sell AI agents into enterprises, this one’s about you. SOC 2 is the report your prospects already ask for in procurement. AIUC-1 is the standard that checks whether your agent can be talked into leaking data, inventing a refund policy, or calling an API it was never supposed to touch. Putting both into one engagement, under the AICPA’s attestation standards, changes what audit-ready means for any company whose software acts inside other people’s systems. Here’s what was announced, what AIUC-1 tests, why the AICPA’s name matters more than the certificate itself, and what you should do about it if you’re working on SOC 2 or ISO 42001 right now. What the AICPA and AIUC Announced The offering is a single report from one engagement led by a licensed CPA. It combines two things. The first is a standard SOC 2 examination under the AICPA Attestation Standards, with an opinion on
On October 7, 2026, the Monetary Authority of Singapore issued its final Guidelines on AI Risk Management, and the clock is now running. Every financial institution in Singapore has until October 7, 2027 to meet the core supervisory expectations, with the remaining sections due by October 7, 2028. The Guidelines apply to all FIs and all forms of AI, from a chatbot embedded in a support tool to autonomous agentic systems. Here’s the part most coverage will miss: the most commercially significant clause is not aimed at banks at all. MAS makes financial institutions fully accountable for third-party AI, including AI developed, operated, or provided by vendors. FIs must obtain sufficient assurance from those providers, and if they cannot, MAS expects them to limit, suspend, or replace the service. If you sell AI-powered software to banks, insurers, payment firms, or asset managers with a Singapore presence, that sentence is about you. Over the next twelve months, your FI customers will start asking how your AI is governed, and a security questionnaire alone won’t answer the question. This article covers what the Guidelines require, why vendors are effectively in scope, and how ISO 42001, the international standard for AI management systems,
Gartner predicts that by 2028, 90% of enterprise software engineers will use AI code assistants, up from less than 14% in early 2024. SOC 2 and ISO 27001 change management controls were written before that shift, and both rest on an assumption that AI-generated code breaks outright: the person who approved a change wrote it, or at least fully understood it. Neither the AICPA nor ISO has published AI-specific change management requirements, so auditors apply the existing controls, SOC 2 CC8.1 and ISO 27001 Annex A 8.32, to commits no human authored. Most teams discover the mismatch mid-audit, when a sample pulls up a 2,000-line agent-generated pull request that was approved in four minutes. This guide maps AI code generation to both frameworks: what each one requires, the risks AI coding assistants introduce, the workflow that satisfies auditors, and the evidence they request when GitHub Copilot, Cursor, or Claude Code shows up in your SDLC. Why AI-Generated Code Breaks Traditional Change Management Change management controls assume a human bottleneck. AI removes it in three places at once. The Volume Problem: AI Commits at Machine Speed A single developer running an agentic coding tool can open more pull requests in a
Global AI regulation is not converging. Four distinct regulatory models have hardened over the past two years: the EU’s single horizontal law, China’s fast-moving sequence of targeted rules, the American patchwork of state laws and voluntary frameworks, and the Gulf’s procurement-driven approach, where the state shapes the market by being its biggest customer. Anyone waiting for these to merge into one global rulebook will be waiting well past 2030. That fragmentation, not any single law, is the defining trend in AI regulatory compliance. The practical question for 2026 through 2028 is no longer “which regulation applies to us” but “which regulatory model does each of our markets follow, and what carries over between them.” This article maps the four models, with extra time on the Gulf version because it gets far less coverage than it deserves. It also argues that ISO standards, led by ISO/IEC 42001, are becoming the only compliance credential that travels across all four. The Four Models of AI Regulation Most trend pieces treat AI regulation as one global movement running at different speeds. It’s more useful to treat it as four philosophies that answer the same question in incompatible ways. European Union China United States Gulf
OWASP published the 2026 edition of its Top 10 for LLM Applications on August 4, 2026, during Black Hat week, and eight of the ten entries changed position. One got renamed. The message behind the reshuffle is blunt: you won’t build a model that can’t be fooled, so build the application around it in a way that limits the damage when it is. That one idea explains almost every move in the new ranking, and it should change how your team thinks about shipping AI features. This guide walks through the 2026 list in plain English: what each risk means, a real-world example, and what your team can actually do about it, with or without a dedicated security function. What Is the OWASP GenAI LLM Top 10 2026? The OWASP Top 10 for LLM Applications is a community-built awareness document that ranks the ten most critical security risks in applications powered by large language models. The OWASP GenAI Security Project, a global open-source initiative under the OWASP Foundation, maintains it, and the 2026 edition is the third release since the list first appeared in 2023. OWASP, the Open Worldwide Application Security Project, has published risk lists for web applications since
For the past two years, enterprise AI risk conversations have centered on a familiar set of concerns: model bias, hallucination, data privacy, and dependency on third-party models. These are real risks, and most organizations now run some version of a governance program to manage them. But something has shifted. Organizations are no longer just deploying AI that generates content for a human to review. They’re deploying AI that acts. Agents now plan multi-step tasks, call APIs, move data between systems, execute transactions, and coordinate with other agents, often with no human checkpoint in the loop. That shift deserves more than a footnote in the existing AI risk category. It deserves its own line in the risk register: Agentic Autonomy Risk. What Is Agentic AI Risk Management? Agentic AI risk management is the practice of identifying, assessing, and controlling the risks created when AI systems take autonomous action on an organization’s behalf. Where traditional AI governance evaluates outputs (accuracy, bias, privacy), agentic AI risk management governs what agents actually do: the tools they call, the permissions they inherit, and the downstream consequences of their actions. That distinction is the reason existing risk registers struggle with agents, and it’s worth unpacking properly.
One in five breached organizations last year traced the incident to shadow AI, and those breaches cost an average of $670,000 more than standard incidents, according to IBM’s 2025 Cost of a Data Breach Report. The worst part is that most of those organizations already ran a CASB, a DLP program, or both. The tools were on, but the traffic still got through. That’s the visibility gap this article is about. AI tool usage tracking isn’t the same problem as SaaS discovery, and the security stack built for the SaaS era misses most of what matters about AI. Below, we break down what tracking actually requires, where CASB and DLP fail, which categories of AI usage slip through, and what a stack that works looks like in 2026. What AI Tool Usage Tracking Actually Means Most teams that say they “track AI usage” mean they can see that someone visited chat.openai.com. That is app discovery, and it answers almost none of the questions a security or governance team actually needs answered. Beyond App Discovery: Tracking Prompts, Data Flows, and Model Interactions Real tracking covers three layers. First, which tools are in use: chatbots, copilots, coding assistants, embedded SaaS features, agents.
Most organizations think their AI governance is further along than it is. McKinsey’s 2026 AI Trust Maturity Survey of roughly 500 organizations found an average maturity score of 2.3 out of 4, and only about a third reported level three or higher in strategy, governance, and agentic AI oversight. Adoption is outpacing control, and regulators have noticed. An AI governance maturity model gives you a way to measure that gap honestly. This guide covers what a maturity model is, the six dimensions it should measure, the five levels most models use, and how to assess your own organization and build a roadmap to the next level. What Is an AI Governance Maturity Model? An AI governance maturity model is a structured framework that describes how capable an organization is at governing its AI systems, usually across five progressive levels. The concept borrows directly from the Capability Maturity Model (CMM) that software engineering has used since the early 1990s: define the capability, describe what it looks like at each stage of development, and score yourself against it. The purpose is diagnosis. A maturity model tells you where governance is strong, where it’s theater, and where it doesn’t exist at all. How
One in five organizations has already suffered a breach traced back to shadow AI. Meanwhile, 63% of breached organizations either have no AI governance policy at all or are still drafting one. Below is a complete, copy-ready shadow AI policy template with twelve sections, plus guidance on adapting it for your company size, your industry, and the regulatory frameworks you answer to. The template assumes one hard truth up front: your employees are already using unapproved AI tools. A policy that pretends adoption hasn’t started yet fails on day one, so this one starts from the assumption that it has. What Is a Shadow AI Policy? A shadow AI policy is a formal document that defines how your organization discovers, evaluates, approves, and governs AI tools that employees adopt outside official IT channels. The term borrows from shadow IT, the older problem of unsanctioned software and hardware, but the AI version carries sharper risks: data pasted into a public model may be retained, used for training, or exposed in ways the organization can’t reverse. The policy does three jobs: it separates approved use from unapproved use, gives employees a fast and visible way to request new tools so the sanctioned
Legacy threat modeling frameworks such as STRIDE were designed for software that behaves the same way over and over again. Agentic AI does no such thing. It can rewrite its own plan mid-task, call external tools, negotiate with other agents, and produce a different output from identical input. MAESTRO exists because none of the legacy threat modeling frameworks were built to handle that. MAESTRO stands for Multi-Agent Environment, Security, Threat, Risk, and Outcome. It is a seven-layer threat modeling framework created specifically for agentic AI systems, and it has become the closest thing the industry has to a standard method for reasoning about agent security. Understanding MAESTRO in the Context of Agentic AI What MAESTRO Stands For Each word in the acronym carries meaning. Multi-Agent Environment signals that the framework models entire ecosystems of interacting agents, not a single model behind an API. Security, Threat, Risk covers the core discipline: identifying attack surfaces, cataloging threats, and assessing likelihood and impact. Outcome is the part most frameworks skip. MAESTRO asks what an attack actually produces in the real world, because an autonomous agent with tool access turns a compromised prompt into a compromised action. The Origin of MAESTRO (Cloud Security Alliance)
