What Pentr is

What it does¶

Pentr runs penetration tests against systems your organization has registered and proven it owns. Before a run starts, every target and every in-scope entry must be covered by an asset whose ownership proof holds at that moment; Ownership verification describes the check.

The run is carried out by an agent: a program, running in a container started for that run, that asks a language model which command to execute or request to make next, and carries it out. Isolation describes the controls on that container.

Each command the agent executes, each HTTP exchange and each screenshot is hashed with SHA-256 when it is captured and stored as an artifact, up to a ceiling of 10 MiB per artifact; Artifacts describes what happens to a larger one. Evidence the agent attaches to a finding is captured the same way.

When the agent's container exits cleanly with a results payload, the run is recorded as completed and sealed: its artifacts are ordered into a hash chain, a manifest is built over them, and a signature block carrying the manifest's hash is signed with your organization's Ed25519 signing key. Sealing covers when a run is and is not sealed, including a seal attempt that fails.

The report is generated when the console first shows the completed engagement, not when the run ends. Report generation maps each finding to the controls of the engagement's compliance framework. The report is not part of the sealed evidence and is not signed.

What a signature shows¶

A sealed run can be exported as an evidence locker and checked with pentr-verify, offline, with no Pentr account. Verifying a locker covers the procedure.

A verification pinned to your organization's public key shows that the sealed evidence in the locker has not changed since it was signed with the key registered to your organization. Pentr holds that key and signs with it, as Key custody describes, so a pinned verification does not show that a person in your organization signed the locker.

A verification without a pinned key checks the locker against the public key packaged inside it, and shows only that the locker is internally consistent. What verification does not prove sets out the other questions a verification leaves open.

How it is delivered¶

Pentr is a hosted service operated by Pentr. Customers use it through the web console and the partner API; they do not install or run the service. There is no self-hosted edition.

What it is not¶

Pentr is not a vulnerability scanner. Each run tests the targets named in one engagement. In the exploitation phase the agent is instructed to attempt to exploit the findings recorded earlier and to set each one's status to verified, false_positive or not_exploitable. Nothing checks that status against the evidence; Anatomy of a finding describes the field.

Pentr is not a substitute for a human test of an application's business logic. The phase prompts direct the agent to passive reconnaissance, a threat model, port and service discovery, matching service versions to known CVEs, a list of OWASP WSTG categories for HTTP services, configuration checks, exploitation of what those steps find, and privilege escalation, lateral movement, data access and persistence from a compromised host. The WSTG business-logic category is not on that list.

Pentr is not an attestation. Pentr produces evidence and reports. Auditors produce attestations. No Pentr output is a SOC 2 report, an ISO 27001 certificate or an ENS conformity declaration, and none should be presented as one.

Where to start in these docs¶

Three pages introduce the product:

• Anatomy of a run follows an engagement from submission to its sealed evidence and report.
• Your first engagement walks from an empty account to a sealed locker checked with pentr-verify.
• Concepts and glossary defines the terms used across these docs, including the difference between an engagement and a campaign and between an asset and a target.

Nine sections follow:

• Engagements: scope, ownership verification, rules of engagement, framework choice, phases, running an engagement, the engagement lifecycle, and failed runs.
• Findings & reports: the fields of a finding, severity and taxonomy, the PDF report, the SARIF and CSV exports, and retesting.
• Evidence locker: artifacts, the hash chain, signing keys, sealing, export, verification, share links, and what verification does not prove. Its last three pages are written for an auditor who receives a locker or a share link.
• Schedules: recurring campaigns, cadence, timezones and daylight-saving changes, plan caps and skipped occurrences, and managing a schedule.
• Frameworks: how findings map to controls, one page per framework, and custom frameworks.
• API: the partner API: authentication, assets, engagements, reports, schedules, webhooks, usage limits and errors.
• Account: organizations, plans and limits, and billing.
• Security & trust: isolation, data handling, key custody, authorization and subprocessors.
• Support: troubleshooting and frequently asked questions.

Supported frameworks¶

Each engagement is mapped to one framework, named when the engagement is created. Pentr includes six framework definitions:

Framework	Version
SOC 2 Type II	2017
ISO/IEC 27001:2022	2022
PCI DSS v4.0	4.0
OWASP Application Security Verification Standard	4.0.3
NIST Cybersecurity Framework	2.0
Esquema Nacional de Seguridad (ENS)	RD 311/2022

The framework decides which control identifiers appear beside each finding in the report and in the SARIF and CSV exports. It does not direct the testing: no phase, tool or check is selected by it. The framework is recorded in the rules-of-engagement document, which is rendered at the start of the run, stored with the engagement and reproduced in the PDF report. That document is not sent to the model, as Data handling states.

Mapping works from the identifiers a finding carries. The agent is asked for MITRE ATT&CK technique ids on every finding, and the ids it supplies are checked against the ATT&CK catalog included with Pentr; a finding with an unknown id is refused. Nothing requires the list to be non-empty, so a finding can carry no identifiers. Where a finding carries ATT&CK or OWASP WSTG ids, the mapper looks them up in the framework's tables. When that lookup yields no control, because the finding has no identifiers or none of them is in the tables, the mapper matches the finding's text against keyword categories.

Each framework's tables map ten ATT&CK techniques and twelve WSTG ids. A finding whose identifiers are not among them depends on the keyword match, and can end up mapped to no control.

A control identifier beside a finding says that the finding carried an identifier, or matched a keyword, that the framework's tables map to that control. It is not a judgement that the control is met or failed; Frameworks explains what each case tells you.