Safety model

This page explains how I try to reduce mistakes when using real APIs with an agent. It’s a description of the safety model, not a guarantee.

Quick links: - Docs: Docs - Tools: Tools - Pricing (not live yet): Pricing - Terms: Terms - Privacy: Privacy - Disclaimer: Disclaimer

What Qwayk is (and isn’t)

Qwayk is a Ghost-based membership site plus a library of small API tools I designed to be safe-by-default for AI-assisted workflows.

Qwayk is not: - a hosted SaaS (I don’t run API actions on your behalf) - a “give an agent your keys and hope” workflow - a promise of rankings, traffic, revenue, or outcomes

The boundary (important)

Qwayk is local-first: - You run the tools on your own machine/CI/server. - You bring your own accounts and API keys. - You choose permissions/scopes and you decide what commands to run.

You are responsible for the outcomes and any changes made through third-party APIs. The tools and docs are provided “as is” and “as available”, to the maximum extent permitted by law.

What I don’t want: - Do not send me your API keys or tokens. I don’t need them for support.

The safety loop (dry-run → review → apply → verify)

Most write-capable commands are designed as a loop:

1) Dry-run (plan) - The tool computes what it would change. - No external writes occur.

2) Review - You review the plan and confirm it matches your intent. - For high-risk actions, I recommend a human review (you, a teammate, or Codex) before applying.

3) Apply - You rerun with explicit write flags. - Typical pattern: --apply, and for higher-risk actions: --apply --yes.

4) Verify - The tool reads back the affected resources when possible and checks expected vs observed state. - If verification fails, the tool treats it as an error (stop and investigate).

5) Receipt - The tool outputs a receipt you can audit later (what was intended, what was done, what was verified).

Extra note: inbox-connected agents (Slack/Discord/WhatsApp)

If your agent can be messaged from an inbox (Slack/Discord/WhatsApp/etc.), treat it as a higher-risk setup.

Why: - inbound messages are untrusted input - group chats can contain prompt injection attempts - “one mistake at scale” is easier when strangers can trigger the agent

Practical guardrails: - allowlist who can talk to the agent (and require pairing/approval for new senders) - require mentions in groups - sandbox non-owner sessions if you can - keep dangerous tools disabled by default (host shell, browser automation, device controls) - still use the Qwayk loop for API work: plan → review → apply → verify

This is not specific to any one runtime. It’s a category of risk: “agent + inbox + tools”.

Two-layer safety (tool + reviewer)

Layer 1 is the tool’s safety behavior (dry-run, refusal, verification, redaction). Layer 2 is the review step: you (or a reviewer like Codex) check that the plan/receipt matches your intent before you apply changes (and after you apply).

For a concrete example of how I treat “verified” vs “not yet verified”, see: - How we write and verify

Refusal rules (what “safe” looks like)

These are examples of refusals that are considered “working as intended”:

• No writes by default. If a command can write, it refuses unless you explicitly allow writes.
• Extra confirmation for risky actions. Destructive or high-blast-radius actions refuse unless you confirm with stronger flags (example: --yes).
• No guessing. If IDs/slugs are missing, ambiguous, or don’t match the fetched state, the tool refuses instead of guessing.
• Scope must be explicit. If a command might affect more resources than expected, the tool refuses until the scope can be validated.
• Stop on verification failure. If a post-apply check fails (mismatch, permissions, unexpected API response), the tool stops and reports it.

Verification (why receipts matter)

Two common verification patterns:

• Read-back verification: re-fetch the resource and confirm the expected fields match.
• “Run again” check (when applicable): re-run a dry-run after apply; the plan should show “0 changes”.

Backups and rollback (when possible)

Some writes can be backed up and rolled back cleanly (example: “save the before JSON, apply the patch, verify, and if needed generate a rollback plan”).

Important: - I don’t promise rollback is possible for every action. - Some actions are effectively irreversible (for example: sending analytics events, spending money, or downloading/licensing assets).

When rollback is possible, I prefer this approach: 1) create a snapshot (before) 2) apply the change 3) verify 4) if verification fails: generate a rollback plan and require explicit apply

Risk levels (how the tool decides how strict to be)

Not all writes are equal.

Examples: - Creating a new draft is usually lower risk. - Editing published content is higher risk. - Batch operations are higher risk. - Anything that spends money or creates account records is high risk (often “irreversible”).

That’s why Qwayk tools use stronger gates for higher risk: - low/medium risk: --apply - high risk: --apply --yes

“Trust over time” (what I recommend)

At the beginning, move slowly: - dry-run - review - apply - verify

As you gain confidence, you can speed up — but I still recommend reviewing anything that touches production, published content, or irreversible actions.

Secrets and redaction

Qwayk tools and docs are written to avoid secret leakage:

• Don’t paste secrets into chat prompts, issue threads, or screenshots.
• Examples use placeholders like <post_id> and <slug>.
• Logs/receipts should redact sensitive fields (tokens, cookies, auth headers).

Supply-chain risk (viral projects)

When a tool goes viral, attackers often ship: - typosquat domains - cloned repos - fake browser extensions/installers

Basic hygiene: - install only from official sources - don’t expose local dashboards to the public internet - if anything seems off, stop and rotate credentials

Third-party boundaries

Qwayk integrates with services I do not control, including:

• site hosting/memberships (Ghost(Pro))
• payments (Stripe, via Ghost(Pro), if enabled)
• analytics (Ghost Analytics and/or Plausible, if enabled)
• code delivery and access control (GitHub)
• DNS/email forwarding (Cloudflare, if used)
• the APIs you connect to (Ghost, WordPress, Freepik, Plausible, etc.)

Third parties can change availability, behavior, rate limits, pricing, or API responses at any time.

Support boundary (best-effort; no SLA)

Support is email-only and best-effort. There is no guaranteed response time and no SLA. If a third-party API changes behavior or breaks compatibility, I may need time to investigate and ship updates (and sometimes a quick fix may not exist).

Email: support@qwayk.com

If you need help, send: - the tool name + version - the command you ran - the redacted plan/receipt output (preferred over raw logs)

International users (mandatory rights)

Qwayk sells globally. Nothing on this page (or in the legal terms) is intended to limit rights that cannot be limited under applicable law.

Example: dry-run plan (JSON)

{
  "tool": "ghost-api-tool",
  "mode": "plan",
  "apply": false,
  "generated_at": "2026-01-21T00:00:00Z",
  "target": {
    "resource": "post",
    "id": "<post_id>"
  },
  "operations": [
    {
      "action": "update",
      "field": "slug",
      "from": "<old_slug>",
      "to": "<new_slug>"
    }
  ],
  "verification_plan": {
    "read_back": true,
    "idempotence_check": true
  },
  "redactions": [
    "token",
    "authorization_header",
    "cookie"
  ]
}

Example: apply receipt (JSON)

{
  "tool": "ghost-api-tool",
  "mode": "apply",
  "apply": true,
  "confirmed": true,
  "generated_at": "2026-01-21T00:01:00Z",
  "target": {
    "resource": "post",
    "id": "<post_id>"
  },
  "result": {
    "status": "success",
    "writes": 1
  },
  "verification": {
    "read_back": {
      "status": "success",
      "observed": {
        "slug": "<new_slug>"
      }
    },
    "idempotence_check": {
      "status": "success",
      "would_change_again": 0
    }
  },
  "redactions": [
    "token",
    "authorization_header",
    "cookie"
  ]
}