Data handling

This page lists where Pentr stores data, what it sends to the LLM provider, what the application encrypts, and when data is deleted.

Where data is stored¶

Store	What it holds
Application database (PostgreSQL)	Organizations and users; engagements, with each run's rules-of-engagement document, threat model and intelligence report; findings, with their evidence inline; artifact metadata; seals; report records; share links, as a SHA-256 digest of each token; signing keys, with the private half wrapped; assets and their verification history; schedules; API keys, as bcrypt hashes; webhook registrations
Identity database (Ory Kratos)	Sign-in identities — email address, name and password credential — and their sessions
Evidence store	Artifact bytes, and each sealed run's manifest and signature block, stored as files at <engagement_id>/<sha256>
Report files	Generated reports, one file per engagement and format
Redis	Jobs waiting for the scheduler; each run's most recent progress events, kept for 24 hours; rate-limit counters
Run logs	The output of each run's container, one file per run, written by the scheduler
Scheduler service log	The same container output as the run log, when the container exits with an error or the run log cannot be written

What the LLM provider receives¶

Each request the agent sends to the model carries:

• Pentr's instructions to the agent, including those for the current phase, and the definitions of the tools the agent may call;
• the engagement's targets, and its in-scope and out-of-scope lists;
• the findings recorded so far in the run, and the summaries of completed phases;
• the run's conversation so far: the model's earlier replies and tool calls, and their results, including the full output of each command the agent has run.

For an HTTP request the guard allows, the result in the conversation is a single line with the method, the URL and the response status. For a screenshot, it is a caption naming the URL and the status. The response body and the image are captured as evidence and are not sent.

The rules-of-engagement document rendered for the run is not sent to the model.

The LLM provider is listed on Subprocessors.

Encryption¶

The application encrypts one kind of data itself: the private half of each signing key, which is stored wrapped under a key-encryption key. Key custody describes how.

Traffic between the browser or API client and Pentr is encrypted with TLS. Connections between Pentr's services, and from them to the database and the queue, are encrypted and authenticated.

Data is encrypted at rest on the GCP disks that hold it.

Backups¶

The databases and the evidence storage are backed up.

Deletion¶

No route deletes an engagement, a finding, an artifact, a seal, a report or an account, and nothing deletes them on a schedule or after a retention period. An organization can delete its schedules and webhooks, and any asset that has no verification history. A share link is revoked rather than deleted.

Redis data is removed without a request in three cases. A queued job is removed when the scheduler takes it. A run's progress events are trimmed to the most recent ones and expire after 24 hours. Rate-limit counters expire at the end of their window.