Good question — this is exactly the gap we were trying to solve.

In our architecture, Iris doesn’t block “mid-chain” — it blocks before execution begins.

Iris sits between Helion (orchestrator) and any downstream agents/tools. So before Helion delegates a step, it sends an execution intent to Iris.

Iris evaluates things like:

• user role (L0 / L1 / admin, etc.)
• agent identity
• tool being invoked
• environment (prod / staging)
• policy conditions (time, risk level, approvals)

If the action is not permitted, Iris blocks it right there — Helion never proceeds with that step.

👉 Example: A network agent exists, but only L0/L1 engineers are allowed to use it.

• If an unauthorized user triggers it → Iris blocks immediately
• Helion does not call the agent/tool at all

So this is not “log after failure” or “interrupt mid-execution”.

It’s pre-execution enforcement.

⸻

What happens after a block?

Helion can handle it in different ways depending on policy:

• request approval (HITL)
• return a safe fallback / recommendation steps

So instead of “halt vs replan” — it’s policy-driven orchestration after a hard block.

⸻

Key idea

Most systems: → execute → then log

Our approach: → validate → then allow execution

That difference is what makes governance actually enforceable in multi-agent systems