Credentials
How connector tokens are stored.
OAuth tokens are stored encrypted, never in plain text. Token exchange for most connectors happens on PawOS’s backend, so a client secret is never present on your machine at all.
Product disclosure
This page documents the current PawOS behavior for Credentials. It is intended to disclose what users can see and use, what permissions are required, what evidence is recorded, and what limitations remain.
This disclosure is part of the PawOS documentation for Credentials. It is written to make the product behavior understandable before a user relies on it, pays for it, connects an account, approves a plan, or authorizes a machine-affecting action.
What users see
- Users see confirmation gates, permission prompts, connector authorization screens, blocked-command messages, filesystem boundaries, credential status, and system-action warnings.
- Security documentation should explain which process enforces the rule and what the user should expect on screen.
- When an action is blocked, users should see an explanation rather than a silent no-op.
What PawOS does
- The main process owns execution of security-sensitive actions; the renderer requests actions through typed IPC and preload boundaries.
- Command execution uses allowlisted command structures and avoids raw shell-injection paths for supported command runners.
- Credentials are handled through connector-specific storage and authorization flows rather than being pasted into arbitrary prompts.
Permissions and boundaries
- Plan approval, model confidence, companion personality, or task urgency cannot bypass confirmation gates.
- Actions that affect files, commands, git state, installs, system PATH, deployments, connectors, or external services require the relevant authorization path.
- The docs must not imply that PawOS can safely perform arbitrary destructive work without user or organization approval.
Evidence and records
- Security-sensitive actions should leave evidence of the request, confirmation requirement, result, and failure reason when blocked.
- Credential and connector claims should be limited to configured providers and scopes that actually exist.
Limitations and user responsibility
- No local security design removes the user responsibility to review proposed plans, confirmations, diffs, commands, deployments, and connector side effects.
- External provider security, account policy, and operating-system permission prompts remain outside PawOS control.
Warning
PawOS can assist with planning, coding, automation, connectors, billing flows, and system operations, but the user remains responsible for reviewing plans, confirmations, diffs, command effects, connector side effects, billing actions, and final outputs before relying on them.
Related