Evidence Handling Policy

1. Plain-English summary

Security work depends on evidence, but evidence can contain sensitive system details. We handle evidence using minimization, classification, access control, redaction, and engagement-specific boundaries. Public forms should receive only non-sensitive preliminary information. Detailed targets, credentials, regulated data, production logs, and customer records should be shared only through the approved agreement path and secure channel for the engagement.

This policy applies across the public website, trust center, scoping and intake flows, no-cost scoping retainer and NDA workflows, private offers and SOWs, the customer portal, Workbench Copilot, generated packets and reports, and the following packet families where enabled: AI Launch Security Review, AI Product Security Assessment, AI Security Sales Evidence Pack, Pen Test & Red Team Readiness Packet, AWS / Cloud Infrastructure Testing Packet, AI / LLM / Agentic Red Team Packet, Agentic Workflow Security Packet, RAG / Knowledge System Security Packet, SSO / SCIM Enterprise Onboarding Packet, and Claim-Readiness / Public Evidence Packet.

2. What counts as evidence

Evidence is any material that helps define scope, authorize work, prove a condition, support a finding, or prepare a deliverable. It can include:

• scoping answers;
• target names, URLs, domains, IP ranges, AWS account metadata, cloud regions, and service inventories;
• architecture diagrams and data-flow diagrams;
• screenshots, screen recordings, logs, traces, and request/response samples;
• prompts, system instructions, model or provider configuration, and RAG source descriptions;
• agent tools, actions, permissions, approvals, workflows, and connector scopes;
• test accounts, role matrices, tenant details, and workspace boundaries;
• findings, reproduction notes, severity notes, and proof-of-concept material;
• generated packets, reports, memos, checklists, questionnaire drafts, and answer banks; and
• contracts and workflow artifacts related to NDA, SOW, ROE, DPA, private offers, and procurement.

Evidence does not mean the same thing in every engagement. A public URL, a redacted screenshot, and an unredacted production trace are all evidence, but they belong to different handling classes.

3. Evidence classes

Class 1: Public / low sensitivity

Examples:

• public URLs;
• published documentation;
• public marketing claims; and
• public trust-center content or non-sensitive company metadata.

Handling:

• may be collected in public forms or scoping flows;
• can be shared in public-safe packets; and
• should still be checked for accuracy before reuse.

Class 2: Confidential engagement material

Examples:

• architecture summaries;
• product descriptions;
• non-public target names;
• scoping answers; and
• buyer questions, packet drafts, or internal approval memos.

Handling:

• appropriate after account or session scoping;
• NDA is recommended before detailed sharing; and
• should move into an access-controlled workspace or secure channel as soon as the engagement path is confirmed.

Class 3: Sensitive security evidence

Examples:

• logs;
• traces;
• screenshots;
• prompts;
• system instructions;
• RAG source details;
• vulnerability reproduction steps;
• cloud metadata;
• role matrices;
• tenant boundary details; and
• access plans or ROE details.

Handling:

• share only after the NDA, no-cost scoping, SOW, and ROE path is in place as appropriate;
• keep access limited to the people who need the evidence; and
• prefer redacted or minimized versions where they still support the work.

Class 4: Restricted material

Examples:

• secrets;
• credentials;
• private keys;
• access tokens;
• production customer records;
• regulated data;
• payment data;
• health data;
• malware samples;
• destructive exploit material; and
• unredacted third-party data.

Handling:

• not accepted through public forms;
• only accepted if explicitly required, authorized, and covered by the applicable SOW, DPA, ROE, and secure-channel instructions; and
• default instruction is do not send.

4. Intake channels

Public forms may collect:

• company and contact details;
• business pressure or timeline;
• rough system type;
• non-sensitive target categories;
• rough launch date or testing window; and
• non-sensitive procurement needs.

Do not send through public forms:

• passwords;
• API keys;
• access tokens;
• private keys;
• production credentials;
• regulated data;
• sensitive customer records;
• exploit payloads requiring restricted handling;
• unredacted production logs; or
• unapproved third-party data.

Approved channels may include, depending on the engagement:

• authenticated workspace;
• secure file upload;
• encrypted document exchange;
• customer-approved ticketing or repository system;
• customer-controlled shared drive;
• secure portal;
• agreed email channel for low-sensitivity material only; and
• direct customer environment access after SOW, ROE, and access approval.

Credential exchange happens only after the right agreement path through an approved secure channel.

5. Minimization rules

We request the minimum evidence needed to answer the scoped question.

We prefer:

• summaries before raw data;
• redacted logs before full logs;
• screenshots with secrets masked;
• sample records before production exports;
• staging or demo environments before production;
• customer-run exports where direct access is unnecessary; and
• derived findings instead of retained raw artifacts where possible.

6. Redaction defaults

By default, redact or mask:

• passwords;
• API keys;
• OAuth tokens;
• session cookies;
• private keys;
• access tokens;
• customer personal data;
• payment data;
• health data;
• secrets in logs;
• internal employee personal details not relevant to the engagement;
• third-party confidential data;
• unrelated customer records; and
• production identifiers where not needed.

Some identifiers may remain when they are required for reproducibility, authorization, or remediation. The engagement should define that boundary before sharing.

7. Access controls

Evidence is accessible only to people and systems with a legitimate need for the engagement or platform feature.

We use:

• workspace and organization permissions;
• role-based access;
• assigned technical, legal, finance, and security users;
• least privilege;
• separation of customer workspaces;
• limited internal access for delivery, support, and security;
• access revocation and offboarding; and
• audit or logging controls where supported.

Legal, finance, and procurement contacts may see contract and procurement materials, but they should not automatically receive sensitive technical evidence unless they are assigned or otherwise authorized.

8. AI / Workbench Copilot processing

Workbench Copilot and other AI-assisted features may help summarize, classify, draft, triage, or generate packet and report sections from evidence when the customer uses those features or when the engagement permits AI-assisted processing.

Commitments:

• customer data is not used to train public AI models;
• third-party model providers are not authorized to train on customer content submitted through approved service or platform pathways;
• consequential findings, reports, attestations, claim language, and buyer-facing evidence require human review;
• restricted material should not be submitted to AI features unless explicitly covered by the applicable agreement and secure processing path; and
• customers may request AI-free or restricted processing for certain professional services where agreed in writing.

Related policies:

• AI Usage Policy
• Customer Data and Model Training
• Privacy Policy
• Subprocessors

9. Evidence use

Evidence may be used for:

• scoping;
• generating readiness packets;
• preparing SOW or private-offer inputs;
• performing authorized reviews or testing;
• validating findings;
• preparing reports and memos;
• creating a remediation backlog;
• producing buyer-ready evidence summaries;
• supporting claim-readiness review;
• providing support or security assistance; and
• complying with legal obligations.

Evidence is not used for:

• training public AI models;
• public marketing without approval;
• publishing customer-identifying examples without approval;
• expanding scope beyond the agreed engagement;
• authorizing testing outside named targets; or
• making certification claims unless expressly agreed.

10. Public-safe derivatives and claims

A public-safe derivative is a redacted, scoped, non-sensitive summary prepared for buyer, trust-center, procurement, or claim-readiness use.

Rules:

• public-safe summaries must not reveal secrets, exploit details, restricted evidence, or unrelated customer data;
• customers may not convert internal evidence into public claims unless the claim-readiness terms permit it;
• "reviewed by aisecurity.llc" does not mean certified, continuously monitored, or vulnerability-free; and
• claim language must include scope, date, limitations, and dependencies where applicable.

See the Publication & Claim-Readiness Policy for the claim-control rules that apply before public release.

11. Evidence in packets and deliverables

Generated packets, reports, and deliverables may contain draft conclusions and incomplete scope. Packet previews are working artifacts, not final professional advice.

Final deliverables depend on the applicable SOW, private-offer, or ROE scope. Readiness packets may identify missing inputs, required contracts, authorization gaps, special approval needs, and evidence-handling requirements.

Findings are point-in-time and scope-limited.

12. Special handling for active testing and red team evidence

For pentest, red team, cloud testing, AI red team, or agentic workflow testing, evidence boundaries must be documented in the ROE or SOW.

The engagement record should capture:

• allowed and prohibited techniques;
• stop conditions and emergency contacts;
• testing windows and escalation paths; and
• what targets, tools, and methods are in scope.

Exploit proof should be minimized. Destructive testing, denial of service, malware, persistence, phishing, social engineering, data exfiltration, credential attacks, third-party impact, or production data modification are prohibited unless explicitly authorized.

Cloud provider rules and special approvals may apply. Evidence must not exceed the authorized targets or methods.

13. Retention and deletion

Retention depends on evidence class, workspace settings, legal obligations, and the applicable SOW, DPA, ROE, or retention policy.

In general:

• raw evidence may be deleted or redacted after use where appropriate;
• final reports, contract records, billing records, and audit records may be retained longer; and
• customers may request deletion or export subject to contractual, legal, billing, and security obligations.

Retention details are governed by the Data Retention & Redaction Policy and the applicable agreement.

14. Customer responsibilities

Customers are responsible for:

• submitting only information they are authorized to share;
• avoiding secrets or regulated data in public forms;
• obtaining third-party authorization where targets are not wholly owned or controlled;
• identifying data sensitivity and restrictions;
• providing test accounts or access through approved channels;
• marking material that requires special handling;
• approving public-safe summaries or claims before external use; and
• revoking access when it is no longer needed.

15. Relationship to other documents

This policy works with:

• Privacy Policy
• Terms of Use
• AI Usage Policy
• Customer Data and Model Training
• Subprocessors
• Data Retention & Redaction Policy
• DPA
• the Mutual NDA(/trust-center/contracts/mutual-nda)
• the applicable Statement of Work(/trust-center/contracts/statement-of-work)
• Assessment Terms
• Rules of Engagement
• Pen Test & Red Team ROE
• Publication & Claim-Readiness Policy

If an executed agreement sets stricter evidence-handling requirements, the stricter engagement-specific requirement controls for that engagement.

16. Next step

Before sharing sensitive evidence, use Pre-Engagement Scoping or request the appropriate agreement packet.

• Pre-Engagement Scoping
• Open Contract Packet
• Request NDA
• Review Retention & Redaction