Roadmap

This page consolidates every gap surfaced while building this site, cross-checked against docs/CLAIMS.md §4 (Future Claims) and the internal strategy document UNAVOIDABILITY-ARC.md (2026-07-05). Both are being updated to reflect the current state as a follow-up (tracked in 02-REMAINING.md, Tier 0), this page reflects the true current state now, not the slightly-stale wording in those two files.

​

The unavoidability arc, 3 moves, in dependency order

“The provability layer is done: every approved action carries a signed, content-bound, single-use authorization that receiving systems verify independently, byte-for-byte. What that does NOT yet do: it makes Parmana’s authorization verifiable, not unavoidable. Today an AI still holds whatever execution credentials it was given.” Source: UNAVOIDABILITY-ARC.md, 2026-07-05

​

Move 1: KMS / HSM key custody, [ROADMAP], roughly 1-2 weeks once started

Today: FileKeyProvider reads a PEM file from disk (KEY_PROVIDER=local, the only implemented provider). KeyProviders declares aws-kms/azure-key-vault/gcp-kms/hsm as config values with zero implementing classes behind any of them. This is the exact exposure class that produced the committed-key incident on Security. Update, 2026-09-10: setting KEY_PROVIDER to one of these four now fails startup loudly (KeyBootstrap.create() throws, naming the configured value) instead of the prior behavior, which silently constructed FileKeyProvider anyway, as if local had been chosen. That silent-fallback bug is fixed (docs/VERIFICATION-GAPS.md G-40); the underlying absence of a real KMS/HSM provider is unchanged. Unlocks: “Parmana’s signing key cannot be exfiltrated from the application process.” What’s pending, precisely: a real KeyProvider implementation (getPrivateKey, getPublicKey, hasKey, getMetadata; see packages/crypto/src/KeyProvider.ts) for at least one of aws-kms/azure-key-vault/gcp-kms/hsm, registered in KeyBootstrap.ts in place of today’s fail-closed throw for that value. Why it’s still pending, not just unscheduled: this repo’s own evidence bar for a Supported claim is a live test against a real key in a real account. “A fake/mock passing proves nothing here” is not a rhetorical flourish, it’s the same standard PostgresRateLimitStore (the durable rate limiter, docs/CLAIMS.md 3.14) was held to before being marked working. A KeyProvider implementation can be written and unit-tested against a stubbed cloud SDK client entirely offline, which proves the code is structurally correct, not that it actually works against the real service (correct IAM permission scoping, correct key ARN/resource-id format, the signature actually verifying against the returned public key, etc.). None of that can be verified without a real AWS/Azure/GCP account and credentials, which this development environment does not have and a code-writing session cannot manufacture for itself. What building it actually needs, in order:

1. Resolve the algorithm question below first. It changes what the provider signs, not just how it fetches the key.
2. Pick one provider to start with (AWS KMS is the most likely first target: broadest existing tooling, most common in this codebase’s target deployments).
3. A real account + credentials with a KMS key already provisioned, scoped to exactly the sign/verify operations this provider class needs, not broader IAM permissions than required.
4. Implement the KeyProvider interface against that SDK, following FileKeyProvider.ts’s existing shape (including its assertValidKeyId path-safety discipline, translated to whatever the cloud SDK’s own key-identifier validation needs to be).
5. Wire it into KeyBootstrap.create(), replacing the current throw for that one KEY_PROVIDER value only. The other three stay fail-closed until each gets the same treatment.
6. Run a live sign/verify round trip against the real key before claiming this as Supported anywhere in docs/CLAIMS.md. A passing unit test against a mock does not satisfy this repo’s own bar, stated above.

Open design questions (from the strategy doc, not yet resolved, and blocking step 4 above until answered): does AWS KMS support Ed25519 natively, or does this force a move to ecdsa-p256 (already declared in SignatureAlgorithms, unused today) for KMS-backed keys specifically? ML-DSA-65 (this codebase’s post-quantum signer) is not yet broadly available in any major cloud KMS. A KMS-backed deployment may need to run classical-only, or hybrid mode with the PQ half still file-based, an inconsistency worth deciding on deliberately rather than discovering mid-implementation.

​

Move 2: Credential brokering, [PARTIAL], wired for the registered connector, full claim is [ROADMAP]

Today, precisely: packages/execution-control is real and tested (11 tests) and, as of commit 651497a, wired into the default server: ExecutionControlService authenticates a calling gateway, issues a short-lived InMemoryGatewaySessionStore session, and only then invokes a connector, auditing every step. InMemorySessionCredentialVault isolates the credential from the caller within that flow. This is real, tested, and running in the default server for the one connector this is proven for (hubspot), see Credential isolation for the precise scope note. It is still an in-process, in-memory scaffold, not a cross-system claim about arbitrary connectors, landed 2026-07-05 as a library, wired into the server 2026-07-11. What’s still missing for the actual claim: real cloud-provider credential minting (the plan targets AWS STS: a verified envelope causes the gateway to mint a short-lived, action-scoped credential, use it, and discard it, the AI never receives it, structurally), and a general-purpose path to register a new connector into this seam without a bootstrap code change. InMemorySessionCredentialVault and InMemoryGatewaySessionStore are dev/reference-grade names for a reason, no STS integration, no persistence, no cross-process session sharing exists yet. The strategy doc is explicit that this move “needs a design partner, not a mock”, a fake AWS account proves nothing a diligence review would trust. Unlocks (scoped): “For [action class] on AWS, AI never possesses execution credentials.” Scoped to the integrated system class, never claimed universally. Schema note: extending the envelope with resource/action fields for this is a signed-artifact format change, requiring a dedicated versioned session (the version field already in ExecutionAuthorizationPayload exists for exactly this reason).

​

Move 3, Network enforcement + bypass detection, [ROADMAP], needs a partner’s red team

What: network-policy templates (firewall / security-group / K8s NetworkPolicy) so a target’s ingress accepts traffic only from the gateway, plus a reconciliation loop comparing the target’s own activity log against issued authorizations, anything without a matching envelope raises an alert. Why last: it’s a property of a customer’s deployment, proven by a partner’s security team trying to break it, not by a unit test. Unlocks (permanently scoped): “Non-bypassable per integrated system under the reference deployment; bypass detected everywhere.” The unscoped “non-bypassable, period” claim is never made, see Security.

​

Other tracked gaps

​

The permanent ceiling, never claimed, on principle

Directly from 02-REMAINING.md, matching CLAIMS.md §5: unscoped “non-bypassable,” absolute prevention of all unauthorized execution, tamper-proof operation in every environment, guaranteed regulatory compliance, elimination of all software defects. These are not “not yet” items, they’re claims Parmana does not intend to ever make unscoped, because no implementation could honestly back them.