# Security and Data Handling (/reference/security-and-data-handling) This page is the practical trust reference for Mogplex. Use it when you need to know which credential is involved, where sensitive state lives, what appears in logs or API responses, and what to capture safely when debugging. ## The Main Trust Boundaries [#the-main-trust-boundaries] Mogplex crosses several systems: * GitHub OAuth and the Mogplex GitHub App for identity, repo discovery, and webhook-backed routing * managed sandbox access for preview runtimes * managed model access for hosted execution * Slack OAuth and webhooks for Slack conversations and repo-agent starts * REST and MCP connections for tools agents can call * personal access tokens for CLI, scripts, and the public v1 API * sandboxes for executing repo work When debugging, identify which boundary failed before rotating credentials or changing agent prompts. ## Authentication And Tokens [#authentication-and-tokens] Mogplex personal access tokens use the `mog_...` prefix. The token value is shown once when created and is stored server-side as a SHA-256 hash. Current public API scopes are: | Scope | Allows | | ------- | -------------------------------------------------------------------------- | | `read` | List and detail endpoints such as repos, runs, sandboxes, and MCP servers. | | `write` | Mutations such as starting or cancelling runs. | API tokens can be revoked from Settings. Expired, revoked, malformed, or unknown tokens resolve as unauthenticated. Valid tokens are also rate-limited per key before route handlers proceed. Use [API Authentication](/web/api/authentication) for request examples and scope behavior. ## Managed Model Access [#managed-model-access] Hosted model execution is billed and authorized through Mogplex account access. Users do not need external model credentials for hosted runs. If a model cannot be used, debug the account plan, model catalog, and entitlement state instead of rotating local shell credentials. ## Connections And MCP Secrets [#connections-and-mcp-secrets] Connections are external tools Mogplex can call. Connection credentials are encrypted server-side before storage. MCP server secrets and provider-backed connection tokens are resolved only when the connection or MCP sync path needs them. Two details matter operationally: * A healthy connection in Settings can still be excluded from a specific repo. * `GET /api/v1/mogplex/mcp/servers` returns resolved MCP config for a PAT caller, which can include decrypted headers or env values. Treat MCP server responses like a `.env` file. Do not paste them into issues, chat logs, CI output, or screenshots. Read [Connection Scope and Overrides](/web/guides/connection-scope-and-overrides) and [MCP Servers API](/web/api/mcp-servers) for the exact behavior. ## Webhooks [#webhooks] GitHub and Slack use separate webhook verification paths. | Source | Verification | | ------ | ------------------------------------------------------------ | | GitHub | HMAC signature against the configured GitHub webhook secret. | | Slack | Slack request signature plus timestamp/body checks. | Slack install state is also signed, nonce-checked, and time-limited during the OAuth callback. Slack account-link URLs are bearer links, so treat the raw link as sensitive until it expires or is consumed. ## Event And Audit Data [#event-and-audit-data] Mogplex stores runtime events so users can inspect what happened after a run starts. Run-event payloads are sanitized before returning through the public events API. Sensitive keys are redacted, long strings are truncated, and deeply nested or oversized payloads are capped so event data is useful without becoming a raw secret dump. Team audit payloads also redact fields whose names look like prompts, tokens, API keys, credentials, passwords, or secrets. Even with those controls, support requests should include identifiers and the first error string, not raw credentials, full env dumps, or full private prompts. ## Sandboxes [#sandboxes] Sandboxes run repository work in an isolated runtime, but they are still allowed to interact with the repo, configured environment, connected tools, and model provider selected for the run. Before starting sandbox work, confirm: * the repo and branch are correct * root directory, install command, dev command, and port are correct * the environment source is intentional * managed sandbox access is available for the account * optional linked Vercel project metadata is intentional when used * Slack or GitHub routing is starting work under the user you intend Use [Sandbox Setup Checklist](/guides/sandbox-setup-checklist) before treating a sandbox failure as a model or agent bug. ## What To Share Safely [#what-to-share-safely] Good support artifacts: * repo owner/name and Mogplex repo ID * run ID, sandbox ID, automation ID, or API request ID * GitHub App installation owner and coverage state * Slack workspace name and channel link state * first error message and timestamp * model id and provider name * whether the request came from CLI, API, Slack, GitHub, Trigger, Assignment, or Automation Avoid sharing: * `mog_...` tokens * Slack account-link URLs * decrypted MCP server config * `.env` files * OAuth tokens * full private prompts or proprietary code excerpts unless needed and approved ## Rotation Checklist [#rotation-checklist] Rotate or revoke the smallest credential that matches the risk: * Revoke a Mogplex PAT when API or CLI access is exposed. * Reconnect GitHub or Slack when OAuth state is wrong or the workspace owner changes. * Recreate a connection when an external REST or MCP credential was exposed. * Stop or delete a sandbox when runtime state may contain sensitive files. Then re-test the exact owning surface before changing agent prompts or routing. ## Read Next [#read-next]