Skip to main content
No, reads included. Every policy must require a signed approval from a trusted person, for the action and its resource, in every rule that approves: PolicyValidator refuses to load or accept a proposal for a policy that does not. The agent can set the approval signal to true, but it counts only with a valid signed approval, checked before authorization and again at the gateway, and used once. See Human approval. The approval names the action and the resource (and the amount for payments and refunds), not every parameter, and a refused request is not held: the agent sends a new one with the approval.
Within a scope that’s now the default, yes, see Content Binding & TOCTOU and The gateway. The default local server wires the Execution Gateway unconditionally, every POST /execute gets independent content-binding re-verification, and every registered connector runs behind credential isolation, so the calling AI never holds that connector’s credential. What’s still scoped: adding a new connector today is a deliberate bootstrap code change, not something the architecture does for you, and Parmana enforces nothing at the network level, this is a property of a gateway-integrated system, not a network guarantee. See Limitations for the full picture.
It depends on KEY_PROVIDER. With local it’s a PEM file on disk, read by FileKeyProvider. With aws-kms the signing key lives in AWS KMS and is never released, see AWS KMS signing. The gateway attestation key is still a file in both modes. There’s a live incident on record: an earlier committed key was publicly exposed and is permanently compromised (rotated 2026-07-05). Azure Key Vault, Google Cloud KMS and HSM custody are not built, see Cryptography and Roadmap.
Either, both are published and actively maintained. Python’s models are generated from the same TypeScript domain types the server uses, drift-guarded in CI; the TypeScript SDK’s models are hand-maintained and kept in sync against the real schemas. Both raise a typed exception per HTTP status and are tested against a real running server, not just mocks. npm install @parmana/sdk, pip install parmana. See Python SDK and TypeScript SDK.
Not via an SDK, none exists. Call the REST API directly; it’s 14 small, documented routes. See Other Languages.
Yes, ML-DSA-65 (FIPS 204), selectable via PRIMARY_SIGNATURE_PROVIDER=dilithium3, real and tested. Requires Node ≥ 24. Its signatures are randomized, not deterministic, don’t build tooling that assumes otherwise. See Cryptography.
Two different things share the name, and neither is what you might assume. See Replay, this is worth reading in full before relying on either.
Not anymore, under that name. An early prototype used it; it was deleted the same session it was replaced by the current SignedExecutionAuthorization + Execution Gateway architecture, which is what actually ships. See Glossary.
Yes. Every route except /health, /ready, /openapi.yaml, and /documentation requires a bearer key and fails closed with a 401 if it’s missing or wrong (createCallerAuthenticator.ts). See Authentication. This is a separate question from whether the underlying business action was authorized, see Security for that boundary.