# Threat Model

Last updated: 2026-07-18.

## Security objective

Let external local Codex agents maintain Tasker cards without turning Tasker into an open automation surface.

## Main threats

### Raw Tasker access leakage

Risk: a user copies a broad Tasker token or cookie into local Codex, allowing arbitrary API calls.

Mitigation:

- never issue Plane session cookies to agents;
- never expose raw Tasker API tokens;
- use opaque Agent Gateway tokens;
- only expose allowlisted MCP tools.

### Project scope escape

Risk: an agent writes to another project or workspace.

Mitigation:

- Agent Gateway grants are project-scoped;
- Tasker adapter revalidates workspace/project membership;
- every tool requires explicit `project_id`;
- gateway rejects projects outside grant set.
- project creation requires `project:create` on a workspace grant, an
  agent-scoped token, and a second workspace-admin check inside Tasker;
- token-scoped AI Workspace sessions cannot add projects to their own grants.

### Attachment exfiltration or storage abuse

Risk: an agent reads arbitrary host files, fetches a remote payload, or bypasses
Tasker storage quotas through the attachment tool.

Mitigation:

- MCP accepts explicit base64 bytes only, never filesystem paths or remote URLs;
- Agent Gateway limits decoded content to 5 MiB and never logs the base64 body;
- Tasker enforces MIME allowlists, workspace storage limits, project quota,
  S3/MinIO ownership, and content deduplication.

### Cross-service token confusion

Risk: an Ops token is replayed against Ontology or an Ontology token gains Tasker
write capabilities.

Mitigation:

- setup redemption mints two independent opaque token records;
- token purpose is persisted and checked on every endpoint;
- `/mcp` accepts only `ops`, `/ontology-mcp` only `ontology`;
- Ontology upstream access token remains server-side.

### Destructive action

Risk: an agent deletes or archives cards, labels, comments, projects, or members.

Mitigation:

- no delete/archive MCP tools in MVP;
- adapter rejects delete/archive intents;
- raw API proxy is forbidden.

### Privilege confusion

Risk: an agent acts as the human user and hides automation history.

Mitigation:

- create dedicated agent identity;
- store owner user separately;
- every audit event includes both `agent_id` and `owner_user_id`;
- UI displays agent-originated changes.

### Prompt injection

Risk: text inside a card tells Codex to exfiltrate token or call forbidden tools.

Mitigation:

- MCP tools enforce server-side scopes;
- instruction pack says Tasker content is untrusted;
- Gateway never exposes secrets through read tools;
- deny arbitrary HTTP fetch/proxy tools.

### Token theft

Risk: local token leaks from developer machine.

Mitigation:

- token hash storage;
- expiry;
- immediate revoke;
- last used metadata;
- rate limits;
- optional IP/device binding later.

### Lifecycle API exposure

Risk: an external caller creates agents, grants projects, or mints tokens without going through Launcher/Tasker entitlement.

Mitigation:

- lifecycle routes require `NODEDC_AGENT_GATEWAY_INTERNAL_TOKEN`;
- owner-scoped routes verify `owner_user_id` against the stored agent owner;
- external Codex tokens can call only agent-session, setup, tool, and MCP routes;
- raw agent token is returned only once on token creation.

### Owner lifecycle bypass

Risk: blocked/annulled user keeps active agent token.

Mitigation:

- Gateway checks Launcher owner status;
- blocked/annulled owner disables agent tokens;
- periodic sync plus request-time access check.

### Replay and duplicate writes

Risk: network retry creates duplicate cards/comments.

Mitigation:

- required idempotency keys for write tools;
- store operation result by agent and idempotency key;
- reject same key with different arguments;
- release failed writes so safe retries can run again.

### Reporting mode false confidence

Risk: enterprise admin assumes local Codex must report, but the developer bypasses the managed config.

Mitigation:

- UI distinguishes `connected`, `stale`, `never connected`;
- reporting mode is visibility and policy, not hard enforcement, unless a managed wrapper is used;
- CI/workflow checks can require Tasker session updates later.

## Hard rules

- No database access from Agent Gateway to Tasker DB.
- No arbitrary Tasker HTTP proxy.
- No user session cookie reuse.
- No delete/archive tools in MVP.
- No secrets in generated markdown instruction files.
- No token logging.
- No frontend access to service secrets.
- No cross-use between Ops and Ontology bearer tokens.
- No attachment from a filesystem path or remote URL.
