The problem with judging
The obvious way to make an agent safe is to put another clever thing in front of it: a second model, a classifier, a prompt that says “be careful with money”. All of these have the same weakness. They can be talked into things, and they can give two answers to the same question on different days. When a payment goes wrong, “the reviewer model thought it was fine” is not an explanation anyone can check. So Parmana starts from the other end. Whatever stands between the agent and the money should be boring, predictable and provable after the fact.Six habits
1. Rules, not judgment. A policy is an ordered list of rules. Parmana reads them top to bottom and the first rule that matches decides. No model call, no randomness, no hidden state: the same policy with the same facts gives the same decision every time. You can read the rule that decided, and so can an auditor. 2. Silence means no. If no rule matches, the request is refused. A missing connector, a check that cannot run, a signing step that is not ready: each of these refuses rather than waves the request through. There is no default allow anywhere in the decision. I would rather explain a refusal than a surprise. 3. A person signs. Every rule that approves anything, in every policy, must require a signed approval from a trusted person for that action and that resource, and for payments and refunds, that amount. Reads included. A policy that could approve without a person is refused when it loads and cannot even be proposed. The agent can claim an approval exists; it counts only if the signature verifies, and each approval is used once. 4. Sign the decision, bind it to the content. An approval becomes a signed execution authorization: valid once, for a short window, and tied by a hash to the exact request that was decided. Change the payee or one rupee of the amount and the authorization no longer fits. 5. Check again at the last moment. The gateway, which actually releases the action, does not trust the authorization it is handed. It recomputes the hash, checks the signature and the expiry, confirms the policy and the approval still hold, and only then marks the authorization as used. It is the one place built to say no even when everything before it said yes. 6. The agent never holds the keys. The credential that performs the action is not in the agent’s hands. A built in connector gets a credential for that one execution, inside the gateway’s boundary. An external system receives a release signed by Parmana that it can check for itself. And underneath all six: write it down, signed. Before release, Parmana signs and stores what it is about to do. After, it signs a record of the request, the decision and what the connector reported. A refusal gets a signed record too. Anyone with the public key can verify these without trusting my server.Why this order
The order is not decoration. A decision must exist before anything can be signed. The gateway checks a claim rather than making one, so it sits after the authorization and before the system that acts, the last point before real state changes. Credentials appear only inside that boundary, after the gateway is satisfied, so nothing upstream ever needs one. Each step does one job and does not trust the step before it.What it does not do
- It does not decide whether the payment is wise. It decides whether a rule a person approved allows it, and whether a person signed. A bad rule, or a careless approver, still gets a signed record.
- It only governs what is routed through it. An agent that keeps its own key to a payment system can go around Parmana. Nothing is enforced at the network level.
- It does not make the agent’s facts true. A fact the agent declares and nothing checks can refuse an action under the shipped policies, never authorize one. Asking the business system that owns a fact is built and deployed, but no shipped policy uses it yet and no real business system is connected.
- The isolation is narrower than it sounds. The session credential layer is in process and in memory today; minting short lived cloud credentials per action is on the roadmap, not built.
- One person is the weak spot today. In Parmana’s own production, as of October 2026, one person holds the maker, checker and approver keys. The records prove which keys signed, not that different people held them.
- It is not fast. Signing, storage writes and a network hop add seconds, not milliseconds.