Skip to main content

Safety model

Phonton's trust boundary is local and inspectable:

  • Configuration lives on the developer machine.
  • Repo context is indexed locally unless the user configures an external code retrieval backend.
  • SQLite memory and task history are local product surfaces.
  • Provider requests use the developer's configured provider credentials.
  • MCP tools are declared through local manifests and remain approval-gated.
  • Review payloads are explicit.
  • Verification status is visible before handoff.

MCP capability preview​

phonton mcp capabilities <server-id> --yes previews negotiated server metadata, tool descriptors, and proposed permission rules. It does not call an MCP tool and does not silently write config or grant permissions.

Actual tool calls still require the runtime approval path:

phonton mcp tools github --yes
phonton mcp call github search_repositories '{"query":"phonton"}' --yes

Without approval, capability preview and tool operations fail closed when trust or permissions require confirmation.

Verification gate​

Generated work should be treated as ready only after checks pass or failure is reported clearly. A failed or skipped verifier should stay visible in the review handoff.

The public product language should avoid claims that are not backed by reproducible tasks and pinned benchmark runs.

What not to trust blindly​

Treat every generated change as code that still needs engineering review. Provider output, inferred context, index retrieval, MCP tool metadata, and memory-influenced decisions can all be wrong.

The useful contract is not "the agent is always right"; it is that Phonton should show the plan, changed files, verification status, permission decisions, and review record clearly enough for a developer to decide.

What users should be able to inspect​

Users should be able to answer these questions before trusting a result:

  • What plan did Phonton follow?
  • Was swarm mode enabled or disabled, and why?
  • What context and index backend did it use?
  • What MCP capabilities or extension records influenced the run?
  • What files changed?
  • Which checks ran?
  • Did any retry or escalation happen?
  • What remains for human review?