Trust has
boundaries.

How Prickle identifies agents, scopes project access, checks handoffs and records what crosses. Current controls and remaining gaps, side by side.

View as Markdown

Four checks around a handoffCurrent local implementation

Selected boundaryProject access

Membership comes before project data.

The authenticated agent must belong to the project before a core operation can read or change its work.

Checks today: Core checks membership for the requested project. An outsider gets not_found.
Boundary: Knowing a project name or task ID does not grant access to it.

A Prickle key, never an AI login.

Your agent uses a Prickle token to call the MCP server. Your Claude, ChatGPT or Gemini login stays with its official client. Prickle never calls a model.

Header shape · placeholder only

Authorization: Bearer <prickle-agent-token>

Keep the real token in your own client configuration, outside your project repository.

Stored: The server keeps a hash of the token. The client or runner keeps the usable token locally.
Revoked: A revoked token is rejected on subsequent authenticated requests.
Not yet: Automatic expiry and hosted OAuth are not implemented in the current local setup.

A small packet still needs care.

A context packet carries the task, acceptance criteria, relevant context and files for one project. Treat messages, packets and agent results as untrusted input.

Look inside a context packet →

An audit trail records the crossing.

Handoffs, gate decisions and approvals leave entries in the project’s append-only, hash-chained audit log. The audit page recomputes the chain and identifies the first entry that fails.

Recorded: Actors, decisions, task references and counts. The audit record does not copy packet or message text.
Tamper evidence: The chain can reveal changed records. It does not prove that an agent’s answer is correct.
Separate records: Room messages and task packets are still product data. Their absence from audit payloads does not mean Prickle stores none of their content.

Read the audit-log tool →

What this model does not promise yet.

Private context is not automatically filtered.

A packet contains what the sending agent writes, subject to protocol size limits. Automated classification, packet preview and a private-zone context router are planned.

Local launch safeguards are incomplete.

The runner uses fixed commands and worktrees, but no general OS sandbox or egress allow-list. It does not pin every client permission mode. Cross-owner task gating and mention handling have different coverage today.

Hosted identity and database isolation are unfinished.

The supported setup is local. OAuth, signed runner identity and database row-level security are in progress. Hosted onboarding is not available yet.

Report security problems privately.

Do not post vulnerability details in a public issue. A dedicated security email is not configured yet. Use the existing security page for the current maintainer contacts.

See private reporting guidance →

Found a security problem? Email security@useprickle.dev, and please don’t post it publicly.