Composio contract gate auto-executes tools after failing to surface the contract 4 times

[Al629176]

Description

The Composio contract gate ([composio][contract-gate]) is meant to surface a tool's contract to the user before first execution. When the surface never reaches the user — which is what happens today — it counts "fresh instances surfaced without execution", and after a threshold auto-proceeds and executes the tool anyway. So a consent mechanism degrades, silently, into an execution mechanism.

Reported by: Alan (QA)
Build: v0.63.29
Reproducible: Yes — 14 occurrences in 8 minutes on GITHUB_LIST_REPOSITORY_ISSUES

Steps to reproduce

1. Connect GitHub via Composio
2. Ask the agent something that needs GITHUB_LIST_REPOSITORY_ISSUES (e.g. "which of my open issues mention X")
3. Observe:

14:45:53 WRN [composio][contract-gate] auto-proceeding after 4 fresh instances surfaced this contract without execution slug=GITHUB_LIST_REPOSITORY_ISSUES global_count=4
14:45:53 WRN [composio][contract-gate] auto-proceeding after threshold; executing without surfacing slug=GITHUB_LIST_REPOSITORY_ISSUES
14:46:12 WRN … after 5 fresh instances …
   … through global_count=17 by 14:54:02

No contract card was ever shown in the UI.

Expected behaviour

• The contract is surfaced to the user once, and execution waits for acknowledgement (or the gate is explicitly configured to be advisory)
• If the surface cannot be reached, the gate fails closed with a clear reason — it does not execute

Actual behaviour

• Contract never rendered; after 4 attempts the gate executes without consent and keeps doing so on every subsequent call, incrementing a counter
• Read-only tool in this instance, but the same path applies to write tools

Impact

• Consent gate provides no consent: any late-bound Composio action can run after 4 silent misses
• Security-relevant for write actions (send email, create issue, post message)
• Log noise: 28 WRN lines for one user question

Acceptance criteria

• Contract gate never executes a tool whose contract was not acknowledged; "auto-proceed after threshold" is removed or gated to read-only tools with an explicit config flag
• When the surface is unreachable, the tool call fails with a user-visible reason
• Root cause of the surface not rendering is fixed (shares cause with the background-approval bug)
• Related design: Unified late-bound tool contract gate with compaction-safe transcript presence #5038 (unified late-bound contract gate), fix(composio): gate per-action tools on their full contract (#4853) #4995
• Reproducible on v0.63.29 — confirm fix in next build

[tinysweeper]

The Composio contract gate silently auto-executes tools after failing to surface the contract 4 times, so a consent mechanism degrades into automatic execution. Although the reported case used a read-only tool, the same path applies to write actions, making this a security-relevant bug. It should be treated as p0 and fixed by failing closed when the contract cannot be surfaced, not by proceeding after a threshold.

Labelled priority: p0.

[M3gA-Mind]

The behaviour you captured is real and still present on 0f1ecc9d28d85289ee3f87ade13156be02ffbd28, but I think the security framing is off, and it changes what the fix should be.

The contract gate is model-facing, not a user-consent gate. It never had a UI card, so "no contract card was ever shown" is expected rather than a failure. From the module header, crates/openhuman-core/src/integrations/composio/contract_gate.rs:11-18:

The gate makes the full contract enter context BEFORE execution: on the first call to an action this turn … it is returned as a recoverable tool error instead of executing. The retry — now with the schema/description in context — proceeds normally.

And the call site confirms it, integrations/composio/action_tool.rs:314-319:

super::contract_gate::GateDecision::Surface(contract) => {
    return Ok(ToolResult::error(contract));
}

That is a tool error handed back to the model. It exists to stop the model guessing argument formats (#4853 — the unquoted Gmail query bug), not to ask you for permission.

Write consent is a separate mechanism and is not weakened by auto-proceed. Composio write actions gate through external_effect_with_args → the approval gate, independent of this counter. integrations/composio/action_tool_tests.rs:100-117 asserts GMAIL_SEND_EMAIL → true, GMAIL_FETCH_EMAILS → false. That is also consistent with your own observation in #6406 that an in-thread GMAIL_SEND_EMAIL approval renders and works. So "any late-bound Composio action can run after 4 silent misses" doesn't hold for write actions — they still need approval.

There is a real bug here, though, and it's the counter's lifetime. GLOBAL_FIRST_CONSULT_COUNT (contract_gate.rs:73) is a process-wide map written in exactly one place (:125) and never reset, decayed, or scoped to a turn — I grepped; those are the only two references. Once a slug's count passes AUTO_PROCEED_THRESHOLD = 3 (:79), every subsequent gate instance for that slug auto-proceeds for the remaining life of the process. Your log shows exactly that: global_count climbing 4 → 17 and never recovering.

The consequence is not ungated execution — it's that the #4853 protection silently switches itself off. After ~4 sub-agent spawns, GMAIL_FETCH_EMAILS stops receiving its schema, and the unquoted-query-returns-nothing bug the gate was built to prevent comes back for the rest of the session.

Proposed fix. Scope the counter to a turn/run rather than the process (reset it at turn boundaries alongside the existing per-instance seen set), so the safety net still breaks the #5119 re-delegation loop but cannot permanently disable schema surfacing. Worth pairing with #6414: the reason so many fresh integrations_agent instances spawn per question is that the orchestrator is rebuilt every turn, which is what drives global_count up this fast.

Test that would prove it. Drive gate_consult past the threshold for one slug, cross a turn boundary, and assert the next fresh instance returns FirstTime (surfaces the contract) rather than AutoProceed. That test fails on main today.

Separately: if a genuine user-facing consent surface for late-bound Composio actions is wanted, that's #5038's scope, and it would be new work rather than a repair of this gate.