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
The last sentence of that quote is now partially stale, in a good way. As of commit
651497a (2026-07-11), the default server wires the gateway unconditionally and routes the
one connector it registers (vendor-payment) through credential
isolation: for that specific path, the calling AI does not
hold the execution credential, the gateway does, briefly, and only inside its own boundary.
Move 2 below is updated accordingly. Move 1 and Move 3 are unaffected.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. This is the exact exposure class that
produced the committed-key incident on Security.
Unlocks: “Parmana’s signing key cannot be exfiltrated from the application process.”
Open design questions (from the strategy doc, not yet resolved): does AWS KMS support
Ed25519 natively, or does this force a move to ecdsa-p256 (already declared in
SignatureAlgorithms)? ML-DSA in KMS is not yet broadly available. The claim only promotes
to Supported once a live test against a real KMS key has run, a fake/mock passing
proves nothing here.
Move 2: Credential brokering, [PARTIAL], wired for one 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 currently registered (vendor-payment), 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 / K8sNetworkPolicy) 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
| Item | Status | Detail |
|---|---|---|
| Additional SDKs (Go, Java, .NET, …) | [ROADMAP] | No source exists. See Other Languages. |
| Real third-party connectors (SAP, Salesforce, Oracle, Workday, …) | [ROADMAP] | HttpConnector and MockConnector are reference implementations; four enterprise-named connectors exist as explicit, self-documented mocks (packages/connector-sdk/src/connectors/{sap,oracle,workday,salesforce}/), deterministic, in-memory, standing in until a real one is built. None of the four is wired into the default server’s connector registry. See The gateway. |
postgres / sqlite storage providers | [ROADMAP] | Declared in the type union, throw “not implemented” at construction. See Storage. |
| Replay semantic verification of the full record | [ROADMAP] | POST /replay is a signature recheck only. packages/replay’s ReplayEngine does genuinely re-evaluate the recorded policy decision, real, tested, verified live, but scoped to one execution and disconnected from the API. CLAIMS.md §4’s broader “every trust artifact” claim remains unbuilt. See Replay. |
| Algorithm migration (re-key Ed25519 → ML-DSA-65, verify old records) | [ROADMAP] | AuthorizationVerifier supports exactly one configured PRIMARY_SIGNATURE_PROVIDER at a time. |
| Structured logging / observability | [ROADMAP] | LOG_LEVEL is parsed into config; nothing currently reads it to configure a real logger. Errors go to console.error. No metrics, tracing, or dashboards exist. |
| Nonce store persistence (Redis/Supabase-backed) | [ROADMAP] | MemoryNonceStore is the only implementation; loses state on restart (CLAIMS.md 3.2). |
| Authority/Intent/Evidence verification checks | [ROADMAP] | Only integrity, signature, and authorization-binding exist in verification-service.ts today (CLAIMS.md 2.15/§4). Open question on record: does an Authority check add anything the signature check doesn’t, before a key/authority registry exists? |
| API authentication | [ROADMAP] | No auth middleware exists on any route today. |
POST /policies/validate semantics | Flagged, not scheduled | Validates policy-existence, not a submitted document, naming mismatch. See core-API findings. |
POST /transactions vs POST /execute duplication | Flagged, not scheduled | Same core-API findings note. |
| A general-purpose way to register a new connector | [ROADMAP] | Today, adding a connector to the running server means editing createConnectorRoute.ts, createConnectorRegistry.ts, and createConnectorAuthenticator.ts, a code change, not configuration. See The gateway. |
The permanent ceiling, never claimed, on principle
Directly from02-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.