Patch the Planet: What Agent-Scale Vulnerability Discovery Requires from Coordinated Disclosure

OpenAI announced Patch the Planet, a coordination platform for vulnerabilities discovered by autonomous agents. The announcement states it will connect security researchers, maintainers, and incident responders to address critical vulnerabilities across open source. Full implementation details are not yet public, but the coordination problem is clear: traditional bug bounty platforms assume human researchers submit findings at human scale. Agents operate continuously, produce findings in bulk, and lack the context to route reports correctly.

This creates a new orchestration challenge. When Third Moment Research recently ran 10,000 agents for 36+ hours on security tasks, the potential for agent-discovered vulnerabilities at scale became concrete. If even a fraction of those agents find legitimate issues, existing CVE workflows will not scale. The question is what infrastructure primitives are needed to triage, deduplicate, and route agent-discovered vulnerabilities without overwhelming maintainers or creating disclosure bottlenecks.

The Coordination Problem

Agents discover vulnerabilities differently than humans. A human researcher understands organizational boundaries, reads SECURITY.md files, and knows when to contact CERT. An agent sees code, runs static analysis, fuzzes inputs, and generates findings. It does not inherently know:

• Which GitHub org owns the vulnerable package
• Whether the maintainer wants reports via email, issue tracker, or security advisory
• If the vulnerability is already known or patched in an unreleased branch
• Whether the finding duplicates something another agent submitted minutes earlier

Traditional disclosure workflows rely on human judgment at every step. Agent-scale discovery requires a routing layer that understands package ecosystems, maintainer preferences, and vulnerability deduplication without requiring the agent to parse social context.

Required Architecture: Routing and Triage

Any platform handling agent-discovered vulnerabilities at scale must solve four core problems:

1. Routing: Map a vulnerable artifact (npm package, PyPI module, container image) to the correct maintainer contact
2. Deduplication: Identify when multiple agents report the same vulnerability
3. Prioritization: Assign severity and exploitability scores without human review for every report
4. State management: Track disclosure timelines across agents, maintainers, and incident responders

Here is a plausible flow for such a system:

class VulnerabilityReport:
    def __init__(self, agent_id, artifact, finding):
        self.agent_id = agent_id
        self.artifact = artifact  # e.g., "lodash@4.17.20"
        self.finding = finding    # PoC, description, impact
        self.fingerprint = self._compute_fingerprint()
        self.state = "submitted"
        self.assigned_maintainer = None
        self.disclosure_deadline = None
    
    def _compute_fingerprint(self):
        # Hash artifact + vulnerability type + affected code location
        # to detect duplicates across agents
        return hashlib.sha256(
            f"{self.artifact}:{self.finding.vuln_type}:{self.finding.location}".encode()
        ).hexdigest()

class DisclosureOrchestrator:
    def __init__(self, routing_db, dedup_cache, timeline_enforcer):
        self.routing_db = routing_db
        self.dedup_cache = dedup_cache
        self.timeline_enforcer = timeline_enforcer
    
    def ingest(self, report: VulnerabilityReport):
        # Step 1: Check for duplicates
        if self.dedup_cache.exists(report.fingerprint):
            return self._merge_with_existing(report)
        
        # Step 2: Route to maintainer
        maintainer = self.routing_db.lookup(report.artifact)
        if not maintainer:
            return self._escalate_to_triage_queue(report)
        
        # Step 3: Set disclosure timeline
        report.disclosure_deadline = self.timeline_enforcer.calculate(
            severity=report.finding.severity,
            maintainer_sla=maintainer.response_sla
        )
        
        # Step 4: Notify maintainer
        self._send_notification(maintainer, report)
        report.state = "notified"
        return report

The routing database is the hardest component. It must map artifacts to maintainers across package ecosystems (npm, PyPI, RubyGems, Maven, crates.io), handle ownership transfers, and respect maintainer preferences for contact methods. This is a graph problem requiring traversal from artifact to package to repository to organization to maintainer, with handling for ambiguous or missing paths.

Deduplication Logic

When thousands of agents run security scans, they will find the same vulnerabilities. Deduplication must happen before maintainers see reports. The fingerprinting function must balance precision (do not merge distinct vulnerabilities) with recall (do merge duplicates).

Fingerprint Component	Why It Matters	Classification Variance Risk
Artifact identifier	Core identity	Low (exact match)
Vulnerability type	SQL injection vs. XSS	Medium (agents may classify differently)
Code location	Line number or function	High (agents may report different entry points for same root cause)
Exploit primitive	What the attacker controls	Medium (PoCs vary but root cause is same)

The dedup cache needs a time window. If Agent A reports a vulnerability at 10:00 and Agent B reports the same issue at 10:05, they should merge. If Agent C reports it three weeks later (after a patch), that is a regression and should not merge.

State Transitions and Timeline Enforcement

Coordinated disclosure follows a state machine:

submitted → triaged → acknowledged → patched → disclosed

Agents lack context to enforce this flow. They submit findings and move on. The platform must enforce timelines without human intervention for every report:

• 90-day disclosure deadline (standard for critical vulnerabilities)
• Maintainer response SLA (7 days to acknowledge, 30 days to patch)
• Escalation triggers (if maintainer does not respond, escalate to CERT or public disclosure)

A timeline enforcer would run as a scheduled job:

class TimelineEnforcer:
    def check_deadlines(self):
        overdue = self.db.query(
            "SELECT * FROM reports WHERE state != 'disclosed' AND disclosure_deadline < NOW()"
        )
        for report in overdue:
            if report.state == "notified" and not report.maintainer_acknowledged:
                self._escalate_to_cert(report)
            elif report.state == "acknowledged" and not report.patch_available:
                self._public_disclosure(report)

This is where agent-discovered vulnerabilities break traditional workflows. A human researcher can negotiate timeline extensions. An agent cannot. The platform needs policy rules that handle edge cases: abandoned projects, maintainers on vacation, disputes over severity.

Authentication and Authorization

Agents submitting vulnerability reports create a new attack surface. An adversary could:

• Flood the platform with fake reports to DoS maintainers
• Submit poisoned PoCs that exploit the triage system
• Impersonate agents to gain access to pre-disclosure vulnerability data

The platform needs agent authentication that does not rely on API keys (which leak) or OAuth (which agents cannot complete). A likely approach:

• Agent attestation: Each agent signs reports with a private key, and the platform verifies the signature against a registry of known research agents
• Rate limiting per agent: Cap submissions per agent per hour to prevent floods
• Sandbox execution: Run agent-supplied PoCs in isolated containers with network egress blocked

The authorization model is trickier. Who gets to see pre-disclosure vulnerability data?

• The submitting agent (for follow-up questions)
• The assigned maintainer (to patch)
• Incident responders (if escalated)
• Other agents (for deduplication)

Sharing data with other agents is risky. If Agent A discovers a 0-day and Agent B sees it in the dedup cache, Agent B’s operator now has pre-disclosure knowledge. The platform must enforce read isolation between agent operators while allowing the system to deduplicate.

Observability and Failure Modes

The platform needs metrics to detect when the coordination layer breaks:

• Routing failures: Percentage of reports that cannot be mapped to a maintainer
• Deduplication accuracy: False positive rate (merged distinct vulns) and false negative rate (duplicate reports reaching maintainers)
• Timeline violations: Reports that miss disclosure deadlines
• Maintainer response rate: Percentage of reports acknowledged within SLA

Failure modes to watch:

1. Agent spam: Poorly tuned agents submit low-quality findings faster than triage can filter them
2. Maintainer burnout: High-profile projects receive hundreds of agent reports and stop responding
3. Disclosure leaks: Pre-disclosure data leaks via agent logs or dedup cache side channels
4. False negatives: Agents miss critical vulnerabilities because they optimize for volume over depth

The platform needs circuit breakers. If routing failures exceed 20%, pause agent ingestion and alert the ops team. If a single maintainer receives more than 50 reports in 24 hours, throttle submissions and escalate to human triage.

Likely Deployment Shape

A platform like Patch the Planet would likely run as a multi-tenant SaaS with per-agent isolation. The architecture would need:

• Ingestion API: Agents POST reports via HTTPS with signed payloads
• Routing service: Looks up maintainers in a graph database (artifact → package → org → maintainer)
• Dedup engine: Runs similarity matching on incoming reports against a time-windowed cache
• Notification service: Sends emails, GitHub issues, or Slack messages to maintainers
• Timeline enforcer: Scheduled job that checks deadlines and triggers escalations
• Audit log: Immutable record of all state transitions for post-incident review

The routing database is the bottleneck. It needs to handle:

• 100,000+ open source packages
• Ownership changes (maintainer transfers, org renames)
• Maintainer preferences (email vs. issue tracker vs. security advisory)
• Multi-party ownership (Linux kernel has 1,000+ maintainers)

This is a graph problem. The database needs to traverse artifact → package → repository → org → maintainer and handle cases where the path is ambiguous or missing.

Technical Verdict

A platform like this is needed when:

• You operate agents that perform security research at scale
• You need to coordinate disclosure across multiple maintainers and ecosystems
• You want to enforce disclosure timelines without manual tracking for every report
• You need deduplication to prevent maintainer overload

Traditional approaches still work when:

• Your agents discover fewer than 10 vulnerabilities per week (bug bounty platforms handle this volume)
• You need custom disclosure policies that do not fit 90-day timelines
• Your vulnerabilities require deep human context to triage (agents cannot explain nuance)
• You operate in a regulated environment with specific disclosure requirements (finance, healthcare)

The core problem is real: agent-scale security research breaks human-scale coordination workflows. But any solution introduces new risks. Agents cannot negotiate, explain context, or handle edge cases. The platform must encode policy decisions that were previously left to human judgment. If those policies are wrong, the platform becomes a disclosure bottleneck instead of an accelerator.

Watch for routing database staleness, deduplication false positives, and maintainer burnout. The success metric is not volume of reports. It is time-to-patch for critical vulnerabilities and maintainer response rate. If maintainers start ignoring reports because agents flood them with noise, the coordination layer has failed.

Source Links

• OpenAI: Coordinated Disclosure of Critical Vulnerabilities