The system under evaluation
The enforcing system is the Parmana server in github.com/pavancharak/parmana: the API, the runtime that evaluates policy and signs authorizations, the execution gateway, and the connectors behind it.@parmana/sign is not an enforcement
component. It verifies signed records after the fact and decides nothing. A valid signature
on a Trust Record shows that Parmana signed that record and that it was not altered. It does
not show that an unauthorized action was prevented, and it says nothing about actions that
never passed through Parmana. Prevention is a property of the enforcement points below, and
of the downstream system only accepting requests that went through them.
Where execution is blocked
A request toPOST /execute passes these points in order. Each refuses before the next one
runs, and nothing reaches a downstream system unless every point passes.
In Parmana’s own server, E2 and E3 run in the same process for each request. E3 is the point
that matters when a receiving system runs separately and verifies authorizations itself
(
@parmana/envelope-verifier). E5 is only as strong as the receiver’s own check: Parmana
cannot stop a downstream system from accepting a request that never came through it.
What an attacker controls
THREAT-MODEL.md puts these attackers next to the assets, trust boundaries and threats, with the control, evidence and residual risk for each. “Credential compromise” is not one thing. Each credential below is listed separately, because the outcome differs. The expected outcome is what the code is designed to do; an evaluation should record what is actually observed.
SECURITY.md lists findings that need a compromised signing key or infrastructure as out of
scope. They are listed here anyway, so that a report can state them as assumptions rather
than leave them implicit.
On a copy you run yourself, you are the operator: you hold every key, the database, both
governance credentials and the host. An evaluation, and the
security challenge,
tests what an attacker can do from the in scope rows above, not what the operator can do.
A bounded scenario: a refund without a valid manager approval
Code versions. Pin the commit you test and record it in the report:- Policy:
policies/customer-refund/1.2.0/policy.json. Every refund above 0 and up to 100000 needs a signed manager approval for that order, covering that amount. Above 100000 is refused. - Capability:
paytm:refund, bound tocustomer-refundinpackages/capability-registry/src/CapabilityPolicyBinding.ts. - Offline verification of the resulting records:
@parmana/sign0.2.0.
paytm:refund, and controls the entire request
body, including every declared signal. Does not hold an approver key, Parmana’s signing key,
the gateway key, Paytm credentials or database access.
Attacks and expected outcomes.
Run them:
bash docker/local/offline-check/run.sh (Docker). An auditor is encouraged to write further
attacks against the server running locally (npm run dev, or the Docker stack) rather than
rely only on the tests listed here.
Running every scenario at once
npm run evaluate runs the attacks above together with the rest of the 16 scenarios in
evaluations/scenarios.json
and writes evaluation-report.json with the commit, whether the tree was clean, a hash of the
policies and each test file’s hash and counts. It is a quick baseline, not a replacement for
your own attacks: it shows that the repository’s tests for each scenario pass at that commit.
See Run the attack scenarios.
Recording results
A useful result is a reproducible account of which attacks were blocked, which succeeded, and under which assumptions, not a pass or fail for the whole system. For each attack, record:
An attack that succeeds is a finding even when it falls under a stated assumption: it shows
where the boundary actually is.
Evidence documents
- docs/CLAIMS.md: every claim, scoped to its evidence. Summarised in Claims and evidence.
- docs/VERIFICATION-GAPS.md: every gap found, and how it was closed or narrowed.
- docs/adr/: architectural decisions.
- Limitations and Security, including the
automated checks every change to
mainmust pass.
Review history
These are internal reviews by the developer, not independent audits.-
2026-10-03. A review of code, docs and claims found and fixed, among others:
- a rejected policy change that could still be applied;
- unauthenticated requests that could each trigger a signing call;
- caller chosen tenant signing keys;
- concurrent approvals of one policy change;
- an unchecked approval scope field;
- a gateway signal check skipped when signals were absent.
- Earlier reviews are recorded in docs/VERIFICATION-GAPS.md and in dated updates in docs/CLAIMS.md.