How to prepare vulnerability disclosure for AI-generated or AI-assisted reports

Introduction

A researcher submits a detailed report: a description of the flaw, a severity rating, a code snippet and an alleged proof of concept. The text looks consistent. On investigation, though, the team finds that the function cited does not exist in that version, the behavior depends on a configuration that is missing, and the proof of concept was never run.

Another report, written with help from the same category of tool, identifies a real authorization flaw between customers.

That is the challenge: the quality of the writing is no longer a good indicator of the quality of the evidence.

Artificial intelligence can help find vulnerabilities, organize results and lower communication barriers. It can also produce incorrect hypotheses that look like verified conclusions. The disclosure process has to absorb both cases without wasting engineering capacity or discarding legitimate findings.

This article presents a flow for intake, triage, reproduction and coordinated disclosure. A lab on Google Kubernetes Engine — GKE — serves as an isolated environment to validate evidence. Reinforcement Learning — RL — appears only as a research possibility for triage agents, kept separate from the operational process.

What coordinated vulnerability disclosure is

Coordinated Vulnerability Disclosure — CVD — organizes the interaction between researchers, product owners and, when necessary, vendors and external coordinators.

The work involves receiving the report, assessing its validity, fixing the problem and communicating useful information to affected users. Coordination matters most when a flaw spans several products or organizations. The CERT Coordination Center guide presents this process as an activity with multiple participants and responsibilities.

Three concepts should be kept apart:

An organization can run a VDP and CVD without offering rewards.

For AI-assisted reports, the main change is at the input: the process has to tell observation, hypothesis and conclusion apart, preserving the accountability of whoever submits and whoever validates.

Key concepts

Reproducible evidence

A set of information that lets someone verify the reported behavior: version, configuration, preconditions, procedure and observed result.

A Proof of Concept — PoC — can help, but it does not have to be a full exploit. A minimal test or a demonstrable code analysis can be enough to start the investigation.

The team should also not require access to real third-party data to prove impact.

Provenance and review

Record whether AI helped with discovery, test code, analysis or only the writing. This informs the review; it does not determine validity.

What matters is knowing which claims a person verified and which remain hypotheses. There is no need to demand the full prompt history, which may contain confidential information.

Severity and confidence

Severity expresses impact and exploitation conditions. Confidence expresses the strength of the available evidence.

A report can claim critical impact and still have low confidence. Another can prove a flaw of limited impact.

The Common Vulnerability Scoring System — CVSS — can support the technical rating, but the vector must be reviewed against the confirmed behavior. A score suggested by AI does not replace that analysis.

Untrusted content

Text, attachments, URLs and code sent by researchers are untrusted input.

That includes instructions embedded to manipulate a Large Language Model — LLM. OWASP describes this problem as _prompt injection_, including indirect attacks in documents and external content.

Prepare the policy before you automate

The public policy should state:

• Which products, versions and environments are in scope.
• Which tests are allowed and which require specific authorization.
• How to submit sensitive information.
• Which evidence helps the analysis.
• How status updates and public disclosure work.
• What rules exist for automation and AI use.

One possible operational wording is:

AI-assisted reports are accepted. Distinguish observed results from hypotheses, state the steps you verified and provide enough evidence for analysis. Do not run tests outside the authorized scope or send third-party data that is not needed to prove the issue.

This wording is a proposal to adapt, not ready-made legal text.

Rules on good-faith research must reflect what the organization can actually authorize. The policy cannot promise permissions over third-party infrastructure.

Publish a security.txt

RFC 9116 defines a format for publishing security contacts and references at /.well-known/security.txt. The Contact and Expires fields are required; the file must be served over HTTPS.

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-04-07T23:59:59Z
Preferred-Languages: pt-BR, en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/disclosure-policy

Replace the domain, contacts and expiry date. Serve the file as text/plain and monitor its expiration.

The file makes it easier to find the right channel; the research and handling criteria belong in the policy it references.

Architecture and how it works

A suitable architecture keeps intake available and controls the investigation work separately.

Intake
   ↓
Registration and quarantine
   ↓
Scope and evidence triage  ←───────────────────┐
   ↓                                           │
Next action ──→ Request more information ──────┘
   ↓
Isolated reproduction
   ↓
Human validation
   ↓
Fix and retest
   ↓
Coordinated disclosure

The portal receives the report, assigns an identifier and stores attachments with restricted access. A queue decouples intake from the analysis workers.

Deterministic checks verify size, format and fields. AI can produce summaries or suggest duplicates, but its answers remain recommendations.

Reproduction happens in an authorized environment. Afterwards, an owner confirms validity, impact and priority. Engineering prepares the fix; the retest checks both that the flaw is gone and that nothing regressed.

The model must not, on its own, control code execution, closing a report, publication or access to internal systems.

Report template: turn text into verifiable information

A structured form reduces repeated questions:

{
  "title": "Possible cross-organization access on the documents endpoint",
  "asset": "Authorized staging API",
  "affected_version": "2026.10.1",
  "preconditions": [
    "Two test organizations",
    "Authenticated user from organization A",
    "Synthetic document owned by organization B"
  ],
  "steps": [
    "Create the document in organization B",
    "Request the document using organization A's session",
    "Record the HTTP status and sanitized content"
  ],
  "expected_result": "Access denied",
  "observed_result": "Synthetic document returned",
  "claimed_impact": "Possible cross-organization read",
  "ai_assistance": {
    "used": true,
    "purpose": ["writing", "test suggestion"],
    "human_verified_steps": true
  },
  "evidence": [
    {
      "type": "sanitized_http_transcript",
      "attachment_id": "evidence-001"
    }
  ]
}

This is a proposed application contract, not an official standard.

Keep claimed_impact separate from the impact confirmed by the team. Validate types and lengths on the backend and keep a channel for reports that do not fit the form.

A day-to-day example: a multi-tenant API

Consider a fictional company with APIs on Kubernetes, PostgreSQL and processing workers.

Before, every report became an engineering ticket with the priority suggested by the sender. Long reports consumed hours even when the version and preconditions were missing.

The company starts to apply three steps:

1. Check scope and the information available.
2. Identify evidence gaps.
3. Route verifiable reports to the technical owner.

In the cross-organization access example, the team reproduces the behavior with two synthetic accounts. It finds that the query filters on the document identifier but not on the organization bound to the session.

The fix adds the authorization check and regression tests for cross-organization access.

The expected outcome is a more objective investigation. The existence of the vulnerability was established by observed behavior; AI helped organize the report.

This scenario is didactic and does not represent an incident or a measured result.

GKE lab: validate with isolation

GKE Sandbox and Agent Sandbox

GKE Sandbox provides additional isolation for workloads. The documentation lets you request the gVisor runtime through runtimeClassName: gvisor. Agent Sandbox, in turn, adds its own features for managing agent environments and has a specific enablement procedure.

The lab below uses a Kubernetes Job with GKE Sandbox. It does not install the Agent Sandbox controller nor implement a full RL environment.

For one-off reproductions, this approach reduces operational components. Persistent agent environments may justify adopting the dedicated controller.

Prerequisites

Use a lab cluster separate from production, with:

• A gVisor-compatible node pool.
• A network implementation that enforces NetworkPolicy.
• Approved images and synthetic data.
• Identities with no access to production projects.

On an existing GKE Standard cluster, the documentation shows how to create a pool with --sandbox=type=gvisor. Also keep a node pool suited to the system components that do not use the sandbox.

gcloud container node-pools create disclosure-sandbox \
  --project=YOUR_PROJECT \
  --cluster=YOUR_CLUSTER \
  --location=YOUR_REGION_OR_ZONE \
  --sandbox=type=gvisor

Adapt the identifiers. This command creates billable infrastructure; sizing, autoscaling and node identity must be defined for the lab.

Complete YAML for a controlled test

apiVersion: v1
kind: Namespace
metadata:
  name: disclosure-lab
  labels:
    pod-security.kubernetes.io/enforce: restricted
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: reproduction-runner
  namespace: disclosure-lab
automountServiceAccountToken: false
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: disclosure-lab
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: approved-test
  namespace: disclosure-lab
data:
  test.py: |
    import json
    import sys

    # Synthetic pipeline test, not the reproduction of a real flaw.
    result = {
        "case_id": "LAB-001",
        "status": "completed",
        "synthetic_data": True
    }
    print(json.dumps(result), flush=True)
    sys.exit(0)
---
apiVersion: batch/v1
kind: Job
metadata:
  name: reproduction-lab-001
  namespace: disclosure-lab
spec:
  backoffLimit: 0
  activeDeadlineSeconds: 120
  ttlSecondsAfterFinished: 600
  template:
    metadata:
      labels:
        app: reproduction-runner
    spec:
      runtimeClassName: gvisor
      serviceAccountName: reproduction-runner
      automountServiceAccountToken: false
      restartPolicy: Never
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: runner
          image: python:3.12-slim
          command:
            - python
            - -I
            - -B
            - /tests/test.py
          resources:
            requests:
              cpu: 250m
              memory: 128Mi
            limits:
              cpu: "1"
              memory: 256Mi
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
          volumeMounts:
            - name: tests
              mountPath: /tests
              readOnly: true
            - name: temporary
              mountPath: /tmp
      volumes:
        - name: tests
          configMap:
            name: approved-test
        - name: temporary
          emptyDir:
            sizeLimit: 64Mi

The manifest creates a namespace, an identity with no automatic token, an isolation policy and a time-limited Job. The script only validates that the pipeline runs.

The main fields are:

• runtimeClassName: requests execution under gVisor.
• backoffLimit: 0: prevents the test from being retried automatically.
• activeDeadlineSeconds: limits the duration.
• ttlSecondsAfterFinished: allows the finished Job to be cleaned up.
• requests and limits: guide scheduling and cap resources.
• securityContext: restricts privileges and writes.
• default-deny: isolates ingress and egress for the selected Pods.

NetworkPolicies depend on network support, and their permissions are additive: another policy can allow traffic. They do not replace all network and identity controls.

Adapt the case name, resources and the reviewed script. In production, pin the image to an approved digest, apply quotas and export evidence before cleanup.

To test an API, create a synthetic replica and allow only the traffic that is needed. Do not open unrestricted internet access to accommodate a PoC.

Production: availability without widening permissions

The intake service should run separately from the executors.

Keep multiple portal replicas, a durable queue and persistent evidence storage. Workers must be idempotent: receiving the same message again must not trigger duplicate tests.

Use distinct queues for text analysis and reproduction. When there are signs of active exploitation, route the case to incident response without waiting for normal processing.

Availability and trust are different problems. A portal can be highly available and still forward incorrect claims. Technical validation remains necessary.

Process and infrastructure security

Protect the triage system itself

An attachment can try to instruct the agent to reach an external address or reveal internal information.

Keep authorization and tool validation outside the model. OWASP recommends least privilege, treating outputs as untrusted and specific controls on tool actions. A protective prompt on its own does not establish that boundary.

Apply:

• RBAC — role-based access control — scoped per component.
• Separate ServiceAccounts for intake, analysis and execution.
• IAM — identity and access management — with no production permissions in the lab.
• Secrets kept out of prompts, attachments and ConfigMaps.
• Encryption in transit and at rest.
• Retention and auditable access to evidence.

Do not automatically download every URL received. That can expose internal services to Server-Side Request Forgery — SSRF. Validate destinations, redirects and resolved addresses.

Development vs production

A namespace helps organize workloads, but on its own it is not a sufficient boundary for running hostile code.

Troubleshooting

The Job stays in Pending

Possible causes: missing runtime, lack of capacity, quotas or scheduling constraints.

kubectl get runtimeclass
kubectl get pods -n disclosure-lab
kubectl describe job reproduction-lab-001 -n disclosure-lab
kubectl get events -n disclosure-lab \
  --sort-by=.metadata.creationTimestamp

Read the events before changing resources or removing restrictions.

The test ends with no result

kubectl logs -n disclosure-lab \
  job/reproduction-lab-001

kubectl get job reproduction-lab-001 \
  -n disclosure-lab -o yaml

Look into a timeout, a script failure or a memory limit. An execution error means an inconclusive result, not an invalid report.

The test cannot reach the synthetic API

kubectl get networkpolicy -n disclosure-lab -o yaml
kubectl get pods -n disclosure-lab --show-labels

Check selectors, port and ingress and egress permissions. In the example, the block is intentional.

Legitimate reports are closed incorrectly

Review closed cases, recorded reasons and decisions after model changes. Keep a human appeal path and treat automatic classifications as proposals.

Observability

Use Prometheus for metrics, Grafana for dashboards, Loki for sanitized logs and OpenTelemetry to instrument the path between portal, queue and workers.

Useful metrics include:

• Volume per report state.
• Age of the oldest item in the queue.
• Time to acknowledge receipt.
• Time to reproduction and to fix.
• Inconclusive runs.
• Automatic decisions reverted on review.
• Cost per confirmed vulnerability.

Names such as disclosure_reports_total and disclosure_reproduction_duration_seconds are instrumentation proposals, not native metrics.

Do not use report identifiers as Prometheus labels: that increases cardinality. Use correlation in logs and traces, without recording tokens, sensitive payloads or full attachments.

Alert on an aging queue, channel unavailability, persistence failures and a rise in reverted decisions.

Costs and FinOps

Cost combines infrastructure, model consumption and specialists' time.

Run cheap validations before AI calls. Use text analysis to organize information and reserve reproduction for the cases that need it.

Limit calls, tokens, runs and duration per case. Avoid resending whole attachments in every interaction.

On Kubernetes, oversized requests waste capacity; too little memory makes tests inconclusive. Measure real consumption before tuning.

Spot can serve interruptible, idempotent reproductions. Intake, queue and evidence components need an appropriate availability strategy, often with On-Demand capacity.

The core metric is cost per validated finding, tracked alongside triage quality.

Where RL can contribute

RL can be researched in a separate environment to teach agents to choose between requesting more information, recommending reproduction or escalating a report.

Use sanitized historical cases, reviewed labels and separate training and evaluation sets. The agent must not be given access to the original assets.

The reward has to account for precision, investigation cost and missed real vulnerabilities. Rewarding only the number of closures can produce an agent that is efficient at dismissing reports.

This lab is research. Operational adoption depends on evaluation and execution controls.

Best practices and what to avoid

Standardize states, owners and decision reasons. Preserve original evidence and record human and automated interpretations separately.

Avoid:

• Rejecting reports just because they used AI.
• Confusing the length of the text with evidence.
• Running attachments directly in CI/CD — continuous integration and delivery.
• Granting cluster-admin to the triage system.
• Treating a timeout as proof that the flaw does not exist.
• Publishing details automatically.
• Promising a fix deadline without assessing impact and dependencies.

Deduplication should suggest relationships between cases and allow review. Similar reports may involve different versions or causes.

When to use it and when to keep it simple

The full flow suits organizations with multiple products, a recurring volume of reports and a need for controlled reproduction.

For a small team, a monitored mailbox, a public policy, a simple form and a named owner may be enough.

Kubernetes is justified when isolated execution needs scale and standardization. RL is justified when there is a research question and suitable data for evaluation.

Practical summary

Before expanding automation:

• Publish the scope and a contact channel.
• Separate hypotheses from observed results.
• Require evidence proportional to the case.
• Restrict models and tools to least privilege.
• Reproduce in an authorized, isolated environment.
• Keep inconclusive results.
• Review decisions and coordinate communication.

Conclusion

Preparing vulnerability disclosure for AI-assisted reports requires clear evidence criteria and control over the actions that have effects.

AI can speed up reading, organizing and comparing reports. Sandboxes can make reproduction more controlled. Technical confirmation, the fix and communication still depend on accountable owners and verifiable decisions.

In a Platform Engineering strategy, this process turns external reports into traceable work: every finding has evidence, every run has limits and every publication has a technical justification.

References

• CERT Guide to Coordinated Vulnerability Disclosure
• RFC 9116 — security.txt
• OWASP — LLM Prompt Injection Prevention
• Google Cloud — GKE Sandbox
• Google Cloud — Enable Agent Sandbox on GKE
• Kubernetes — Network Policies