Capability · Approval gate
Propose → approve → dispatch. Default-deny.
Default-deny control: mutation-capable tool calls become pending proposals and wait for your decision before anything is dispatched.
monopea never lets an agent act outward on its own say-so. Every mutation-capable tool call — send the email, update the record, move the money — is drafted as a proposal: the exact tool, the exact arguments, held in a pending state while the run blocks and waits for your decision.
That is the whole architecture in one sentence: propose → approve → dispatch. The agent plans and drafts at machine speed; outward execution happens only after a human decision — or under a policy you granted explicitly, on the record, in advance.
How the propose → approve → dispatch lifecycle works
When the agent decides an action is needed, it does not execute the call. It writes a proposal — tool name, full arguments, context — and the run enters a blocked state until you approve or reject it. Only an approved proposal is dispatched, and every step of that lifecycle is logged.
You see exactly what would run before it runs. Approve, and the call dispatches immediately; reject, and the agent takes the feedback and re-plans. There is no third path where an ungated action slips through: a call either matches a policy you granted or it waits for you.
- The agent drafts the exact call — tool and arguments — before anything runs
- The run blocks until you decide; approval is what dispatches the call
- Rejections feed back into the plan instead of failing silently
Why default-deny is the right default
Most agent frameworks execute tools by default and rely on prompt instructions to behave. monopea inverts that: dispatch is denied unless a decision or an explicit policy allows it. A tool the platform has never evaluated fails closed — its calls route to review automatically, because unknown should never mean allowed.
The gate lives in the runtime, not the prompt. A system-prompt instruction can be argued out of by a clever input; an architectural gate cannot. Whatever model you run — Claude, GPT, or a Swiss-hosted open-weight model — the same gate sits between it and your tools.
Grant autonomy explicitly, per tool and per agent
Default-deny does not mean approving everything forever. When you trust a specific action, you grant a policy for it — scoped to a tool, an operation, and an agent — and matching calls then dispatch without a pause. Every grant is an auditable record you can review and revoke, not a hidden setting.
In practice, autonomy expands at the pace of your confidence. Week one, everything stops for review. By week four, the routine, low-risk plays flow on standing grants while anything novel or sensitive still waits. The agent gets faster; your exposure does not grow silently.
- Policies are scoped per tool, per operation, and per agent
- Every grant is explicit, logged, and revocable
- Sensitive and unknown actions keep stopping for you
Built for EU AI Act Article 14 oversight
Article 14 of the EU AI Act, enforceable since August 2026, requires effective human oversight of high-risk AI systems — oversight implemented as a real control, not a suggestion in a prompt. monopea’s proposal gate is exactly that kind of control: external to the model, enforced by the runtime, and evidenced in logs.
Every proposal, approval, rejection, and dispatch is written to the audit trail, and audit-chain checkpoints are Ed25519-signed so the record is tamper-evident. monopea was built for this oversight model — that is an architectural fit, not a certification claim.
Why it matters
No surprise actions
Outward actions are drafted and held, not fired. You see the exact call before it exists in the world.
Autonomy on your terms
Grant standing policies for the plays you trust; everything else keeps stopping for you.
Unknowns fail closed
A tool the platform has not evaluated routes to review by default. Unknown never means allowed.
Evidence, not assurances
The full decision history is logged and Ed25519-signed, so oversight is provable after the fact.
FAQ
Approval gate, in short
- What happens when the agent wants to do something risky?
- The action becomes a pending proposal — exact tool and arguments — and the run blocks until you approve or reject it. Nothing is dispatched while it waits. Reject it and the agent re-plans with your feedback instead of pushing through.
- Does every single action require my approval?
- No — that would make autonomy pointless. Mutation-capable calls are held by default, but you can grant per-tool, per-agent policies so trusted, low-risk actions dispatch without a pause. Every grant is explicit, logged, and revocable.
- What happens with a tool Monopea has never seen?
- It fails closed. Calls from unknown or unevaluated tools are routed to review automatically rather than dispatched — default-deny applies most strictly exactly where knowledge is thinnest.
- Is this EU AI Act Article 14 compliant?
- monopea’s gate was built for the oversight Article 14 describes: a human control external to the model, enforced by the runtime, with a signed audit trail as evidence. That is an architectural fit, not a certification — no formal certification has been obtained.
- Is the approval history verifiable?
- Yes. Every proposal, decision, and dispatch is logged, and audit-chain checkpoints are Ed25519-signed, so the history is tamper-evident rather than just a database row.
Keep exploring
Secrets vault
A write-only vault: the agent references {{secret:NAME}}, the plaintext is substituted only at dispatch, and the model never sees the value.
Audit trail & live activity
Every proposal, decision, and dispatch on a signed, tamper-evident record — with a live view of what is running right now.
Delegation & sub-agents
Big jobs fan out to sub-agents that run in parallel — every one of them inheriting the same approval gate, and all of them stoppable at once.