Fix: strip client-supplied X-Agent-ID/X-Task-ID to close agent impersonation

[CatCatUncle]

Problem (security)

A workspace member authenticating with a normal JWT/PAT can assume any agent's identity within their workspace, with no extra privileges.

resolveActor (server/internal/handler/handler.go) has a fallback: if the request carries X-Agent-ID + X-Task-ID and task.AgentID == agentID, the caller is resolved as actorType="agent". The only "proof" required is knowledge of a valid (agent_id, task_id) pair — but both ids are returned by member-readable endpoints:

• GET /api/issues/{id}/task-runs (ListTasksByIssue)
• GET /api/agents/{id}/tasks (ListAgentTasks)

Both return AgentTaskResponse{ id, agent_id, ... }.

Exploit

1. As an authenticated member, call one of the list endpoints above and read a real (agent_id, task_id) pair.
2. Replay them as X-Agent-ID / X-Task-ID headers on your own authenticated request.
3. task.AgentID == agentID passes trivially (it's a real pair).
4. You are now treated as actorType="agent" — you can author comments/issues as that agent, and bypass the private-agent gate (agent-to-agent flows trust actorType=="agent").

The existing code comment claims requiring both headers "closes the impersonation path" — it doesn't, because the task id is just as observable as the agent id.

Fix

Auth and DaemonAuth middlewares now strip any client-supplied X-Agent-ID / X-Task-ID on entry, right alongside the existing X-Actor-Source strip. The only code that sets these headers is the server-controlled mat_ task-token branch (which re-stamps them from the token row after stripping). So agent identity now flows exclusively from the unforgeable task token (MUL-2600).

resolveActor's fallback is intentionally kept (it is now unreachable from the network, since every route that reaches it goes through one of the two stripping middlewares) so in-process callers and handler unit tests can still assert agent-actor behaviour by setting the headers directly. Its doc comment is corrected to state it is not a security boundary — the middleware strip is.

Changed files

• server/internal/middleware/auth.go — strip X-Agent-ID / X-Task-ID
• server/internal/middleware/daemon_auth.go — same, for uniformity/defense-in-depth
• server/internal/handler/handler.go — corrected resolveActor doc comment (behaviour unchanged)

Tests

• TestAuth_StripsForgedAgentIdentityHeaders — a valid member JWT + forged X-Agent-ID/X-Task-ID reaches the handler with both headers cleared.
• TestDaemonAuth_StripsForgedAgentIdentityHeaders — same invariant on the daemon path (Redis-gated, mirrors the existing StripsClientSuppliedActorSource test).

go build ./..., go vet ./internal/middleware/ ./internal/handler/, and go test ./internal/middleware/ -run 'TestAuth|TestDaemonAuth' all pass; existing handler tests that set these headers directly (squad/subscriber/agent_env) are unaffected since resolveActor's fallback is preserved.

Note: disclosed as a public PR at the reporter's request. Maintainers may prefer to coordinate via a private security advisory.

🤖 Generated with Claude Code

[vercel]

@unclecatai is attempting to deploy a commit to the IndexLabs Team on Vercel.

A member of the Team first needs to authorize it.