Disclosure, Law, Careers, and What's Next

After this lesson, you will be able to read a vulnerability disclosure policy before testing, prepare a useful report, describe the legal limits of security research in broad terms, plan a learning path toward AI red teaming, and follow changes in the field without treating a tool, certificate, or framework as a guarantee of skill. All examples below are fictional unless a public policy or standard is named.

AI red teaming happens in a professional setting with real people, systems, contracts, and responsibilities. A useful finding can help a team fix a weakness. The way a researcher reaches the finding and shares it matters just as much as the technical detail. Good judgment includes knowing when to stop, what evidence to preserve, who to contact, and which questions belong with a lawyer or program owner.

This course uses a fictional HelpDesk Bot and synthetic data. The reporting examples here are templates for learning. They do not authorize testing against any live system.

Responsible disclosure starts with permission

A vulnerability disclosure program (VDP) is a published process that tells people how an organization accepts reports about security weaknesses. A bug bounty program is a program that may offer rewards for eligible findings, according to its own rules. Some organizations operate a VDP without paying a bounty. A bounty does not expand testing beyond the assets and methods named by the program. HackerOne's VDP and bug bounty comparison describes the distinction between reporting procedures and reward programs.

Before you run a test, read the current policy from the organization that controls the target. Check the named domains, applications, accounts, models, and APIs. Look for excluded assets, allowed methods, test windows, data handling rules, rate limits, contact methods, and instructions for stopping. Confirm whether the policy covers the specific activity you have in mind. If a boundary is unclear, ask the program owner in writing and wait for an answer. Do not infer permission from a public login page, a bug bounty logo, a past report, or a colleague's approval. The course's authorization and rules of engagement guide has a fuller scoping checklist.

Coordinated vulnerability disclosure (CVD) is a process in which a reporter and the affected organization work together to validate a report, reduce risk, and decide how and when to share details. The reporter gives the owner a chance to understand and address the issue. The organization acknowledges the report, investigates it, and communicates about status and disclosure. If multiple products or vendors are affected, coordination may involve more than one owner. ISO/IEC 29147 describes vendor practices for receiving and disclosing vulnerability reports; ISO/IEC 30111 describes how vendors process and remediate them. Both standards were current when checked on 6 November 2026, and ISO lists work to revise them, so check their status again before using them as a process reference.

A public policy is useful because it makes expectations visible. For example, the U.S. Department of Justice's VDP identifies its scope, allowed testing, reporting details, and activity that must stop. That policy applies to DOJ-managed systems under its own conditions. It does not grant permission on other federal, state, private, or third-party systems. Treat every program as its own agreement and check the latest version before acting.

Stop at the minimum proof

The goal is to show a real security consequence with as little access and change as possible. Stop when the issue is confirmed. Do not continue to inspect unrelated records, test other users, increase access, create persistence, or collect more data just to make a report look stronger. Avoid actions that could disrupt service, expose personal information, or change a real user's account. If unexpected sensitive information appears, do not copy or share it. Stop and use the contact and handling instructions in the policy.

For an AI application, the smallest useful proof might be a synthetic canary appearing in an answer, a dummy tool action that happened without the required approval, or a controlled test showing that a role can reach a resource it should not. Use a test account and fake records when the policy allows them. In a model test, record the model or application version, the test setup, and the observed system behavior. Keep prompts and responses to the minimum needed for reproduction, and follow the program's data-retention instructions.

The response may be variable. One successful attempt does not automatically show how often a behavior occurs or how much damage it could cause. Describe the exact run and repeat count. Separate what you observed from what you infer. For example, write, "In two of five runs against the named staging build, the synthetic marker for Account B appeared in Account A's response." Do not turn that into a claim about every user, model, or release.

Write a report an owner can act on

A useful report lets the recipient understand the affected system, reproduce the minimum proof, judge impact, and plan a fix. Follow the program's submission fields when it provides them. A concise report can include:

1. Title and summary: a short description of the affected behavior and why it matters.
2. Target and scope: the in-scope product, URL or interface, environment, account role, and version if known.
3. Prerequisites: the test account, configuration, and safe setup required to reproduce it.
4. Steps: the smallest sequence that reliably shows the issue, with test values clearly labeled as synthetic.
5. Expected and observed behavior: what the access control or model-integrated application should do and what happened instead.
6. Impact and limits: the data or action at risk, who could be affected, conditions required, and what you did not test.
7. Evidence: a small redacted screenshot, event identifier, or response excerpt, only if the policy allows it and the evidence is needed.
8. Suggested next step: a practical mitigation direction, such as checking permission at the tool boundary, without claiming to know the owner's full architecture.

For example, a fictional report might say: "The staging HelpDesk Bot returned the planted marker TICKET-B-CANARY to a synthetic Account A when asked for a synthetic Account B ticket. This occurred in two of five runs on build staging-42. No real records were used. The result suggests the retrieval boundary may not be applying the caller's tenant check. Recheck ownership in the server-side retrieval function and add a regression case for this role and object pair." The example describes an illustrative outcome, not a test performed for this lesson.

Include enough detail to be useful while protecting the people and data involved. Redact tokens, session cookies, private customer information, and unrelated records. If a report contains a secret by accident, tell the recipient where it appears without repeating it in email or a public issue. Keep a private copy only when the policy and your organization's process allow it. Store notes in an approved location and remove them when the retention rule says to do so.

Severity is a reasoned estimate of impact and likelihood under stated conditions. The recipient may use a different rating system or reach a different conclusion. Explain the access needed, affected boundary, possible consequence, and observed reliability. Do not threaten publication or demand payment in exchange for silence. A bounty amount, acknowledgment, or public credit follows the program's rules and is not guaranteed unless those rules say so.

Understand the legal and policy boundaries

This section is general awareness, not legal advice. Computer misuse laws vary by country and can depend on where the researcher, system, data, and affected people are located. Contract terms and organizational policies can add separate obligations. If you are uncertain about authorization, employment rules, disclosure, privacy, or cross-border activity, stop and consult a qualified lawyer or your organization's security and legal contacts.

The U.S. Department of Justice publishes a charging policy for the Computer Fraud and Abuse Act (CFAA). It says that good-faith security research meeting its stated conditions should not be charged under that policy. The policy guides U.S. federal prosecutors; it is not a general permission slip, a change to every law, or a guarantee about civil claims or another authority's actions. The DOJ explains that a claim of research does not excuse bad-faith activity such as extortion. The UK Computer Misuse Act 1990 is a separate example of a national law that addresses unauthorized access and modification. These examples show why a person's location and the system's location matter. They illustrate two jurisdictions and leave many local laws and legal questions unaddressed.

Terms of service and testing policies also need careful reading. A provider may allow certain testing on named assets and forbid testing of other services, customer accounts, denial of service, social engineering, or access to data. A program may offer a safe-harbor statement for activity that follows its rules. Scope still matters. HackerOne's help documentation, for example, explains that its safe-harbor options do not change which assets a program includes. That is an example of a platform's policy, not legal protection that applies to every program. Read the service's current terms alongside its security policy, since those documents may be separate.

Use the written authorization and rules of engagement from the actual owner. Record the allowed targets, test accounts, methods, time window, data boundaries, stop conditions, reporting route, and disclosure process. If someone asks you to test a related service that is absent from the scope, pause until an authorized owner confirms the change. If a live test produces an unexpected effect, stop and notify the contact named in the agreement. The course's findings and fixes guide covers how to track remediation and retesting.

Build a career through visible skills

There is no single job title or route into AI red teaming. Related work appears in application security, penetration testing, product security, AI evaluation, machine-learning security research, security engineering, and governance. Some roles focus on finding weaknesses; others build the harnesses, controls, evaluation methods, or response processes that help a team understand and reduce risk.

The NICE Framework from the U.S. National Institute of Standards and Technology describes cybersecurity work through tasks, knowledge, skills, competency areas, and work roles. It is a shared vocabulary for learning and hiring, not a list of job titles or a guarantee that an employer uses those labels. Compare the tasks in a job posting with what you can demonstrate. A red-team role might ask for engagement planning, web or API testing, scripting, evidence handling, and clear reporting. An AI evaluation role may add model behavior analysis, test-set design, statistics, retrieval, or tool-boundary review.

Build foundations in the areas the work joins together:

• Application security: HTTP, APIs, identity, access control, software architecture, and secure development.
• AI and machine learning: model inputs and outputs, training and inference, retrieval, evaluation, uncertainty, and where AI components sit in an application.
• Testing practice: scope, test design, repeatable cases, safe evidence collection, failure analysis, and regression testing.
• Communication: concise reports, risk explanations for different audiences, and collaboration with developers, operations, privacy, and legal teams.

Choose a starting point based on your current strengths. A software developer can learn threat modeling and security testing, then study the model and data paths in an AI application. A security tester can deepen knowledge of retrieval, evaluation, and tool-enabled systems. A data or ML engineer can practice application authorization, infrastructure boundaries, and responsible disclosure. You do not need to claim expertise across every domain before contributing to a team.

Choose practice and credentials deliberately

Use environments designed for training. PortSwigger's Web Security Academy offers online material and interactive web security labs. OWASP Juice Shop is an intentionally insecure application for training and Capture the Flag exercises. Both help build general application testing habits; they are not substitutes for testing an AI system with permission. Run a local lab, follow its terms, and keep practice inside the named environment.

For AI-specific learning, OWASP's GenAI Red Teaming Manual, version 1.0, was published on 20 October 2026. It describes a method for evaluating models, applications, multimodal interfaces, and agents, including planning, attack-surface mapping, reporting, and remediation. The course's guide to red teaming LLM applications and agents applies those ideas to a fictional HelpDesk Bot plan. MITRE ATLAS maintains a knowledge base of AI-related adversary tactics and techniques. NIST's adversarial machine learning taxonomy gives shared terminology for attacks and mitigations across predictive and generative systems. These references are evolving; revisit them as part of study rather than treating one snapshot as a permanent checklist.

Certificates can help structure study or show that you passed a particular assessment. They vary in cost, prerequisites, hands-on content, renewal rules, and recognition by employers. Examples in penetration testing include OffSec's OSCP+ and CREST's Registered Penetration Tester certification. Their current exam objectives and terms were checked on 6 November 2026. Treat the examples as options to compare against your goals, region, and budget. Review the issuer's current material, ask whether the credential fits the roles you want, and weigh its cost against lab practice, mentoring, or work samples. Hiring needs differ by employer and region.

A small portfolio can show how you work without exposing a real target. Use a fictional or training application. Include a scope statement, a system diagram, a repeatable test case, the expected and observed behavior, the limits of your test, a suggested control, and a retest result. Remove secrets and personal data. If the finding comes from a public program, check the rules before sharing any detail. A sanitized write-up should teach the method without revealing an unpatched weakness.

You can also contribute through open-source security projects, research groups, local security communities, and conferences. Read contribution and disclosure rules before sending a report or publishing a demonstration. Ask maintainers whether they need help with tests, documentation, triage, or evaluation. A careful test case and clear explanation can be useful work even when it does not involve a novel exploit.

Follow changes in AI security

AI red teaming draws on application security, machine learning, privacy, safety, operations, and policy. Areas that deserve continued study include tool-using agents, memory and context handling, multimodal inputs, model supply chains, retrieval boundaries, and evaluation across model or application updates. These are topics for ongoing testing and research, not a prediction that every system contains each risk.

Good research questions start with an observable gap. Can an evaluator distinguish a risky tool side effect from a refusal that merely sounds unsafe? How should a test account for differences in role, tenant, or tool permission? Which evidence lets a team reproduce a result while minimizing retention of sensitive prompts? How does a patch behave after a model version changes? A useful project defines a bounded question, uses a controlled dataset or fixture, records limitations, and publishes findings only under the applicable rules.

Standards and taxonomies serve different purposes. ISO/IEC 29147 focuses on vulnerability disclosure, while ISO/IEC 30111 covers handling and remediation. ISO/IEC 42001 specifies requirements for an organization's AI management system. OWASP's 2026 LLM and Agentic lists and MITRE ATLAS organize security risks and techniques. NIST AI 100-2e2025 gives adversarial machine learning terminology and taxonomy. Read the scope of each document. A management system standard sets organizational processes. A risk taxonomy names types of threats. Authorization still comes from the system owner and the applicable policy. Standards may be revised, and frameworks may add or change categories.

The field will keep changing as systems add capabilities and organizations learn from evaluations. Make a habit of checking publication dates, version history, and the system under test. Compare new guidance with observed behavior. Bring a concrete test question back to a safe lab, and keep the result small enough for another person to reproduce.

Mistakes beginners make

• Assuming that a public service or bug bounty page allows testing every system from the same company.
• Treating a safe-harbor statement or general prosecutor policy as blanket legal immunity.
• Continuing after a minimal proof has established the issue, increasing exposure without improving the report.
• Sending unredacted tokens, personal data, or unrelated records to a program inbox.
• Reporting a single variable model response as a guaranteed behavior or broad impact.
• Writing a long report without the target version, exact role, expected behavior, or a minimal reproduction path.
• Collecting certificates without checking current objectives, renewal rules, employer needs, or practical lab work.
• Publishing a portfolio example that reveals an unpatched vulnerability or violates a program's disclosure terms.
• Treating a framework category as a complete test plan or a prediction about every AI system.

Recap and try it yourself

Responsible research starts with written scope and ends with a report the owner can use. Stop at the minimum proof, protect evidence, and coordinate disclosure under the program's rules. Laws and contract terms depend on jurisdiction and context, so seek qualified advice when the boundary is unclear. Career development grows through skills, supervised practice, careful documentation, feedback, and learning that continues as tools and standards change.

Try this with the fictional HelpDesk Bot: write a one-page report for the synthetic cross-tenant canary case from the local lab. Include the exact role, build, expected and observed behavior, repeat count, impact, and a proposed regression test. Do not add real records, credentials, or a claim about a live provider. Then draft a six-month learning plan with one skill, one safe practice activity, one work sample, and one source you will revisit in each stage. Ask a peer to check whether they can reproduce your test and understand what it proves.

The capstone brings the course's scope, threat model, test plan, harness, findings, fixes, and retest together in one authorized practice engagement.

Sources checked on 6 November 2026: the U.S. Department of Justice Vulnerability Disclosure Policy supports the scoped policy example, reporting expectations, stop rules, and limits of its own authorization; the DOJ's CFAA charging policy announcement describes the federal good-faith research policy and its limits. The UK Computer Misuse Act 1990 is an example of jurisdiction-specific statute. HackerOne's VDP and bug bounty comparison supports the program distinction; its Safe Harbor overview supports the example that program scope remains distinct from safe harbor. ISO's pages for ISO/IEC 29147, ISO/IEC 30111, and ISO/IEC 42001 support their stated scopes and status. NIST's NICE Framework guide supports the task, knowledge, skill, competency, and work-role framing. Training examples were checked in the primary PortSwigger Web Security Academy, OWASP Juice Shop project page, OffSec PEN-200 / OSCP+ page, and CREST Registered Penetration Tester page. AI security directions are informed by the OWASP GenAI Red Teaming Manual v1.0, OWASP LLM Top 10 2026, OWASP Agentic Applications Top 10 2026, MITRE ATLAS, and NIST AI 100-2e2025. All HelpDesk Bot outcomes and the sample report are fictional; no live system was tested.