Why I write this down
Every security product has a boundary. The dishonest ones leave it implicit and let you discover it in an incident review. I would rather you read it here first, so you can decide what else you need around Parmana. The repository has a threat model that lists who is in scope and who is not, and a limitations page that lists every open issue with its evidence. This post walks through them in plain words.Who Parmana defends against
The threat model names the attackers Parmana is designed to stop:- someone on the network with no credentials;
- a caller with a valid agent key who controls the whole request, which includes a prompt-injected or compromised agent;
- someone who captured a valid authorization or a used approval and tries to replay it;
- someone holding one governance credential, a maker or a checker, but not both;
- someone who can read or alter stored records but holds no signing key.
Who it does not defend against
The same document lists attackers that are out of scope. Against most of them, the attack succeeds.- Someone holding a key that matters. An approver key signs valid approvals. The signing key signs valid authorizations. A connector credential calls the system directly. Parmana assumes these are not compromised.
- Someone who can write to the database. Parmana’s checks assume the database is not attacker-writable.
- One person holding both maker and checker credentials. The server cannot tell that two credentials belong to two people. In the current production deployment (October 2026), one person holds both. That person is me.
- An agent with its own credentials. If the refund agent also holds a payment API key, it can refund without ever calling Parmana. Parmana governs only actions routed through it. This one has to be closed downstream, by making the system accept only Parmana’s signed release.
- Whoever controls the host, image or source Parmana runs from. They can change what it enforces.
What it cannot stop even inside the boundary
- It does not detect prompt injection. It limits what an injected agent can achieve. It does not read the model’s input or output.
- A persuaded approver. Parmana checks that a trusted, unrevoked key signed the approval. It cannot check that the person read the request.
- Parameters an approval does not fix. An approval covers the action and the resource, and the amount where the policy names one. A Slack approval does not fix the message text; a HubSpot approval does not fix the new deal stage. Within an approved action, those are the agent’s choice.
- A policy written too broadly. Signatures prove which policy ran, unmodified. They do not prove the policy is right.
- Approvers are not scoped. Any trusted approver can approve any action, and any human checker any policy change. Today one approver key is trusted in production.
- Facts the agent declares. Most are not checked against another system. They can only cause a refusal. Connecting the system that owns a fact is built, but no real one is connected.
- Daily totals. Limits are per request. “₹1,00,000 per day” is designed, not built.
- What an external endpoint says. Its answer is recorded as its claim, not as proof it acted.
- Some history tampering. Audit events are chained per caller, so a deleted row breaks the chain. Deleting a caller’s whole history, or reordering rows across callers, is not caught that way.
- Load. There is no load guarantee and no throughput test. An approved request took 24 to 32 seconds in production.
Against the OWASP lists
I mapped Parmana to the 2026 OWASP Top 10 for LLM Applications and for Agentic Applications. Two entries are rated “Covered”: excessive agency, and tool misuse, both only for actions that go through Parmana. Most are “Partly”. Several are “Not covered” because they are about the model itself: data and model poisoning, misinformation, vector and embedding weaknesses, unexpected code execution, memory poisoning, and messages between agents. Parmana does not see the model. Where it still limits the damage, the mapping says how: a poisoned or mistaken model still cannot act without a signed approval.What it does not do, ever
Some things are not “not yet”. The roadmap calls them the permanent ceiling, and the claims register lists them as claims Parmana intentionally does not make:- that execution is impossible to bypass under all circumstances, or “non-bypassable” as an unscoped claim;
- absolute prevention of all unauthorized execution;
- tamper-proof operation in every deployment environment;
- mathematical proof of execution correctness, or cryptographic proof of every aspect of runtime behaviour;
- guaranteed regulatory compliance;
- elimination of all software defects or operational risks;
- that enforcement adds no overhead.