Skip to main content
The Parmana Python SDK lets you integrate authorization into Python applications, AI agents, and microservices. Before any consequential action executes, your code asks Parmana: “is this allowed?” — and gets back either a signed proof of what happened, or a rejection with a reason.

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:
  1. Your code proposes the action (who, what, why, with what supporting facts).
  2. A policy decides, deterministically, based on the facts you supplied (amount limits, verification status, risk score, whatever the named policy actually checks).
  3. Your system executes only if approved — a rejected proposal raises an exception before any downstream call happens.
  4. Proof is recorded: a cryptographically signed Execution Trust Record, independently verifiable without trusting Parmana’s word for it.
The agent never holds the vendor’s credentials. Policy decides, not the agent’s own judgment call.

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 if statements scattered through agent code.
  • You’re wiring an agent into a payment, CRM, or infrastructure connector.
Skip it if the action is read-only or has no real consequence — plain application logging is enough there; The gateway exists to guard actions that actually change something.

Core concepts

Three objects, one call in between:
There’s no separate “authorize” step to call — 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 with create_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 own allowed_principal_ids server-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 once execute() succeeds — a signed record of the decision, the connector’s evidence, and the resulting proof:
You can verify this independently without trusting Parmana’s word for it — the signature is checkable against a public key you control.

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 real 403 and the SDK raises:
See Errors, correctly mapped to real conditions for the full exception taxonomy — connection failures, malformed requests, and auth failures each raise their own distinct exception, not a generic one you have to string-match.

Installation

Real PyPI package, confirmed against the live registry (see Python SDK for the current published version). Requires Python 3.8+.

Quick example

This is the exact call Quickstart walks through against a local server, with real captured output — see there for the full step-by-step (installing, generating a local Gateway keypair, starting the Runtime) if you haven’t set up a local server yet.

Real-world example: a refund an agent proposes

No separate credential ever reaches the agent — the 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.