I/O Mesh v1 fails closed. Five cases return deny to the caller:
- The audit write fails.
- The store returns an error.
- The decision times out. Default is 5 seconds.
- Confidence in the decision is uncertain.
- The grant map is full.
Each of these returns deny to the caller.
One more case is different. If an allow cannot be delivered (for example a slow client is cut off), the grant is dropped before the handler returns. The caller gets no usable answer. The audit record for that decision is an allow; the grant does not stay.
The decision tree
The harness asks I/O Mesh before a tool runs. Walk the request through the failure checks:
Can the store be read? No: deny.
Did the decision finish inside the timeout? No: deny. The default is 5 seconds.
Is confidence certain? No: deny. Any other confidence is a deny.
Is there room in the grant map? No: deny. Active grants sit under a configurable cap. When the map is full, new requests are denied.
Did the audit record write? No: deny. One audit record per decision is the rule. A decision with no record does not become an allow.
Was the allow delivered? If the response cannot be written, the decision stays on the record as an allow, but the grant is revoked before the handler returns. The caller gets no usable answer, so the tool cannot run on it.
Only a request that gets through all of that, passes policy, and is delivered to the caller leaves a grant the tool can use.
Why audit failure is a deny
This one gets pushback. "The policy said yes, the log just failed. Why block the user?"
Because the allow without a record is the exact thing an auditor will ask about later, and you will have nothing to show them. If you cannot write the evidence, you do not take the action. Treat the audit path as part of the decision, not a side effect of it.
Why timeout is a deny
The decision deadline defaults to 5 seconds. Past that, the answer is deny, and no grant is stored. That window is meant to be far above a healthy decision path. If a decision takes that long, something is wrong, and an allow would be a guess. Measure the check in your own environment.
Why a full grant map is a deny
A full map means I/O Mesh cannot track a new grant. Allowing anyway would mean allowing something it cannot account for. Size the map for your workload, watch it, and raise it before it fills.
What this means for on-call
Failing closed moves the pain. Instead of a quiet security gap, you get loud denies. Plan for that.
- Monitor I/O Mesh like a dependency. Store health, latency against the timeout, grant map usage.
- Read reasons in the audit record. The caller gets a plain deny. The reason is on the audit record only. When a team says "the agent keeps getting denied," that is where you look.
- Remember the audit write case. If the audit path itself is what failed, you will see it in your own monitoring of that path before you see it in the records.
- Placement. I/O Mesh is not a proxy. It can sit behind an API proxy you already run. Its failure modes are its own: five return deny; an undelivered allow drops the grant.
The trade
Fail closed costs availability when I/O Mesh or its store has a bad day. Fail open costs you the policy check exactly when nobody is watching. For tool calls that move money, change config, or touch customer data, the first cost is the one you can recover from.
If your current agent setup has an "if the check errors, proceed" branch anywhere, find it before an incident does.
I/O Mesh runs in your own environment. Learn more at iome.sh, or email hello@iome.sh to talk with us about Enterprise.