[Security] Cross-Agent Authorization Bypass in `/v1/tools/invoke` Allows Unauthorized Cron Binding to Foreign Agents

Advisory Details

Title: Cross-Agent Authorization Bypass in /v1/tools/invoke Allows Unauthorized Cron Binding to Foreign Agents

Description:

Summary

An authenticated caller with only operator.write privileges can use the documented HTTP tool invocation endpoint, POST /v1/tools/invoke, to create a cron job bound to another user’s private agent. Direct reads of that same foreign agent are correctly blocked with 403, but the cron creation path accepts an attacker-controlled agentId without an access check and persists the unauthorized binding into cron_jobs.agent_id. This creates a stored cross-agent authorization bypass that the scheduler later trusts as the execution target.

Details

The defect is in the HTTP direct-tool entry point. In internal/http/tools_invoke.go, the handler accepts top-level request field agentId, resolves it with agentStore.GetByKey, and injects the resolved UUID into context with store.WithAgentID, but never calls CanAccess before doing so.

if agentIDStr != "" && h.agentStore != nil {
    ag, err := h.agentStore.GetByKey(ctx, agentIDStr)
    if err == nil {
        ctx = store.WithAgentID(ctx, ag.ID)
    }
}

That matters because direct agent reads do enforce authorization. In internal/http/agents.go, GET /v1/agents/{id} checks h.agents.CanAccess(...) and returns 403 when the caller is not allowed to access the target agent.

Once the attacker-controlled agent UUID is present in context, the cron tool consumes it in internal/tools/cron.go through resolveAgentIDString(ctx) and passes it into handleAdd(...). The same function also accepts an explicit job.agentId override, which can replace the context agent again before persistence:

// Use agent ID from job object if explicitly provided, otherwise from context
if explicit, _ := jobObj["agentId"].(string); explicit != "" {
    agentID = explicit
}

job, err := t.cronStore.AddJob(ctx, name, schedule, message, deliver, channel, to, agentID, userID)

The SQLite cron store then writes that UUID directly into the persisted cron row:

var agentUUID *uuid.UUID
if agentID != "" {
    if aid, err := uuid.Parse(agentID); err == nil {
        agentUUID = &aid
    }
}

_, err := s.db.ExecContext(ctx,
    `INSERT INTO cron_jobs (..., agent_id, user_id, ...) VALUES (...)`,
    ...,
    agentUUID, userIDPtr, ...
)

Finally, the scheduler trusts the stored job.AgentID as the future execution target. In cmd/gateway_cron.go, the cron runner resolves job.AgentID back into an agent key and builds the cron session using that foreign-bound target:

agentID := job.AgentID
...
if ag, err := agentStore.GetByID(cronCtx, id); err == nil {
    agentID = ag.AgentKey
}
sessionKey := sessions.BuildCronSessionKey(agentID, job.ID)

In a live local verification against the real HTTP API, I observed the following:

1. GET /v1/agents/owner-b-agent as ownerA returned 403.
2. POST /v1/tools/invoke as ownerA with tool=cron and agentId=owner-b-agent returned 200.
3. The resulting SQLite row stored user_id=ownerA while agent_id resolved to owner-b-agent, owned by ownerB.

That shows a real authorization boundary mismatch rather than a theoretical code smell.

PoC

Prerequisites

• A checkout of the canonical repository https://github.com/nextlevelbuilder/goclaw
• Python 3 available locally
• Go toolchain available to build the sqliteonly binary
• No external model/provider is required for proving the vulnerable binding itself
• The PoC assumes localhost access only and launches an isolated SQLite-backed gateway instance on 127.0.0.1:18891

Reproduction Steps

1. Download the PoC helper from: gist-common.py
2. Download the exploit PoC from: gist-verification.py
3. Download the control script from: gist-control.py
4. Place the three files in the same directory.
5. From the repository root, run the exploit PoC:
   python3 gist-verification.py
6. Confirm the baseline protection works first:
   the script prints a 403 result for GET /v1/agents/owner-b-agent as ownerA.
7. Confirm the vulnerable path succeeds:
   the script then sends POST /v1/tools/invoke with tool=cron and agentId=owner-b-agent, receives 200, and prints the returned cron job payload.
8. Confirm the persisted unauthorized binding:
   the script reads the SQLite database and prints a row where user_id is ownerA but the bound agent_key is owner-b-agent and owner_id is ownerB.
9. Run the control case:
   python3 gist-control.py
10. Confirm the control stays within scope:
    the control stores a cron job bound to owner-a-agent, showing the issue is specifically caused by the foreign target selection rather than a broken cron subsystem.

Log of Evidence

Observed exploit log:

[STEP] GET /v1/agents/owner-b-agent as ownerA => 403 {'error': {'code': 'UNAUTHORIZED', 'message': 'no access to this agent'}}
[STEP] POST /v1/tools/invoke add foreign cron => 200
[OBSERVE] cron row {"bound_agent_key": "owner-b-agent", "bound_owner": "ownerB", "job_id": "...", "user_id": "ownerA"}
[DEFECT-CONFIRMED-WITH-LIMITATIONS] operator.write caller can persist a cron job bound to a foreign owner agent

Observed control log:

[STEP] GET /v1/agents/owner-b-agent as ownerA => 403
[STEP] POST /v1/tools/invoke add local cron => 200
[OBSERVE] cron row {"bound_agent_key": "owner-a-agent", "bound_owner": "ownerA", "job_id": "...", "user_id": "ownerA"}
[CONTROL-PASS] Removing the foreign target override keeps the cron job bound to the caller-owned agent

One limitation is worth stating clearly: I also attempted to force a cron run through the same public interface, but the minimal harness had no usable model/provider, so the agent turn timed out before a full model-backed completion. That does not affect the core proof here, which is the unauthorized persisted binding and the fact that the scheduler path later trusts that binding.

Impact

This is an authorization bypass affecting scheduled agent execution. A lower-privileged operator can create cron jobs targeting another user’s private agent, even when direct access to that agent is denied. In practice this allows an attacker to plant stored scheduled work that will later run under the foreign agent’s configuration, prompts, tools, and execution context. The exposed asset is not just metadata visibility; it is the integrity of agent ownership boundaries and the scheduler’s trust in persisted work items.

Affected products

• Ecosystem: go
• Package name: github.com/nextlevelbuilder/goclaw
• Affected versions: <= 3.13.2
• Patched versions:

Severity

• Severity: High
• Vector string: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L

Weaknesses

• CWE: CWE-862: Missing Authorization

Occurrences

Start in internal/http/tools_invoke.go and compare its agent resolution with the CanAccess check in internal/http/agents.go. Trace the selected agent through internal/tools/cron.go, internal/store/sqlitestore/cron_crud.go, and cmd/gateway_cron.go. Done means a foreign agent cannot be bound through POST /v1/tools/invoke while the owner-a-agent control case still succeeds; verify with the linked Python PoC and control script.