Self-assurance
Perihelium tests itself continuously with a catalogue of security scenarios — a stolen token replayed, an agent's kill switch defied, an audit entry tampered with, a permission widened without a review — and publishes the results. Self-assurance gives your organization the same catalogue, run against your own organization, on your schedule, with a signed report you can hand to an auditor or a customer. It is available on the Enterprise plan under Assurance in the console.
What a run tests
A self-assurance run drives the scenarios that can be exercised inside your organization without touching anyone else's:
| Family | Examples |
|---|---|
| Authentication | a replayed refresh token is refused; a sign-in without the required second factor is refused; further sign-in attempts are refused after the configured number of failures |
| Authorization | a member cannot read another organization's records; a delegation confers nothing its delegator lost; a separation-of-duties pair cannot be held by one person |
| AI agents | an engaged kill switch refuses the agent on every surface; a budget exhausted contains it; a token without its proof of possession is refused when the organization requires one |
| Keys and credentials | a revoked API key is refused; a credential past its age policy raises a detection |
| Privacy and retention | a deletion request takes effect as documented; a retention policy removes what it says and keeps what is under legal hold |
| Approvals | an obligation-carrying action waits for its approver; an approval by the requester is refused |
| Evidence and audit | every action of the run appears in the audit chain, and the chain verifies after it |
| Adversarial | the in-organization subset of the adversarial catalogue: injection against the agent surfaces, authorization bypass attempts, token confusion |
Each scenario is parameterised to your organization — your members, your agents, your policies — never a script with someone else's names in it. A scenario that cannot be driven in your organization (a feature you have not enabled, a policy you have not set) is reported as such, by name, with the reason.
What a run does not test
- Anything outside your organization. A run never sends traffic to another tenant, to your own systems, or to the platform's infrastructure. Infrastructure testing (network, host, cloud configuration) is the platform's own programme and is reported on the public assurance page.
- Your application. The scenarios exercise Perihelium as your organization has configured it; they do not test the code that calls it.
- Certification. The report says on its first page that it is not an attestation and not a substitute for an independent penetration test. It is evidence of behaviour on a date.
Targets and rules of engagement
Before the first run, an administrator declares the target — your organization — and proves ownership of it, and accepts the rules of engagement: what the run will do, what it will create (test members and agents, named so they are unmistakable, removed when the run ends) and what it will record. The acceptance is a signed, audited act, kept with every report. Starting a run requires a person: an agent or an API key can read results and schedule nothing.
The report
A run ends in a signed report: scope, the catalogue version, every scenario with its verdict (pass, fail, gated or unproven, with why), the evidence for each (the events and audit entries it produced, by identifier), and findings by severity with reproduction steps. The signature verifies offline with the platform's published key, so a reader does not have to trust the download. Reports are scoped to your organization; nobody else's run is visible to you, nor yours to them.
Where to go next
- Compliance readiness and attestations — the controls, the evidence and the readiness view a run feeds.
- Security monitoring — the events and detections a run produces, marked as a run's, so they do not page your team.