Skip to main content
Parmana is often compared with tools a team already has. This page sets out what each kind of tool answers, what Parmana adds, and where Parmana is weaker. It compares categories, not products: products differ and change, so check the ones you use. The short version. IAM decides who may call an API. An API gateway decides whether a request may pass and how fast. A guardrail decides whether text looks harmful. Parmana decides whether one specific action, with its exact parameters, may run now, requires a person’s signed approval for it, and signs a record of what ran and what was refused that anyone can verify offline. It does not replace the others; it sits after them, in front of the actions an agent takes.

​
What each answers

​
Where Parmana adds something

  • A person per action, not per role. A scope or role grants a class of actions for a long time. A Parmana approval covers one action on one resource, up to one amount, once, until it expires (15 minutes by default, at most 24 hours), and is signed by a registered approver (Human approval).
  • The agent never holds the credentials. The gateway holds them and releases each action only after checking the signed authorization (Credential isolation). A guardrail or an in-agent confirmation can be skipped by an agent that holds the keys; Parmana’s check cannot be skipped by an agent that does not.
  • Evidence, not logs. Each action and each refusal has a signed record a regulator, auditor or customer can verify without access to your systems (Execution Trust Records, Refusal records).
  • Governed rules. Policies, approvers and external connectors change only through a second person, and each change is signed (Maker checker).

​
Where Parmana is weaker

  • It does not read text. Parmana does not detect prompt injection, toxic output or data leakage in what the model says. Use a guardrail for that. Parmana limits what an injected agent can do, not what it says.
  • Only actions that go through it. Parmana enforces nothing at the network level. An agent that holds other credentials, or a system reached another way, is outside it.
  • A person in the loop is slow by design. Requiring approval adds human latency to every action that needs it. Policies decide which actions need it; most teams require it only above a risk threshold.
  • Facts the agent declares are not checked against another system. They can only cause a refusal, never an approval (G-51). A policy engine fed from your own systems can use facts Parmana does not see.
  • Approvers are not yet limited to particular actions or policies (G-50). IAM can scope who approves what more finely today.
  • Few ready made connectors. HubSpot, GitHub, Paytm and Slack are built in; anything else goes through a registered external endpoint or a connector you write (Connect any external system). An API gateway already fronts all your APIs.
  • Young, with a small operational surface. No metrics, tracing or dashboards yet; key custody is local files or AWS KMS only. IAM products and API gateways have years of production use, scale and operations tooling behind them. See Limitations and the Roadmap.

​
Using them together

A typical stack, outside in:
  1. IAM authenticates the agent and the people, and issues the agent a Parmana caller key only.
  2. An API gateway in front of Parmana handles TLS, routing, quotas and network policy.
  3. Guardrails check the model’s input and output text.
  4. Parmana checks each proposed action against its policy, requires a signed approval where the policy says so, releases it through the gateway with the credentials it holds, and signs the record.
  5. Your logging and SIEM collect Parmana’s records alongside everything else; the records stay verifiable on their own.
A policy engine you already run can sit beside step 4 for decisions that need facts from your systems; Parmana’s policy still decides release.

​
Next