Paperclip: Approval decision attribution spoofing via client-controlled `decidedByUserId` in paperclip server

Secondary sink (budget policies) — server/src/services/approvals.ts:147-156, reached when a hire_agent approval with budgetMonthlyCents > 0 is approved:

if (budgetMonthlyCents > 0) {
  await budgets.upsertPolicy(
    updated.companyId,
    { scopeType: "agent", scopeId: hireApprovedAgentId, amount: budgetMonthlyCents, windowKind: "calendar_month_utc" },
    decidedByUserId,              // ← forwarded as actorUserId
  );
}

budgets.upsertPolicy uses that actorUserId to populate createdByUserId/updatedByUserId on the budget_policies row, extending the forgery to budget-policy audit columns.

Same pattern in reject and request-revision — server/src/routes/approvals.ts:229 and :257:

router.post("/approvals/:id/reject", validate(resolveApprovalSchema), async (req, res) => {
  assertBoard(req);
  ...
  const { approval, applied } = await svc.reject(id, req.body.decidedByUserId ?? "board", req.body.decisionNote);

approvalService.reject() and requestRevision() (approvals.ts:175 and :201) both write decidedByUserId directly into the approvals row.

Why logActivity is not a mitigation: the route handlers correctly use req.actor.userId ?? "board" when writing to activity_log (e.g. approvals.ts:151, 175, 190, 212, 246, 276), which shows the developer intent was that the deciding user equals the authenticated user. But the authoritative approvals.decidedByUserId column — the value shown to anyone reviewing the approval — is still sourced from the client, so the two records are allowed to diverge and the user-visible attribution is the forged one.

Why this is reachable from a non-admin attacker: actorMiddleware (server/src/middleware/auth.ts:62-98) populates req.actor as type: "board" for any authenticated user (session cookie or board API key); isInstanceAdmin is not consulted by assertBoard. In a multi-user authenticated deployment, any board member of a company can spoof the attribution of any other board member for approvals within that company. In local_trusted deployments there is only a single implicit local-board user, so the exploit has no target — but the code is shipped for both deployment modes.

PoC

Prerequisite: a pending hire_agent approval $APPROVAL_ID in a company where both attacker@corp and ceo@corp are board members of the authenticated deployment. Attacker authenticates with their own session cookie / board API key.

1. Attacker approves as the CEO:

curl -X POST http://localhost:3000/approvals/$APPROVAL_ID/approve \
  -H 'Content-Type: application/json' \
  -H "Cookie: $ATTACKER_SESSION" \
  -d '{"decidedByUserId":"ceo@corp","decisionNote":"LGTM"}'

2. Verify the forged attribution is stored on the authoritative row:

curl http://localhost:3000/approvals/$APPROVAL_ID \
  -H "Cookie: $ATTACKER_SESSION" | jq '.decidedByUserId'
# => "ceo@corp"

3. For hire_agent approvals with budgetMonthlyCents > 0, confirm the budget-policy row is also stamped with the forged user (direct DB read, or via an endpoint that surfaces budget_policies.createdByUserId):

SELECT scope_id, amount, created_by_user_id, updated_by_user_id
FROM budget_policies
WHERE scope_type = 'agent'
ORDER BY created_at DESC LIMIT 1;
-- created_by_user_id = 'ceo@corp'
-- updated_by_user_id = 'ceo@corp'

4. The same body works against /approvals/$APPROVAL_ID/reject and /approvals/$APPROVAL_ID/request-revision.

Note: the activity_log row written alongside the approval still shows the real attacker's userId (correctly taken from req.actor.userId), so a defender who looks at activity_log will see the discrepancy — but the approval UI, the approvals API, and the budget_policies audit columns all display the forged user.

Impact

• Forged governance audit trail. Any board user with access to a company can record approval, rejection, or revision-request decisions under any arbitrary user identifier — including other legitimate board users of that company. Approvals gate security-sensitive actions (agent hiring, which grants execution privileges and assigns a monthly spend budget), and the approvals.decidedByUserId column is the authoritative record of who authorized each decision.
• Budget-policy attribution forgery. For hire_agent approvals that carry a monthly budget, budget_policies.createdByUserId / updatedByUserId are also populated from the same attacker-controlled string, spreading the forgery to spend-authorization audit columns.
• Non-repudiation break. A board user can frame another board user for approving/rejecting a hire, undermining accountability for governance actions. The parallel activity_log entry does preserve the true actor, but any reviewer inspecting the approval itself (not the activity log) will see the forged attribution as fact.
• Scope. Limited to board users who already have company access; does not escalate privileges, does not leak data, and does not change whether the decision itself gets applied. Integrity impact is Low (attribution only, not decision content); confidentiality and availability are unaffected.

Recommended Fix

Drop decidedByUserId from the request schema entirely and derive it server-side from the authenticated actor. Treat req.body.decidedByUserId as untrusted and ignore it.

packages/shared/src/validators/approval.ts:

export const resolveApprovalSchema = z.object({
  decisionNote: z.string().optional().nullable(),
  // decidedByUserId removed — server derives from req.actor
});

export const requestApprovalRevisionSchema = z.object({
  decisionNote: z.string().optional().nullable(),
});

server/src/routes/approvals.ts (apply to /approve, /reject, /request-revision):

router.post("/approvals/:id/approve", validate(resolveApprovalSchema), async (req, res) => {
  assertBoard(req);
  const id = req.params.id as string;
  if (!(await requireApprovalAccess(req, id))) {
    res.status(404).json({ error: "Approval not found" });
    return;
  }
  const decidedBy = req.actor.userId ?? "board";   // trust the session, not the body
  const { approval, applied } = await svc.approve(id, decidedBy, req.body.decisionNote);
  ...
});

Repeat the same const decidedBy = req.actor.userId ?? "board"; substitution at approvals.ts:238 (/reject) and :269 (/request-revision). No change is needed inside approvalService — it already accepts the value as a parameter — and this also ensures the forged value cannot reach budgets.upsertPolicy at approvals.ts:155. Existing callers that currently pass a body decidedByUserId can be updated to stop sending it (it is already effectively redundant with the session).