Issa · Action gateway · Rust
Putting your limits in the system prompt is asking a probabilistic model to enforce its own constraints. Issa sits between the agent and the tool: policy is evaluated before execution, anything irreversible stops for a human, and every decision is recorded.
Fail-closed default · MCP-compatible · SQLite WAL durability
The decision
There is no fourth option, and there is no default-allow. A call that matches no rule is denied — because the failure mode of getting that backwards is an agent doing something you cannot undo.
Matches policy, within limits. Executes and is recorded.
Matches policy but crosses a value or blast-radius threshold. Waits for a human.
Matches no rule, or matches a deny rule. Never reaches the tool.
Guarantees
Fail-closed by default
Every tool call is evaluated against policy before it runs. A call that matches no rule is denied, not allowed — the default has to be the safe one, because the failure mode of getting this backwards is an agent doing something irreversible.
Key-sorted canonical SHA-256
What a human approves is hashed canonically, with object keys sorted, so the arguments cannot be reordered or mutated between approval and execution. Approving "refund 40.00" cannot become "refund 4000.00" in flight.
Atomic reservations, WAL durability
Each call reserves an execution slot atomically before it runs, persisted in SQLite WAL. A retry after a timeout resumes the original outcome instead of performing the action twice.
PII-redacted sequential evidence ledger
Every decision is appended to a sequential ledger with the arguments redacted. When an auditor asks why an agent did something in March, there is a record, not a log level.
Evidence
Sequence number, action, verdict, and the canonical hash of the arguments. Arguments themselves are redacted before writing, so the ledger proves what was decided without storing the payload.
Note entry 415: the same hash as 412, now allowed, because a named human approved that exact payload. A different payload would have a different hash and would not have executed.
| Seq | Action | Verdict | Arg hash | |
|---|---|---|---|---|
| 000412 | erp.postJournalEntry | HELD | 9f2a…c418 | above AED 25,000 |
| 000413 | erp.getTrialBalance | ALLOW | 3b71…08de | read-only |
| 000414 | bank.initiateTransfer | DENY | c0d5…7a19 | no matching rule |
| 000415 | erp.postJournalEntry | ALLOW | 9f2a…c418 | approved by T. Mughal |
Together
They are separate on purpose. The framework that plans a task should not be the thing that authorises it — that is the same mistake as letting the prompt hold the limits.
Questions
Because the model decides which tool to call, and that decision is probabilistic. The gateway is where the non-negotiable rules live: what may run, what needs a person, what never runs. Putting those rules in the prompt means asking the model to enforce its own limits, which is not a control.
MCP is a protocol for exposing tools to a model. Issa is the control plane in front of them. They compose: MCP describes what a tool is, Issa decides whether this particular call, with these particular arguments, is permitted to run right now.
The approval is bound to a canonical SHA-256 hash of the arguments, with object keys sorted so that logically identical payloads hash identically and any change at all produces a different hash. If the arguments change after approval, the hash no longer matches and execution is refused.
Calls fail closed. An agent that cannot reach policy does not get to assume permission. That is the correct trade for anything touching a ledger, and it is why the default is deny, never allow.
No. Arguments are redacted before they are written. The ledger records that a call was made, what was decided, and the canonical hash — enough to reconstruct and verify a decision without storing the payload itself.
Next
We run enterprise audits of agent estates: what tools are exposed, what the blast radius of each one is, and where a human gate belongs.