Ostrom for AI vulnerability management — what a Nobel-prizewinning economist who studied lobster fisheries figured out that the 90-day disclosure regime is missing.
Palo Alto Networks' Unit 42 published its 2026 Threat Intelligence Report in January with a number that I cannot get out of my head: attackers begin scanning for newly-disclosed vulnerabilities, and initiate exploitation attempts, within fifteen minutes of the CVE going public.
Fifteen minutes.
The entire scaffolding of responsible disclosure — the ninety-day windows, the coordinated patch days, the careful negotiation between researchers and vendors about when to publish — was built for a world where defenders had hours and days to deploy fixes before exploitation began. That world is gone. Software bugs in 2026 are exploited at the speed of an automated scanner reading a feed. And AI vulnerabilities are about to make this much worse, because most “AI vulnerabilities” can't be patched in any conventional sense at all. A prompt injection technique that works against GPT-4-class models works against most other models in the same family. A jailbreak discovered Monday is being used against thousands of deployed systems by Tuesday. There is no equivalent of “applying the patch.”
So what kind of governance system would actually work?
The answer turns out to come from an unexpected place: a Nobel-prizewinning political economist who spent her career studying lobster fisheries.
Carnegie Mellon's Software Engineering Institute reported in February 2025 that there are approximately 44,900 AI projects on GitHub, the majority of which provide no support for security workflows or coordinated vulnerability disclosure tooling. The CVE ecosystem — the systematic catalog of software vulnerabilities that the security community has built across thirty years — has no equivalent for AI behavioral flaws. A jailbreak isn't a CVE. A systematic bias in a model's output isn't a CVE. A prompt injection technique that crosses model boundaries isn't a CVE. The infrastructure that lets us coordinate around software bugs does not yet exist for AI.
This is, by any honest reading, a classic commons problem. The “resource” is the shared security of the AI ecosystem. Every AI lab, every deployer, every user benefits from a world where vulnerabilities get disclosed responsibly, patched promptly, and tracked systematically. And every individual actor has incentives to defect: discover a vulnerability and sell it to the highest bidder, find a flaw and stay quiet to preserve competitive advantage, ignore reports because addressing them costs money. Each defection degrades the commons a little. Enough defections, and the commons collapses.
The standard responses don't work:
This is exactly the configuration Elinor Ostrom spent her career studying — and exactly the kind of problem she proved was solvable.
Garrett Hardin's 1968 “Tragedy of the Commons” essay had become canonical: shared resources without strong property rights inevitably get overexploited. Centralized control or privatization were the only options.
Ostrom, working in political economy at Indiana University, didn't accept this. She went and looked. Across decades of fieldwork — lobster fisheries in Maine, irrigation systems in Nepal, alpine pastures in Switzerland, forest commons in Japan — she found communities that had been sustainably managing shared resources for centuries without either centralized control or privatization. The “tragedy” wasn't inevitable. Self-governing communities could and did succeed.
She won the Nobel Prize in Economics in 2009 for this work. Specifically, for the eight design principles she identified as characterizing the long-enduring commons institutions she studied:
The principles aren't a checklist for success — they're a description of what working commons institutions share. When all eight are present, sustainable governance is achievable. When key principles are missing, the system degrades toward Hardin's tragedy.
The AI security commons in 2026 is missing most of them.
Let's go through them. This is the part that suggests what governance could actually look like.
Principle 1: Clearly defined boundaries. Who is part of the AI security commons? Every AI lab? Every deployer? Every researcher? Every downstream user affected by a vulnerability? The answer is currently undefined. There is no membership concept, no community boundary, no list of who has standing to participate in disclosure decisions. This is the critical missing piece. Until you can answer “who is in the commons?”, none of the other principles can function — because each of them assumes there's a defined community to apply them to.
Principle 2: Proportional equivalence. The 90-day disclosure norm inherited from software was reasonable when patches deployed in days. It is incoherent for AI behavioral flaws, where there's no “patch” in the conventional sense — only model retraining or guardrail updates that take weeks. The disclosure timeline needs to vary by what kind of flaw is being disclosed. A traditional code vulnerability in an AI inference server: 90 days might still work. A novel jailbreak against a foundation model affecting an entire industry: longer window, different recipients, different urgency. The one-size disclosure rule fails here.
Principle 3: Collective-choice arrangements. The rules of AI vulnerability disclosure are currently set by platforms (HackerOne's terms), governments (CISA's CVD program guidelines), or vendors (each lab's own policy). The community of AI security researchers, the deployers who carry the operational risk, the users who absorb the consequences — none of them participate in rule-making at any structural level. Some forums exist (the ML Security Council, various industry working groups), but they're advisory rather than rule-setting.
Principle 4: Monitoring. The CVE system monitors software vulnerabilities. The AI Incident Database tracks deployed-system failures. But there is no comprehensive monitoring infrastructure for AI vulnerabilities specifically — no way to systematically see who's finding what, who's disclosing what, who's patching what, and where the gaps are. The arXiv paper “Coordinated Flaw Disclosure for AI” (2402.07039) makes this point directly: AI flaws are broader than traditional vulnerabilities, and we lack the infrastructure to track them.
Principle 5: Graduated sanctions. Right now the response to non-disclosure is binary: either the community judges you a bad actor (rare, with limited consequences) or it doesn't notice (common). There's no graduated framework — no equivalent of the EU's GDPR fining structure, no professional licensing that can be temporarily revoked, no community sanctions that escalate. The result is that the cost of non-disclosure is approximately zero, while the cost of disclosure can be substantial (legal exposure, vendor retaliation, lost competitive advantage).
Principle 6: Conflict resolution. Disputes arise constantly. Researcher and vendor disagree about severity. They disagree about timeline. They disagree about whether something even is a vulnerability. The resolution mechanisms today are ad hoc — HackerOne mediation if you're in their platform, but otherwise it's lawyers and Twitter. Cheap, rapid, accessible mechanisms barely exist.
Principle 7: Minimal recognition of rights. Some movement here. HackerOne's January 2026 Good Faith AI Research Safe Harbor explicitly protects researchers conducting AI security work from legal risk under participating programs. CISA's Coordinated Vulnerability Disclosure Program now explicitly includes AI systems per the 2025 Year in Review. These are the first formal recognitions that the AI security research community has a right to operate. It's exactly what Principle #7 looks like in practice. But recognition without the other seven principles is incomplete — it protects participants in a system that still needs to be built.
Principle 8: Nested enterprises. This is the second-most-critical missing piece. A working commons governance system has layered structure: individual project-level rules nest inside organization-level rules nest inside community-level rules nest inside ecosystem-level rules nest inside global norms. Each layer handles what it can handle; harder questions escalate. AI security today has no such structure. Each AI lab has its own policy. Each platform has its own program. Each government has its own framework. There is no nesting — there's just a fragmented landscape of incompatible local rules.
If you ask security people what AI vulnerability management most urgently needs, you'll hear about monitoring infrastructure, automated triage, faster patching, better incident response. These map onto Principles 4 and 5 — important, but downstream.
The diagnosis Ostrom's framework actually produces is different and harder. The most critical missing principle is #1: clearly defined boundaries. Until we can answer who is in the AI security commons — who has standing to participate, what entities are bound by the community's rules, what counts as membership — we cannot build any of the other principles meaningfully. Monitoring whom? Sanctioning whom? Resolving conflicts between whom?
This isn't a problem of better tools. It's a problem of community definition.
A useful comparison: the CVE system works because it has implicit boundaries. The “community” is software vendors, security researchers, and CERT teams who participate in MITRE's process. Membership is functional rather than formal — you're in if you participate. The implicit boundary is what allows the rest of the system to function. AI doesn't yet have even this implicit boundary, because the participating-entity set is much fuzzier (is a deployer in the AI security commons or just a consumer of it?) and the implicit norms haven't yet crystallized.
The second-hardest missing principle is #8: nesting. Even if we defined the commons membership, the current landscape has no layered governance. Each major AI lab is essentially a sovereign in its own security practices. There's no “above” layer to which lab-level rules can defer, and no “below” layer that handles project-specific concerns within a lab. Building nesting requires creating intermediate institutions that don't yet exist — something like an AI ISAC (Information Sharing and Analysis Center) with real authority, sitting between individual labs and government-level coordination.
The good news is that the easier principles are advancing. Principle #7 (recognition of rights) has HackerOne's safe harbor and CISA's AI VDP inclusion. Principle #3 (collective choice) has industry working groups starting to consolidate. Principle #4 (monitoring) has the AI Incident Database and various efforts toward a proper CVE-equivalent. But these are downstream pieces being built on a foundation — Principles #1 and #8 — that doesn't exist yet.
If you're building AI security infrastructure right now, here's what Ostrom's framework suggests about prioritization:
Don't start with another monitoring tool. Several exist. They're useful. None of them solve the underlying problem, because monitoring works only when there's a defined community whose behavior is being monitored against shared rules.
Don't start with a new disclosure platform. HackerOne, Bugcrowd, and others handle the platform layer adequately. What's missing isn't the platform — it's the community-level governance that platforms operate within.
Start with boundary definition. The most useful work right now is the most boring-sounding: helping the AI security community articulate who is in it. What counts as a participating AI lab? Who has standing to disclose a flaw? Who must accept disclosure? What is a deployer's obligation? These look like procedural questions; they are actually constitutive. Whoever builds the answer that the community adopts will have shaped the foundation of every subsequent piece of governance.
Build nesting institutions. The space for an AI-specific ISAC, with sectoral subgroups and clear escalation paths, is genuinely empty. The first credible attempt to occupy it will have outsized leverage. This is the most important governance vacuum in AI security today, and the most underestimated.
Recognize that we have 15 minutes. The traditional disclosure timeline is going to keep degrading. The governance system that works in 2030 will need to operate on a much shorter clock than the system designed in 1995 did. Building for the 15-minute window — not retrofitting the 90-day system — is the only path that doesn't collide with the actual threat model.
Ostrom's work suggests, against intuition, that this is achievable. The lobster fishermen of Maine built sustainable commons governance without computers, without lawyers, without state enforcement. They did it by getting eight principles right, in their order of dependence: define who's in; agree on proportional rules; let members participate in rule-making; monitor each other; sanction proportionately; resolve conflicts cheaply; secure external recognition; nest the whole thing in larger structures.
The AI security commons can be governed. It is not, structurally, a special case. What it requires is the unglamorous work of community formation that the security industry has been postponing — partly because each individual actor benefits from postponing it, which is exactly the dynamic Ostrom identified as the engine of tragedy.
The patch isn't a tool. The patch is a community willing to govern itself. The fifteen-minute window is the clock. Whether we build the governance before that window closes on something catastrophic is the open question of the next several years.
Ostrom showed it can be done. Now we have to do it.
Sources: Ostrom, Elinor. Governing the Commons: The Evolution of Institutions for Collective Action (1990). Carnegie Mellon Software Engineering Institute, “Protecting AI from the Outside In: The Case for Coordinated Vulnerability Disclosure” (February 2025) — the 44,900-AI-projects statistic. Palo Alto Networks Unit 42, “2026 Threat Intelligence Report” — the 15-minute exploitation window. arXiv: 2402.07039, “Coordinated Flaw Disclosure for AI: Beyond Security Vulnerabilities.” CISA, “2025 Year in Review” — AI inclusion in Coordinated Vulnerability Disclosure Program. HackerOne, “Good Faith AI Research Safe Harbor” (January 2026). SC Media, “Responsible vulnerability disclosure in 2025: why the debate still matters.” P2P Foundation Wiki, “Elinor Ostrom's Eight Commons Governance Design Principles.” Mozilla Foundation, “A Practical Framework for Applying Ostrom's Principles to Data Commons Governance” — data-commons precedent, not AI security.
The patch isn’t a tool. The patch is a community willing to govern itself.
Ostrom’s prescription is layered: boundary definition, proportional rules, collective choice, monitoring, sanctions, dispute resolution, recognition, nested enterprises. The Agent Trust Stack is the open-source toolkit for building that nesting in software: Chain of Consciousness for the cryptographic provenance that makes participation auditable; Agent Rating Protocol for the reputation signals that make graduated sanctions possible; the integrated agent-trust-stack meta-package for the layered governance an AI ISAC would actually need. Boundary definition is community work. The technical substrate it sits on is ours.
Hosted CoC · Verify a chain · pip install agent-trust-stack · npm install agent-trust-stack