PERMIXA DOCUMENTATION
Architecture
A financial authorization control plane, with execution enforced independently in the customer's environment.
Three trust boundaries
- Agent runtime: holds an agent credential and sends a typed intent. No wallet keys or raw signing capability.
- Permixa Cloud: authenticates, evaluates policy and budget, selects a permitted route, signs a typed authorization and records evidence.
- Customer environment: the Signer verifies the authorization and local limits, then uses a customer-controlled wallet adapter.
Transport is outbound from the Signer. The customer does not need a public inbound signing endpoint. Providers remain behind adapters rather than defining the core protocol.
Separate authority domains
| Domain | Purpose | Does not grant |
|---|---|---|
| Payment | Bounded agent purchases | Treasury conversion or administration |
| Treasury | Exact approved transfers/conversions | Arbitrary future transfers or local policy expansion |
| Administration | Enrollment, credentials and policy administration | A substitute for the required local execution approval |
Protected cloud signing keys are separated by authority. Wallet secrets remain outside Permixa Cloud. Customer-local hard-policy expansion uses its own administration mechanism.
Authorization and receipt contracts
The versioned protocol binds organization, actor, intended Signer, operation class, source account, exact asset/network, amount, destination, expiry, nonce and relevant intent, route, quote and policy hashes.
Canonical JSON and domain-separated hashes make the signed meaning deterministic. Money uses integer atomic units and decimal strings, not floating-point arithmetic. The reference signature profile uses ES256.
The Signer verifies every binding before adapter execution and signs an independent receipt afterward. Unknown versions, expired authority, mismatched economics and replay fail closed.
Durable state, not a success boolean
Policy approval, budget reservation, authorization, submission and settlement are distinct states. A journal preserves the plan and transaction identity across failures. Signing/submission uncertainty requires reconciliation, never a fresh source payment.
For two-stage treasury approval, cloud approval, customer-local approval and the eventual authorization must bind the same immutable economic version. Approval of version A cannot authorize version B.
Current deployment, not a production claim
The invite demo uses static assets on S3/CloudFront, API Gateway and Lambda, Cognito authentication, private PostgreSQL and separate KMS authority keys. The customer-local Signer keeps its own durable state and wallet connections.
This is a single-AZ proof of concept. Production custody, production resilience, launch/compliance claims and mainnet execution are not enabled by this documentation. A local stdio MCP connector, a macOS companion preview and a separate testnet purchase worker are implemented. A hosted remote MCP endpoint, self-service Signer enrollment and production custody remain unfinished. See the roadmap.
For completed capabilities, assisted setup and remaining work, see the current roadmap.