Data handling

AISafe processes your source code, target URLs, and assessment results to deliver security testing.

What data AISafe processes

AISafe processes the following when you run an assessment:

• Source code: for code audits, the platform clones your repository into an isolated sandbox for analysis. The code stays for the duration of the assessment and its revision history.
• Target information: for pentests, the target URLs, authentication credentials, and HTTP traffic captures produced during testing.
• Findings and evidence: vulnerability descriptions, file locations, taint flows, proof-of-concept payloads, and suggested fixes.
• Reports: PDF deliverables.
• Organization metadata: member information, team structure, integration connections, API keys, and billing records.

How data is stored

• Source code archives: the platform stores them in encrypted object storage, under a prefix that belongs to your organization and no other. AISafe stores identical code only once: two assessments of the same snapshot share one encrypted copy, in the same way that two assessments of identical code already share one static-analysis snapshot. AISafe removes that copy once none of your assessments still holds it, so deleting an assessment removes its source unless another of your assessments is still using the same code.
• Static-analysis snapshots: AISafe SAST persists only source-free typed facts, locations, coverage, dependency metadata, policy-neutral infrastructure configuration facts, deterministic infrastructure-policy findings, and redacted secret fingerprints in immutable encrypted artifacts. Dynamic infrastructure expressions and sensitive configuration properties are stored as typed unknowns rather than evaluated source text; policy evidence that AISafe cannot resolve is kept as partial evidence and is not reported as a clean result. Secret history correlates fingerprints across scanned revisions and stores no additional credential material. AISafe SAST does not persist raw source in those snapshots, and a detected secret is stored as a redacted fingerprint rather than as its value. One exception applies today: in infrastructure-as-code files, a configuration value is stored as it appears in the file unless the property name marks it as sensitive — the names AISafe withholds today contain password, passwd, secret, token, private_key, access_key or encryption_key. A credential written into an infrastructure file under any other name — api_key, connection_string, credential, bearer and dsn among them — is held in the snapshot as written, until the snapshot is deleted. Shared content-addressed snapshots are deleted when their final assessment reference is removed.
• Static-analysis rules: versioned rule artifacts are validated and executed locally by AISafe SAST. The artifact bundles its compatibility metadata, commercial-use license provenance, and required notices; loading it does not send customer source, findings, or rule results to AISafe or another rule host.
• Assessment and finding data: AISafe's database holds this data, scoped to your organization. The platform blocks cross-tenant access to prevent information leakage.
• Credentials and secrets: API keys and integration tokens use encryption at rest. Source access tokens (GitHub/GitLab installation tokens) expire within a short window and do not touch disk.
• HTTP traffic captures: the platform stores pentest traffic (request/response pairs) as artifacts linked to the assessment. Bodies go to the same encrypted object storage as the archives; the index of what was requested, and when, sits beside them.
• Screenshots and captured pages: during a pentest, AISafe takes screenshots of your running application and keeps the JavaScript, HTML and responses it downloaded. These are stored with the assessment that produced them.
• The agent's working record: an assessment keeps the reasoning trace of the run — what the agent read, what it asked the model and what came back — so a finding can be explained and reproduced. Excerpts of your code and of your application's traffic appear in it.

Who can access your data

Organization membership and roles govern access to your data:

• Organization members: can access assessments, findings, and reports within their organization, subject to their role permissions.
• Raw HTTP traffic: a capture holds whatever your application sent and received during the test, including session cookies and bearer tokens, so AISafe restricts access to it more tightly than access to the assessment's findings. Owners, admins, the member who created the assessment, and anyone assigned to it individually can read the captures. A member who reaches the assessment only through a team can read its findings and its report, and cannot open its traffic.
• AISafe staff: do not have routine access to your source code or findings. Staff access is limited to support and incident response, and the platform audits all access.
• No cross-tenant access: AISafe returns 404 when a caller tries to access a resource belonging to another organization, preventing information leakage about other tenants.

Data retention

AISafe treats your material and its own results differently: only the results remain after a deletion. Everything an assessment produced from your code and your application is yours: the source archives, the screenshots of your running application, the traffic captured against it, the pages it downloaded, and the working record of the run. When an assessment's source is deleted, AISafe deletes all of this material at the same time, on a single retention clock. What remains is the work you paid for: the findings, the report, the documentation and the artifacts. These results hold no copy of your repository. A finding quotes only the few lines of code it is about, so that you can still read and understand it after the code is deleted.

• Assessments and findings: the platform retains them for the lifetime of your organization. You can delete assessments and findings at any time.
• Source code archives: the platform keeps the code it analyses for 30 days by default, then deletes it. An assessment's snapshot is deleted 30 days after it was attached, and that clock never resets. A project's source is deleted after 30 days with no activity on the project, and that clock resets every time you use the project — a project with a scan schedule or monitoring enabled is never affected. Your plan or contract may extend that window; it is never shortened below the 30 days stated here. Deleting an assessment removes its source archives at once, and you can delete an assessment's source yourself at any time.
• Assessments that never start: an assessment with no run behind it — a draft nobody finished, one validated but never paid for, one whose validation was refused — is deleted after 30 days with no activity, along with any source uploaded to it. Editing it, validating it or pressing Start resets that clock, whether or not the start goes through. An assessment that ran is never affected.
• Test evidence: screenshots, HTTP traffic captures and the agent's working record are deleted on the assessment's own clock, at the same time as its source and never later. They have the same retention window as the source, and a contract that extends that window extends it for them too. Whether the clock runs out because you press Delete or because the 30 days pass, one deletion removes all of it together. There is no separate retention window for evidence that you need to track. If one storage system is unreachable at the moment the deletion runs, the assessment is not marked deleted and AISafe attempts the whole deletion again the next day, and keeps doing so until every part of it is gone. The platform never records a deletion that it did not complete.
• Results after the source is deleted: the findings, the report, the documentation and the artifacts stay readable after the code is deleted. The features that read or describe the code stop working: the Code Explorer, the file listing beside it, and — because they are read from the static-analysis snapshot, which is deleted with your source — the dependency inventory, the SBOM and the call graph. For a connected or public repository the next scan fetches the code again; for a project whose source you uploaded, AISafe asks you to upload it again.
• Static-analysis snapshots: a snapshot is deleted with the source it was built from. Because one snapshot is shared by every assessment analysing identical code, it is removed once no remaining assessment still holds that source. The stored copy of the code itself is shared the same way and removed on the same terms.
• Reports: the platform retains them as artifacts linked to the assessment.
• Account data: the platform retains it while your account is active. You can request data deletion by contacting support.

LLM processing

AISafe uses third-party LLM providers to power the AI agents. The platform sends your source code and target information to the LLM provider as part of the reasoning process. AISafe does not use your data to train models. Refer to your LLM provider's data processing terms for details on their handling of inference inputs. See the sub-processors table below for the categories of providers involved.

Data subject rights

If you need to exercise data subject rights under GDPR, CCPA, or similar regulations, including data deletion, data export, or data portability, contact AISafe support. Organization owners can also delete assessments and findings from the dashboard at any time, which removes the associated source archives, artifacts, and reports.

A full organization erasure also removes its projects, integrations, product history, stored source, captures, agent traces and reports. AISafe blocks new work for the organization while erasure runs and marks the request complete only after its API and analysis services verify that no customer row remains. A failed erasure stays visible and can be retried. AISafe records the deletion proof before removing the organization's users. If that last step is interrupted, the erasure worker resumes it without requiring a customer login.

Sub-processors

AISafe relies on the following categories of sub-processors to deliver the service:

Category	Purpose	Examples
Cloud infrastructure	Compute, storage, networking	Major cloud providers
LLM providers	AI agent reasoning	Anthropic
Source code hosting	Repository access (your choice)	GitHub, GitLab
Issue tracking	Finding export (your choice)	Jira, Linear, GitHub Issues
Notifications	Slack/Teams notifications	Slack, Microsoft Teams
Email delivery	Transactional email	Resend
Billing	Subscription and credit purchases	Polar

Request the current sub-processor list with specific providers from support. AISafe commits to notifying customers before adding a new sub-processor that processes customer data.