Authorised Red/Purple-Team and AI Product-Security Validation Lead

The mandate

The defined problem is an AI-enabled product whose security claims have not been tested through a joined offensive, defensive and product-risk evidence method. The consultant will deliver an Authorised Product Security Validation Pack for an agreed environment and threat perimeter. The assignment tests specific conditions and defensive usefulness; it does not promise comprehensive safety or permission to attack third-party services.

The four-month engagement starts on 19 October 2026 at four days weekly, based in Bengaluru with remote evidence development and scheduled India product workshops. Deliverables include written test authorisation, threat and abuse cases, red/purple-team evidence, selected AI product-risk tests and remediation replay instructions. Asset owners approve scope, data handling and safety limits before execution.

Milestone one on 18 November 2026 supplies the signed authorisation and threat baseline, including AI-specific misuse hypotheses and agreed evidence criteria. Milestone two, due 18 January 2027, delivers controlled test results, defensive response observations and prioritised product findings. Milestone three on 18 February 2027 is the accepted validation pack, approved retests and a retained-team replay of selected detection or product-control scenarios.

The product security sponsor and defensive lead jointly accept the work. Findings must be reproducible within the authorised environment, describe preconditions and show the observed defensive or product response. Retests must demonstrate the agreed correction rather than merely a closed ticket. Untested model behaviour, external services and deployment conditions remain explicit exclusions. Acceptance cannot be interpreted as a general certification of the AI product.

The sponsor supplies a safe test environment, authorised access, representative data and product/defensive reviewers. The consultant does not perform unrestricted production exploitation, harvest unrelated personal data, operate customer incident response or redesign the entire product. New threat scope and additional environments require written change approval and fresh authorisation. Closure follows accepted evidence and replay transfer, not a claim that no future vulnerability can exist.

What you will own

• Develop the authorised threat and abuse-case catalogue, linking each proposed test to a product risk, safe environment and explicit asset-owner permission before execution.
• Design red and purple-team scenarios that connect observed exploitation conditions to defensive detection or response evidence rather than treating access gained as the only useful outcome.
• Construct selected AI product-risk tests for agreed misuse and control hypotheses, documenting model, data and deployment limitations that prevent a bounded result from implying general safety.
• Execute controlled validation and preserve reproducible evidence, preconditions and response observations while stopping any activity that exceeds consent, safety or data-handling limits.
• Prioritise findings by demonstrated impact and realistic conditions, separating confirmed weaknesses from speculative scenarios or untested assumptions requiring another validation scope.
• Transfer retest and replay instructions through retained-team exercises, requiring proof of agreed corrections and clear ownership of residual product or defensive issues.

Candidate qualifications

• Demonstrate at least ten years in cybersecurity with substantive authorised offensive-security and product-validation delivery. Present a red or purple-team engagement you personally led, the authorisation boundary and a finding that changed defensive or product action. The role requires proven method rather than assumed executive seniority.
• Show deep testing and evidence discipline across exploit preconditions, detection, response and retest. Explain a case where gaining access did not establish the claimed business impact, and how you revised the conclusion. Candidates must protect asset-owner consent and know when to stop rather than use project pressure to broaden scope.
• Bring practical AI/ML security, product-risk or DevSecOps capability supported by actual test artifacts. Describe a model or product misuse hypothesis, the controlled method and the limitation of the result. Broad AI governance familiarity alone is insufficient, and the consultant must not present selected tests as comprehensive safety certification.
• Prove fixed-fee validation delivery with safe environments, secure records and retained-team replay. Explain handling of new threat requests or production testing pressure without weakening authorisation or acceptance. Professional security certifications support capability, but reproducible evidence, defensive usefulness and disciplined scope are the decisive qualifications.

Application

Applications for this mandate are received in one way only: through the India Board Terminal's application process. It is automated end to end. Your Executive Passport travels to the mandate holder in its confidential form, your answers to the three questions below are read before anything else in your file, and every stage that follows is recorded on your applications page.

There is no address to write to and no intermediary to call. The mandate holder reads what the Terminal delivers and nothing else, which is what keeps the process the same for every applicant and keeps your name out of it until you release it. Applications close on 12 October 2026. Mandate reference PCT-CON-2026-IND-58.