Skip to main content
[AVAILABLE]. packages/shared/src/domain/execution-authorization.ts, AuthorizationSigner, AuthorizationVerifier.
An earlier prototype called this concept “Execution Permit” (packages/shared/src/domain/execution-permit.ts, added then deleted the same day in favor of this architecture, see the Glossary). If you find “Execution Permit” in older material, this page is the current, shipped equivalent.

​
What it is

A SignedExecutionAuthorization is the artifact a PolicyEngine’s APPROVED decision becomes: a signed envelope proving that Parmana authorized exactly one execution, of exactly this content, within a bounded time window, usable exactly once. 
// packages/shared/src/domain/execution-authorization.ts
export interface SignedExecutionAuthorization {
  readonly payload: ExecutionAuthorizationPayload;
  readonly signature: string;
  readonly keyId: string;
  readonly algorithm: string;
}
payload carries: a format version (verifiers reject anything but 1), a unique authorizationId, a single-use nonce, the decisionId and businessTransactionId it authorizes, the exact policyName/policyVersion that produced the decision, an authorizedAt/expiresAt bounded window, and businessTransactionHash, the content binding covered in depth on The gateway.

​
Why it exists

A decision alone isn’t something a separate system can trust: it’s a claim inside Parmana’s own process. The signed authorization turns that claim into something a different system can check without trusting Parmana’s runtime or database at all, using nothing but a public key and the envelope itself. Every property below exists so that check is meaningful.

​
How it behaves

  • Signed only after approval. A REJECTED decision never produces a SignedExecutionAuthorization, signing happens only after ExecutionGate.enforce() approves (RuntimeEngine; execution-authorization-wiring.test.ts, “rejected transaction produces no authorization”).
  • Single use. A receiving system must reject an authorization whose nonce has been seen before, enforced by whichever NonceStore performs the check. See The gateway for the fleet-wide caveat: single-use is scoped to whichever NonceStore instance checks it.
  • Time bounded. expiresAt is required; a receiving system must reject an expired authorization.
  • Content bound. businessTransactionHash binds a canonical hash of the executable content into the signed payload, not just an ID. This is what closes the check-vs-use (TOCTOU) gap: see The gateway for the mechanism.
  • Algorithm agile. Ed25519 by default; ML-DSA-65 (FIPS 204) selectable via PRIMARY_SIGNATURE_PROVIDER. See Choose a signature provider.
All timestamps in the payload are ISO-8601 UTC strings, not Date objects, this keeps the artifact byte-identical before signing and after JSON transport, which is what makes independent signature verification possible at all.

​
Minimal example: independent verification

A receiving system can verify a SignedExecutionAuthorization without trusting Parmana’s runtime process or database, it needs only Parmana’s public key and the envelope itself: 
// @parmana/envelope-verifier
const verifier = new EnvelopeVerifier({ publicKey, nonceStore });
const result = await verifier.verify(authorization);
// result.valid, result.checks: { versionSupported, signatureVerified, notExpired, ttlWithinPolicy, nonceUnseen }
An Express middleware ships for this: requireParmanaAuthorization(verifier) (packages/envelope-verifier/src/express.ts), reads req.body.authorization, verifies it, and either rejects with 401/403 or calls next(). EnvelopeVerifier.verify() checks signature, expiry, TTL policy, and nonce, it does not check businessTransactionHash. That’s the Execution Gateway’s job, one layer up, because it needs the actual executable content to hash, not just the envelope.

​
Rejections proven by test

packages/envelope-verifier/test/envelope-verifier.test.ts proves: a forged signature is rejected and does not burn the nonce; an expired envelope is rejected and does not burn the nonce; a second use of the same nonce is rejected.
Related work. The Execution Governance framework (Ku, 2026, EG Reference Specification v0.9.7.3) describes a convergent discipline of pre-effect authorization for physical AI systems. Parmana is a running implementation of pre-execution authorization for enterprise financial execution. The vocabulary on this page is Parmana’s own; it does not adopt that framework’s six-condition terminology.

​
Next

The gateway

Where this envelope gets independently re-verified before anything executes.

Gateway attestation

A second, separate signature: proof the gateway itself released this specific request.