What it solves
Your AI agent wants to refund a payment. The naive integration hands it the payment provider’s credentials directly and trusts its judgment. Instead, with Parmana:- Your code proposes the action (who, what, why, with what supporting facts).
- A policy decides, deterministically, based on the facts you supplied (amount limits, verification status, risk score, whatever the named policy actually checks).
- Your system executes only if approved — a rejected proposal raises an exception before any downstream call happens.
- Proof is recorded: a cryptographically signed Execution Trust Record, independently verifiable without trusting Parmana’s word for it.
When to use it
Reach for the SDK if:- You have an AI agent (LangChain, CrewAI, a custom loop) that takes actions with real consequences.
- You need a durable, signed record of who did what and why, for audit or compliance.
- You want a named, versioned policy to make the call, not inline
ifstatements scattered through agent code. - You’re wiring an agent into a payment, CRM, or infrastructure connector.
Core concepts
Three objects, one call in between:execute() runs the policy decision and the
connector call in one request. If the policy denies the transaction, execute() raises
ExecutionRejectedError instead of
returning; if it approves, the connector runs and you get back a signed
ExecutionTrustRecord with the decision embedded.
BusinessTransaction
What you propose, built withcreate_business_transaction() rather than assembled by hand — see
Why the builder function, not five nested
objects for what it protects
you from:
principal_id— who’s proposing this (an agent id, service name, or user id); checked against your API key’s ownallowed_principal_idsserver-side before anything else runs.action— the capability being invoked, e.g."paytm:refund".parameters— the business data for the action itself (amount, currency, whatever the connector needs).policy— which named, versioned policy evaluates this transaction.signals— the facts the named policy actually checks. Every fact a policy rule references must be present here, or the policy has nothing to evaluate.
ExecutionTrustRecord
What comes back onceexecute() succeeds — a signed record of the decision, the connector’s
evidence, and the resulting proof:
Rejection is an exception, not a status field to check
A denied transaction never produces a 200 response with a “REJECTED” status embedded in it — the server returns a real403 and the SDK raises:
Installation
Quick example
Real-world example: a refund an agent proposes
paytm:refund connector holds its own
credentials, resolved server-side; see Credential isolation.
What Parmana guarantees
- The agent never holds the connector’s own credentials — see Credential isolation.
- The same transaction, evaluated against the same policy version, produces the same decision — policy decides, not agent judgment; see Policies and the decision.
- Every authorization is single-use and time-bounded — see The gateway.
- Execution produces a cryptographically signed proof, independently verifiable — see Execution Trust Records and Verify independently.
- What’s explicitly not guaranteed (compliance certifications, unscoped “non-bypassable” claims, and more) is listed plainly in Limitations — read that before making claims of your own downstream.
Next
Python SDK Quickstart
Get running end-to-end in under 10 minutes.
Python SDK for AI Agents
Wire this into LangChain, CrewAI, FastAPI, and async agent code.
Python SDK Production
Error handling, audit logging, and a deployment checklist.
Python SDK reference
The complete, verified API surface: every method, every error, the test
suite backing it.