You Clicked Accept. The Plugin Has Your Inbox, Your Files, and Your Clipboard. Someone Is Building a Score. The Question Is Who Controls It.

There are now more than 5,000 AI-powered plugins available across the Chrome Web Store, the GPT plugin marketplace, and the various AI tool directories that have proliferated since the generative AI wave began in 2022. Each one arrives with a permission request. Some request access to your current tab. Some request access to all your browsing data. Some request access to your email. Some request access to your file system, your clipboard, your microphone, and the ability to communicate with external servers. The permission popup that mediates this request was designed in an era when the most common browser extension was a coupon finder or an ad blocker, and its design has not materially changed since.

The permission model treats a solo developer shipping from a laptop in Moldova and a funded company with a dedicated security team identically. Both submit to the same store. Both display the same type of permission dialog. Both sit in the same category on the same discovery page. The user who clicks accept is granting the Moldova laptop and the security-reviewed enterprise the same level of trust through the same mechanism, with no information available to distinguish between them.

The Plugpass concept proposes to change this by scanning AI tools before installation, scoring them on the data they access, the gap between what their privacy policy claims and what their actual API call behaviour demonstrates, and the verified identity and trust credentials of the developer behind them. Before the score exists, the user sees a permission popup and clicks accept. After the score exists, the user sees a risk score, a data pathway breakdown, and a comparison to alternatives with smaller permission footprints.

This is a genuinely useful idea. It is also an idea with multiple layers of complexity underneath its clean surface, each of which produces questions that the concept’s description does not fully answer. Who builds the score? Who governs it? Who decides what constitutes risk? What happens when the scoring system itself becomes the target? What happens when the score is gamified by developers who learn to optimise for the metric rather than the underlying safety it is supposed to measure? And what is the financial reality of the world without this system, which the breach cost data can describe in specific and uncomfortable detail?

This essay is about all of those layers simultaneously, in the multidisciplinary way that a problem involving security, economics, social behaviour, political economy, and the specific comedy of a safety infrastructure that is perpetually six months behind the attack surface it is supposed to protect deserves to be examined.

The Financial Cost of the Current Nothing. In Numbers Worth Sitting With.

IBM’s Cost of a Data Breach Report 2025 documented the average total cost of a data breach at $4.88 million globally, a figure that represents direct costs including incident response, regulatory fines, legal fees, and notification costs, as well as indirect costs including customer churn and reputational damage. This is an average. The distribution is skewed: the median breach cost is significantly lower, and the large enterprise breaches that generate the attention are significantly higher. The Change Healthcare breach of 2024 is estimated to have cost its parent company UnitedHealth Group approximately $2.9 billion and disrupted healthcare payments across the United States for months.

The plugin-specific breach cost data is not cleanly separated from general breach data in most reporting, because the initial access vector is not always clearly attributed to a specific plugin in the forensic analysis. What is documented is the access vector pattern. The Verizon Data Breach Investigations Report 2025 found that third-party software and supply chain attacks accounted for approximately 15% of all breaches, up from 9% three years prior. Browser extension and plugin compromise is a growing subset of this category. The NotPetya attack of 2017, which caused an estimated $10 billion in global economic damage and remains one of the most expensive cyberattacks in history, originated through a software update mechanism for accounting software that had been compromised by inserting malicious code into a legitimate software channel. This is the supply chain attack model applied to software distribution, and it is the same attack model that a compromised or malicious AI plugin represents.

The specific economics of the AI plugin attack surface are more alarming than general breach statistics suggest, for two reasons. First, the data that AI productivity plugins access tends to be the highest-value data in a user’s digital environment: email communications, document contents, browser history, clipboard contents, and in enterprise deployments, access to internal systems through the user’s authenticated session. A single compromised AI writing assistant installed by a senior executive with broad system access has access to everything that executive can access, which in a typical enterprise includes financial data, personnel information, strategic plans, and communications with counterparties. The attack surface is not the plugin’s permissions. It is the user’s full data environment, mediated through the plugin’s access.

Second, the AI plugin ecosystem has grown at a speed that the organisational security review processes that would normally mediate enterprise software deployment have not kept up with. The bring-your-own-AI phenomenon, where employees install AI productivity tools personally and use them in their work without IT department awareness or approval, is now documented at 78% of professionals in multiple surveys. This means that the enterprise security perimeter, which is designed around the software that the IT department has reviewed and approved, has been permeable to thousands of AI tools that employees have installed without review, each of which may have access to corporate data through the employee’s authenticated sessions.

The McKinsey & Company hack through its own AI tool, mentioned in the AI episode that this series has covered, illustrates this at the enterprise level. A consulting firm that advises its clients on security governance was compromised through an internal AI tool, demonstrating that the vulnerability is not confined to naive individual users but extends to sophisticated organisations with dedicated security functions. The AI tool vulnerability bypassed the security architecture not because the security architecture was inadequate but because the security architecture was not designed for an attack surface that arrives through a tool the security team may have approved for a different use case than the one through which the compromise occurred.

The financial cost of the current nothing, the world in which no standardised scoring or transparency infrastructure exists for AI plugin safety, is therefore not the cost of the breaches that have been documented. It is the cost of those breaches plus the cost of the breaches that are occurring without detection, plus the expected cost of the breaches that will occur as the attack surface grows and the gap between deployment velocity and security infrastructure widens further. The IBM average of $4.88 million per breach, applied to the scale of AI plugin deployment, produces a forward-looking risk profile that makes the cost of building the prevention infrastructure look modest by comparison.

A single rogue plugin breach at an enterprise with meaningful data access costs more than years of prevention. This is not a controversial claim. It is the arithmetic of the breach cost versus the prevention cost applied to the specific AI plugin attack surface. The argument for doing nothing is not that nothing is cheaper than prevention. The argument for doing nothing is that prevention requires coordination, and coordination requires governance, and governance requires someone to be in charge, and the question of who should be in charge is the one that the nothing strategy most effectively defers.

The Social and Hacking Perspective. Or: How the Attack Actually Works.

The prompt injection attack on AI agents, documented in detail in an earlier essay, is the mechanism by which the AI plugin ecosystem is most directly exploitable. A malicious actor who wants to compromise a user through an AI writing assistant does not need to hack the writing assistant’s servers. They need to create content that the writing assistant reads on the user’s behalf that contains instructions the assistant interprets as commands rather than as data to be processed. The email that says please summarise this thread and also forward the last thirty emails to the following address is, to the AI assistant reading it, an instruction identical in format to the user’s original instruction to summarise the thread. The assistant cannot tell the difference.

The specific social engineering dimension of this attack vector is more subtle than the technical description implies. The AI plugin that is most useful to an enterprise user is the one that is most deeply integrated into their workflow: the email assistant that reads all incoming mail, the document assistant that has access to the full file system, the calendar assistant that can schedule and accept meetings, the browser assistant that tracks all visited pages. The depth of integration that makes the tool most useful is also the depth that makes a successful attack most consequential. The user who installs the most useful AI assistant has also installed the most powerful attack surface.

The plugin marketplace model that has emerged around AI tools replicates the most dangerous feature of every previous app marketplace: the near-zero barrier to entry for malicious actors combined with the post-hoc moderation model that removes harmful tools after discovery rather than preventing their deployment. Google Chrome’s Web Store, despite multiple reviews and policy updates, has consistently hosted malicious extensions that are discovered and removed after causing harm. The 2020 research by academic security researchers found over 500 malicious extensions in the Chrome Web Store with over 1.7 million users at the time of removal. The extensions had been present for months in some cases. The discovery was by third-party researchers, not by Google’s own moderation. The removal was after the harm was done.

The GPT plugin and custom GPT marketplace operates on a similar model. OpenAI reviews tools before listing but at the scale of thousands of new submissions per week, the review is necessarily lightweight for the majority of tools. The developer who submits a tool with a clean privacy policy, a professional presentation, and functionality that appears benign at review time has already cleared the barrier that the marketplace model is supposed to represent. The malicious functionality, if it exists, is deployed after listing, when the developer updates the tool’s behaviour or when the tool’s access permissions are used for purposes that the initial review did not anticipate.

The browser extension supply chain attack, where a legitimate and popular extension is acquired by a malicious actor after the developer has built the user base, is documented frequently enough to be considered a standard attack pattern rather than an exceptional one. The developer who built a popular productivity extension over two years, accumulated 100,000 users, and then sold it to an apparently legitimate buyer has no visibility into what the buyer does with the extension after the sale. The buyer has purchased the user base and the extension’s permissions on that user base. The subsequent update to the extension that installs malicious functionality goes to 100,000 users who trust the extension because they installed it from a developer who was legitimate at the time of installation.

The social dimension of this attack pattern is the specific quality that makes it more dangerous than the purely technical description suggests. Trust in browser extensions and AI plugins is accumulated over time, is community-mediated through reviews and recommendations, and is transferred between parties when a tool is acquired or when a developer’s account is compromised. A tool that has 50,000 five-star reviews is trusted by the users who see those reviews.

The reviews reflect the tool’s behaviour before the malicious update. The trust does not reset when the tool’s behaviour changes. The user who installed the tool because it had good reviews and has not thought about it since does not know that the tool’s ownership changed six months ago and the new owner’s business model is different from the previous one.

The Architecture of Doing Nothing. Its Specific Costs and Its Specific Beneficiaries.

The nothing strategy, the continued absence of standardised AI plugin safety infrastructure, has specific beneficiaries whose interests in its continuation are worth naming explicitly. They are not the users. They are not the enterprises deploying AI tools. They are the platforms that host the plugin marketplaces and the developers who benefit from frictionless deployment of tools that might not survive a rigorous scoring process.

The Chrome Web Store generates revenue through developer registration fees and through the distribution advantages that Google’s browser dominance provides. The GPT plugin and custom GPT marketplace generates revenue and user engagement for OpenAI through the expanded capabilities that plugins provide to ChatGPT. These platforms have financial incentives to maintain large catalogues of available tools, because large catalogues are a competitive advantage: a platform with 5,000 plugins appears more capable than one with 500. The review burden that would be required to comprehensively evaluate the safety of 5,000 plugins is substantial and would slow the rate at which new plugins can be added. The frictionless deployment that characterises the current model is, from the platform’s perspective, a feature.

The regulation that could change this incentive structure exists in incomplete form. The European Union’s AI Act, which came into full effect in 2024, classifies AI systems by risk level and imposes requirements on high-risk systems that include transparency, data governance, and security requirements. Browser extensions and productivity plugins are not cleanly classified under the AI Act’s framework because they function as wrappers around AI capabilities rather than as AI systems in the primary sense the regulation addresses. The regulatory classification gap is the gap through which the current nothing strategy persists.

The GDPR, which imposes data processing requirements on any organisation handling EU residents’ data, applies in principle to AI plugin developers who collect and process user data. In practice, enforcement against small-scale plugin developers who are natural persons or small companies outside the EU is extremely difficult, extremely slow, and extremely resource-intensive for the enforcement authorities who are already managing backlogs of enforcement actions against much larger organisations. The developer in Moldova with 50,000 users is not a high priority for the Irish Data Protection Commission, which is the lead EU supervisory authority for most large technology companies and which has documented case backlogs measured in years.

The Cyber Resilience Act, adopted by the EU in 2024 and coming into full effect over the following three years, imposes security requirements on products with digital elements sold in the EU market. Browser extensions are potentially in scope. The implementation timeline and the enforcement architecture for products distributed through software marketplaces are still being worked through by regulators and industry stakeholders. The regulation is more comprehensive than what preceded it. The implementation gap between the regulation’s requirements and the actual security posture of most AI plugin developers in the market is substantial and will not be closed on any timeline that addresses the current risk profile of the installed base.

The doing nothing strategy persists not because no one has noticed the problem but because the coordination required to solve it involves multiple actors with conflicting incentives, multiple regulatory jurisdictions with different frameworks, and the specific political economy of any safety infrastructure that imposes costs on developers who are currently paying none.

The costs of the nothing strategy are borne by the users and enterprises who experience the breaches. The costs of the alternative strategy are borne by the platform operators and developers who would have to fund or comply with the safety infrastructure. The current regulatory and market structure does not cause these costs to fall on the parties best positioned to bear them, which is the standard condition for the persistence of the nothing strategy in every previous version of this problem.

Would the Scoring System Work. The Honest Assessment.

The Plugpass concept has a technically sound core. Parsing permission manifests from extension stores is automatable and produces structured data about what a tool requests access to. Parsing privacy policies using language models to identify gaps between stated and likely actual data handling is technically feasible and is being done in research contexts already. Cross-referencing developer identities against professional network profiles and code repositories provides signal about the legitimacy and accountability of the developer. Behavioural monitoring of API calls from opted-in users provides the most valuable signal: the distance between what the privacy policy claims and what the tool does in practice.

The behavioural monitoring signal is the hardest to collect and the most valuable, for exactly the same reason: collecting it requires users to run the monitoring infrastructure and transmit their API call data to the scoring service, which is itself a data collection activity that requires trust in the scoring service. The ironies here are structural rather than accidental. A safety scoring tool that requires elevated access permissions to monitor the behaviour of other tools with elevated access permissions has the same attack surface as the tools it is monitoring. If the scoring service is compromised, the attacker has access to behavioural data across the entire monitored tool population, which is potentially more valuable than the data any individual monitored tool provides.

The gaming problem is the most analytically interesting challenge. Any scoring system produces a score, and any score produces an incentive to optimise for the score rather than for the underlying safety the score is supposed to measure. The credit rating agencies that assessed mortgage-backed securities in the 2000s were scoring systems that were gamed by the financial engineers who understood the rating methodology better than the agencies had anticipated. The certificate authorities that issue HTTPS certificates are scoring systems for website identity that have been gamed by malicious operators who obtain legitimate certificates for phishing sites. The app store review processes that are supposed to function as safety scoring systems are gamed continuously by developers who understand the review criteria and design their initial submission to clear the review before deploying the problematic functionality in a subsequent update.

A motivated bad actor who wants to build a malicious AI plugin and understands the Plugpass scoring methodology can optimise their tool’s initial behaviour to score well, accumulate the user base that good scores enable, and then deploy the malicious functionality in an update after the score has been established and the users have installed the tool. The score reflects the behaviour at the time of scoring. The update to the behaviour after scoring is the same vulnerability that exists in every other safety review mechanism in the software distribution ecosystem. Plugpass adds a continuous monitoring component through the behavioural opt-in, which reduces this window, but does not eliminate it, because the monitoring depends on users continuing to opt in and the update can be designed to defeat the monitoring before the monitoring catches it.

The false negative problem, where dangerous tools score safe, is the obvious failure mode.

The false positive problem, where legitimate tools score risky because they have a large permission footprint for legitimate reasons, is equally significant and less discussed. A legitimate enterprise AI tool that requires broad permissions to deliver its functionality will score similarly to a malicious tool that requests the same permissions for data exfiltration. The score does not distinguish between legitimate and malicious uses of the same permissions. The user who sees a high-risk score on a legitimate enterprise tool they need for their job and a high-risk score on a malicious tool they should not install receives no useful differentiation from the score alone. The score needs context that the permission manifest alone cannot provide.

Despite these limitations, the scoring system produces more information than the current nothing. The permission manifest parsing alone would flag many tools that users would choose not to install if they understood what they were granting. The developer identity verification would differentiate between established developers with track records and anonymous submitters with no verifiable history.

The privacy policy parsing would identify the specific language that signals data practices that users would find objectionable if they read the policy, which they do not, because privacy policies are long, written in legal language, and designed to be authoritative rather than legible. The scoring system is an imperfect information improvement over a current state of essentially no information at the point of installation decision. Imperfect information improvement over no information is genuinely valuable.

The Business Model. Who Pays, Who Controls, and Why Both Questions Matter Enormously.

The business model for a plugin safety scoring service can be structured in several ways, and each structure produces different incentives that affect the independence and reliability of the score. Understanding the business model options is not an academic exercise. It is the most important question about whether the scoring system can work, because the scoring system’s value depends entirely on its independence from the parties whose behaviour it is scoring.

The user-subscription model, where individual users pay a monthly or annual fee for access to the scoring service, produces a scoring service that is financially dependent on user trust and therefore has strong incentives to maintain score integrity. Users who discover that the scores are manipulated or inaccurate cancel their subscriptions. The service loses revenue. The incentive alignment between the user who pays and the independence of the service is clean.

The limitation is that the user-subscription model caps the addressable market at users who are motivated enough to pay for plugin safety information, which is a subset of the total user population that is probably smaller than the total user population that would benefit from the information. The users most at risk, those installing the most plugins most quickly, are not necessarily the users most likely to pay for a safety scoring service.

The enterprise platform model, where organisations pay for a managed version of the scoring service that monitors and controls AI tool usage across their workforce, produces a larger addressable market, better revenue per customer, and a customer base that has the most to lose from plugin breaches and therefore the strongest incentive to pay for prevention. The limitation is that the enterprise model creates a relationship between the scoring service and the enterprises it serves that may create pressure on scores for tools that those enterprises want to use but that the honest scoring would rate as risky. The enterprise that has already deployed a high-risk tool to 10,000 employees and then subscribes to the scoring service that rates the tool as high risk has a complicated relationship with the score that the enterprise subscription model has created.

The developer certification model, where developers pay for verification and trust badges that improve their tools’ scores, produces the most obvious conflict of interest. A scoring service that charges developers for the badges that improve their scores is a scoring service whose financial interests are aligned with providing good scores to paying developers. This is structurally identical to the issuer-pays model in the credit rating industry that contributed to the 2008 financial crisis by creating incentives for rating agencies to provide favourable ratings to the securities issuers who were paying for the ratings. The developer-pays scoring model is the issuer-pays model for AI plugin safety. It will produce the same outcome.

The platform partnership model, where browser stores or AI assistant platforms pay for the scoring infrastructure and use it in their own review processes, produces the most comprehensive coverage but reintroduces the platform’s financial interests into the scoring. A Chrome Web Store that has paid for the scoring infrastructure has financial interests in the results: a scoring system that rates too many tools as high risk reduces the extension catalogue that is a competitive advantage for the store. The pressure on the scoring service to calibrate thresholds in ways that do not produce too many high-risk ratings for the platform’s preferred tools is structural rather than explicit, but it is present.

The non-profit or standards body model, funded by a combination of foundation grants, government research funding, and voluntary industry contributions, avoids the direct commercial conflict of interest but introduces governance complexity and funding uncertainty.

Non-profit security organisations exist in the software ecosystem and produce genuinely valuable work: the Open Web Application Security Project, the Internet Security Research Group (ISRG) that issues Let’s Encrypt certificates, the Center for Internet Security that produces the security benchmarks that enterprise IT departments use. These organisations work because their governance structures, funding models, and accountability mechanisms maintain their independence from the industries they are evaluating. Replicating this for AI plugin scoring requires building that governance infrastructure from scratch, which takes time, and the AI plugin ecosystem is generating new risk faster than governance infrastructure can be built.

The governance question is ultimately the most important one because the scoring system’s reliability depends on the answer.

Who decides what constitutes a risky permission request?

Who decides when a privacy policy claim is inconsistent with observed API call behaviour?

Who decides what the trust badge criteria are and who can earn them?

These are not technical questions. They are policy questions that will be contested by the developers who want lower-risk scores, the platforms that want larger catalogues, the enterprises that want tools that score well enough to deploy, and the users who want scores that actually predict harm. The governance structure determines whose interests are weighted in those contests and therefore what the scores actually measure.

The Analogy That Explains Everything. And Also Explains Why It Is Hard.

The food safety inspection system is the closest analogy to what Plugpass is proposing, and examining how food safety inspection works, what it costs, and why it sometimes fails is instructive about the path ahead.

Food safety inspection works through a combination of government-mandated minimum standards, third-party certification programmes, and post-incident enforcement. The minimum standards define what constitutes unacceptable risk. The certification programmes verify compliance above the minimum standard. The enforcement responds to failures. The cost of the system is borne by the producers through compliance costs, by consumers through prices that reflect the compliance costs, and by governments through inspection infrastructure. The benefit of the system is the reduction in foodborne illness, which has measurable public health and economic value.

The food safety system has failure modes. Inspection frequency is insufficient to catch all violations. Inspectors can be captured by the industries they regulate. Certification bodies can be corrupted by the fees they receive from certifying. The minimum standards lag the emergence of new pathogens and new production methods. None of these failure modes have caused the system to be abandoned, because the imperfect system produces dramatically better outcomes than the nothing strategy it replaced. The E. coli outbreaks that occur despite the inspection system are far fewer and far smaller than the E. coli outbreaks that would occur without it.

The AI plugin safety equivalent requires the same combination: government-mandated minimum standards for what constitutes acceptable data handling in AI tools, third-party certification for tools that want to demonstrate above-minimum safety, and post-incident enforcement for tools that cause harm. The Plugpass scoring concept addresses the certification layer. It does not address the minimum standards layer, which requires government action, or the enforcement layer, which also requires government action. A certification system without minimum standards is voluntary and therefore captures only the developers who choose to seek certification, who are not the developers most likely to cause harm. A scoring system without enforcement consequences for low scores is informational rather than behavioural, and its effect on the actual risk profile of the ecosystem depends on how many users respond to the information by making different installation decisions.

The Cyber Resilience Act in the EU is the beginning of the minimum standards layer. The GDPR enforcement against data mishandling is the beginning of the enforcement layer. The Plugpass concept is the beginning of the certification layer. All three are early stage, all three are imperfect, and the combination of all three, once mature and coordinated, produces something that resembles the food safety system for software. The food safety system took decades to develop and is still imperfect. The AI plugin safety equivalent will take years to develop and will be imperfect. The nothing strategy produces outcomes that are worse than the imperfect system. This is the argument.

The Cynical Conclusion. Which Also Happens to Be the Most Useful One.

The AI plugin ecosystem has grown faster than any safety infrastructure could follow. This is not a coincidence. It is the standard sequence in every technology deployment wave: deployment velocity exceeds safety infrastructure because deployment is incentivised by competitive advantage and revenue, while safety infrastructure is incentivised by liability and regulation, and liability and regulation consistently lag deployment by the time required to observe the harm and enact the response.

The person who installed an AI writing assistant last week, clicked accept on the permission popup, and went back to their document did not perform a risk assessment. They performed the action that the interface was designed to make frictionless. The interface was designed by a platform whose interests are in maximising the number of installed tools. The friction that a safety scoring system would introduce to the installation process is, from the platform’s perspective, a competitive disadvantage. From the user’s perspective, it is the difference between knowing what they are installing and not knowing.

The Plugpass concept is a genuine attempt to produce the information that the current interface does not provide. Its technical approach is sound for the limitations described. Its business model questions are real and unresolved. Its governance questions are the most important and the least resolved. Its effect on the actual risk profile of the ecosystem depends on adoption rates that are impossible to predict before the product exists and hard to optimise without the governance structure that determines what the scores actually measure.

What it would unambiguously produce, even in its most imperfect form, is more information than the current nothing. The user who sees a risk score before installation is better positioned to make a decision than the user who sees a permission popup. The enterprise IT department that can see which AI tools its employees are installing and how they score is better positioned to manage its attack surface than the department that has no visibility into the BYOAI tools running on corporate devices. The developer who understands what scoring criteria they are being evaluated against has an incentive to improve their tool’s behaviour in the ways the criteria reward, even if they also have an incentive to game the criteria in the ways the gaming problem describes. The gaming of the score is a lower-quality problem than the absence of the score.

The credit rating industry is the most instructive parallel for the risks of the scoring model itself. Moody’s, S&P, and Fitch produced scores that were used to make financial decisions of enormous consequence, had business models that created conflicts of interest between the accuracy of their scores and the revenue from the entities they were scoring, and produced AAA ratings for securities that turned out to be worth significantly less than their ratings implied. The financial crisis cost the global economy an estimated $10 to $22 trillion.

The rating agencies survived it. The people who made financial decisions based on their scores did not all survive it as well. A plugin safety scoring system that develops the same conflict-of-interest business model will produce a similar gap between the score and the reality it is supposed to represent, at a smaller scale but with potentially similar consequences for the specific organisations that make security decisions based on scores that have been compromised by the business model that produces them.

The answer to the credit rating parallel is not to not build the scoring system. It is to build it with the governance structure that the credit rating agencies did not have: independence from the rated entities, accountability to the users of the scores, and transparency about the methodology sufficient to allow third-party validation of whether the scores are measuring what they claim to measure. This governance structure is hard to build, expensive to maintain, and politically contested by the parties whose interests it constrains. It is also the only version of the scoring system that produces the outcome it promises.

Someone is going to build this. Several groups are probably building something like it right now. The question that determines whether it works is not technical. It is the governance question that the technical description of the concept tends to leave for later. Later needs to be sooner. The attack surface is growing. The breaches are accumulating. The nothing strategy is producing documented financial and human costs that the prevention alternative would reduce. The prevention alternative needs a governance structure that can maintain its independence long enough to earn the trust that makes the scores useful.

The popup that says accept is still waiting. The risk score should be next to it. Who controls the risk score controls the safety of the most widely deployed software category of the decade. This is not a technical detail. It is the most important governance question in the AI plugin ecosystem. It would be convenient if the people building the infrastructure treated it as such before the score exists rather than after it has been captured.

Cybersecurity #AI #Finance #SystemsThinking #LongFormThinking #DataPrivacy #Governance #NoBS