fix(tasks): omit params from the list-tasks response

[gabrycina]

Summary

GET /tasks (list) returned the full task object, the same TaskResponse the single-task GET returns, so every item included params: the arbitrary, caller-supplied create-time payload. Callers routinely stash sensitive material there (credentials, tokens, PII). Because the list is broadly scoped, that turned a single list call into a bulk read of every task's params.

This makes the list a lean summary (TaskSummary, no params) and keeps the full record on the single-task fetch. A list response should carry only what a collection view needs; the full record belongs on the item fetch.

Scope: the list response only. Behavior of GET /tasks/{id}, GET /tasks/name/{name}, POST/PATCH, and the domain/repository layers is unchanged.

Endpoint contract (after)

flowchart TD
    Client(["Client"])
    Client -->|"GET /tasks (list)"| Summary["list of TaskSummary<br/>id, name, status, status_reason,<br/>created_at, updated_at, cleaned_at,<br/>task_metadata, agents"]
    Client -->|"GET /tasks/{id} (detail)"| Full["TaskResponse<br/>(all summary fields) + params"]
    Summary -. "need params for one task?" .-> Client
    Client ==>|"fetch that id"| Full

    classDef lean fill:#e8f5e9,stroke:#43a047,color:#1b5e20;
    classDef full fill:#fdecea,stroke:#e53935,color:#b71c1c;
    class Summary lean;
    class Full full;

Loading

• List returns the lean summary for every task, cheap, and safe to return in bulk.
• Detail still returns everything, including params, and is fetched one id at a time (and is subject to the same per-request authorization as before).

Schema

TaskSummary is a deliberate allowlist. It is a standalone model (not a subclass of Task) so params cannot leak in via inheritance, and because BaseModel ignores extra fields, validating a TaskEntity (which still carries params) into a TaskSummary drops params at serialization.

classDiagram
    class TaskSummary {
      +id
      +name
      +status
      +status_reason
      +created_at
      +updated_at
      +cleaned_at
      +task_metadata
      +agents
    }
    class TaskResponse {
      +id
      +name
      +status
      +status_reason
      +created_at
      +updated_at
      +cleaned_at
      +task_metadata
      +agents
      +params
    }
    note for TaskSummary "list response, omits params"
    note for TaskResponse "single-task detail, includes params (may carry credentials or PII)"

Loading

The two share the same safe fields; only TaskResponse exposes params.

Before / after

// BEFORE - one item in the list response
{
  "id": "0c1f8e2a-…",
  "name": "…",
  "status": "RUNNING",
  "created_at": "…", "updated_at": "…", "cleaned_at": null,
  "task_metadata": { "display_name": "…" },
  "params": {
    "auth_token": "…",        // whatever the caller stored at create time,
    "user_email": "…",        // e.g. credentials and PII, returned in bulk
    "…": "…"
  }
}

// AFTER - same item, lean summary (no params)
{
  "id": "0c1f8e2a-…",
  "name": "…",
  "status": "RUNNING",
  "created_at": "…", "updated_at": "…", "cleaned_at": null,
  "task_metadata": { "display_name": "…" },
  "agents": null
}

What changes across a whole list call:

flowchart LR
    subgraph Before["Before: GET /tasks"]
        direction TB
        b["N tasks × full object<br/>N × params (creds/PII)"]
    end
    subgraph After["After: GET /tasks"]
        direction TB
        a["N tasks × lean summary<br/>0 × params"]
    end
    Before --> After
    classDef bad fill:#fdecea,stroke:#e53935,color:#b71c1c;
    classDef good fill:#e8f5e9,stroke:#43a047,color:#1b5e20;
    class Before bad;
    class After good;

Loading

Field reference

Field	In list (TaskSummary)	In detail (TaskResponse)	Notes
id	yes	yes	System-assigned task id
name	yes	yes	Optional, caller-supplied
status / status_reason	yes	yes	Lifecycle state
created_at / updated_at / cleaned_at	yes	yes	Timestamps
task_metadata	yes	yes	Display / routing / filter metadata (the list can filter on it)
agents	yes	yes	Populated only with ?relationships=agents
params	no	yes	Arbitrary create-time payload; may carry credentials/PII

Breaking change and migration

Removing params from the list is an intentional, security-motivated breaking change for typed consumers that read params off a list item.

flowchart TD
    Q{"Reading params off a list item?"}
    Q -->|No| OK["No change needed"]
    Q -->|Yes| Fix["Fetch the task by id, then read params"]
    classDef ok fill:#e8f5e9,stroke:#43a047,color:#1b5e20;
    class OK ok;

Loading

The SDKs are generated from agentex/openapi.yaml (Stainless), so the list-item type regenerates automatically on merge; consumers pick up the change when they bump the SDK. This PR regenerates and commits openapi.yaml (the list_tasks 200 now references TaskSummary), which the openapi-spec CI check enforces.

Consumers touched in this PR

• Developer UI (agentex-ui): createTaskName fell back to params.description for the task label; switched to the task name (task_metadata.display_name → name → "Unnamed task"). No other code reads params off a listed task.

Implementation

• src/api/schemas/tasks.py: add TaskSummary (allowlist, omits params).
• src/api/routes/tasks.py: list_tasks response_model=list[TaskSummary], returns TaskSummary.model_validate(...) per entity. Single-task routes unchanged.
• agentex-ui/lib/task-utils.ts + test: name-derivation fallback.
• agentex/openapi.yaml: regenerated.

Follow-ups / known limitations

• task_metadata is still free-form (dict[str, Any]) and partly caller-influenced. By convention it holds non-secret display/routing/filter metadata (and the list can filter on it), so it stays in the summary. If we want the list to be strict rather than convention-safe, a follow-up could give task_metadata a typed shape so callers cannot stash sensitive data that the list would surface.
• Concurrency is out of scope: unrelated to this change; not touched here.

Test plan

flowchart LR
    subgraph list["GET /tasks"]
        L1["task present in list"]
        L2["params NOT in item"]
    end
    subgraph get["GET /tasks/{id}"]
        G1["params present + correct"]
    end
    list --> get

Loading

• Integration (tests/integration/api/tasks/test_tasks_api.py): list omits params for both populated- and null-params tasks; the schema test asserts params absent on list items; single-task GET (by id and by name) still returns params.
• UI unit (agentex-ui/lib/task-utils.test.ts): task-name derivation from display_name / name.
• openapi.yaml regenerated and committed.
• Verified directly that TaskSummary.model_validate({... "params": {...}}) drops params while TaskResponse keeps it; ruff clean.

Greptile Summary

This PR fixes an information-disclosure issue where GET /tasks (list) returned the full TaskResponse — including params, an arbitrary caller-supplied payload that can hold credentials and PII — for every task in a single call. The fix introduces a standalone TaskSummary allowlist model that omits params, updates the list route's response_model, regenerates the OpenAPI spec, and adapts the UI's task-name derivation to use task.name instead of params.description.

• TaskSummary is a standalone BaseModel (not a subclass of Task) so params cannot leak via inheritance; Pydantic v2's default extra='ignore' ensures model_validate silently drops the field.
• Single-task routes (GET /tasks/{id}, GET /tasks/name/{name}, lifecycle endpoints) are unchanged and continue to return params.
• UI now derives the task label from task_metadata.display_name → task.name → 'Unnamed task' instead of the now-absent params.description.

Confidence Score: 5/5

Safe to merge — the change is a targeted, well-scoped fix that strips a sensitive field from a bulk endpoint without touching any single-task or write paths.

The allowlist model is correctly designed as a standalone BaseModel (no Task inheritance), and Pydantic v2's default extra-field behaviour ensures params is silently dropped at serialization. The custom BaseModel in model_utils.py does not set extra='allow', so there is no bypass path. Single-task routes, lifecycle endpoints, and the domain layer are untouched. Integration tests verify the before/after contract for both populated- and null-params tasks, and the UI fallback is covered by unit tests.

Files Needing Attention: No files require special attention.

Important Files Changed

Filename	Overview
agentex/src/api/schemas/tasks.py	Adds TaskSummary as a standalone BaseModel allowlist that omits params; correct approach — no inheritance from Task prevents accidental field leakage.
agentex/src/api/routes/tasks.py	list_tasks response_model changed to list[TaskSummary] and serialization updated; single-task and lifecycle routes are correctly unchanged.
agentex-ui/lib/task-utils.ts	createTaskName fallback updated from params.description to task.name; correct adaptation to the new TaskSummary shape.
agentex-ui/lib/task-utils.test.ts	Tests updated to cover the new name-derivation logic (display_name, prefix stripping, task.name fallback, Unnamed task); coverage looks complete.
agentex/tests/integration/api/tasks/test_tasks_api.py	Integration tests flipped to assert params absent from list items and still present on single-task GET; covers both populated and null-params tasks.
agentex/openapi.yaml	list_tasks 200 response now references TaskSummary; TaskSummary schema added with correct allowlist fields matching the Python model.

_{Reviews (2): Last reviewed commit: "Merge branch 'main' into fix/list-tasks-..." | Re-trigger Greptile}

[github-actions]

✱ Stainless preview builds

This PR will update the agentex-sdk SDKs with the following commit messages.

openapi

feat(api): add TaskSummary response to list tasks

python

fix(api): remove params field from task list response

typescript

fix(api): remove params field from tasks list response

✅ agentex-sdk-openapi studio · code

Your SDK build had at least one "note" diagnostic.
generate ✅

⚠️ agentex-sdk-typescript studio · code

Your SDK build had at least one "warning" diagnostic.
generate ⚠️ → build ✅ → lint ✅ → test ✅

npm install https://pkg.stainless.com/s/agentex-sdk-typescript/bd458e3a26effb3a7c420e89206c101ceef1adb4/dist.tar.gz

⚠️ agentex-sdk-python studio · code

Your SDK build had a failure in the lint CI job, which is a regression from the base state.
generate ⚠️ → build ✅ → lint ❗ → test ✅

pip install https://pkg.stainless.com/s/agentex-sdk-python/152bc75b242c2ff4179e0cfac0f33edbc6bcae38/agentex_client-0.20.0-py3-none-any.whl

---

This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-07-27 17:58:34 UTC

[rpatel-scale]

Shouldn't this be maintained on the agent side instead? The agent should know which tasks its writing to or able to write to instead of the task maintaining which agents are associated to it.

[gabrycina]

This field isn't introduced here. TaskResponse already carries agents (populated only with ?relationships=agents), and TaskSummary mirrors that existing shape so list and detail stay consistent. Whether the association should live agent-side is a pre-existing design question that's orthogonal to this fix, so I'd keep it out of scope here. Happy to open a separate issue to revisit it if you want.

[rpatel-scale]

Maybe an integration test would be nice to make sure the fields we deem "sensitive" are omitted (in the case that someone adds them back later). Can be followup

[gabrycina]

This is already covered in the PR: test_list_tasks_omits_params_in_response and test_list_tasks_omits_params_for_null_params_task assert params is absent from list items (populated and null cases), and test_get_task_by_id_includes_params_in_response verifies the single-task fetch still returns it. If you want the regression caught one layer earlier, I can also add a model-level guard asserting "params" not in TaskSummary.model_fields.

[danielmillerp]

For future reference, enabling FGAC and authz would fix this. Gating access is an auth concern not app level, task params is not the right location for this.

Also if it is sensitive it should live in secrets microservice.

[danielmillerp]

Also to be clear, if someone gets the task ID and does a GET this issue will still be exposed.

[gabrycina]

For future reference, enabling FGAC and authz would fix this. Gating access is an auth concern not app level, task params is not the right location for this.

Also if it is sensitive it should live in secrets microservice.

Agentex doesn't seem to have a way to do OBO without saving this params in the task. What is your advice?