Skip to content

Security

MyGreat separates the control plane from the data plane.

  • The web application stores configuration, schedules work, tracks runs, and presents logs and reports.
  • Runners execute the actual transfer operations against source and target systems.

That split matters for every security claim in the product.

Data path and trust boundary

  • The web application does not proxy file contents through the main web request path.
  • File transfer execution happens inside the runner process that runs the job.
  • A runner therefore needs execution-time access to the credentials, tokens, and provider configuration required for that job.
  • If you deploy external runners in your own environment, you control that execution boundary directly.

This means the strongest accurate statement is:

  • MyGreat keeps the web application out of the direct file-transfer path.
  • The runner environment still has access to the data and credentials needed to perform the transfer.

Token and secret storage

  • Storage Repository Open Authorization (OAuth) tokens are encrypted at rest.
  • Sensitive connection values are protected before they are stored.
  • Production environments should use dedicated encryption keys managed through the approved deployment process.

Runner authentication

  • Runner registration tokens are stored in a non-reversible form.
  • Runner authentication tokens are stored in a non-reversible form.
  • The plaintext token value is needed only at issuance time.

Runtime token handling

  • Refresh-token custody now stays with the web application.
  • Runners receive short-lived access material where that contract is supported.
  • Runners can refresh run-scoped access material when expiry approaches.

Important boundary:

  • Some Storage Repository types still require runners to receive other secret material needed for execution, such as static credentials, provider client secrets, or service account credentials.
  • Treat runners as trusted execution components and place them in an environment that matches your security requirements.

Identity and access data

  • Email is the canonical user identity key in the application.
  • The application may also store an optional full name from the identity provider.
  • Tenant membership roles control who can administer the tenant and who can only view selected workspaces.

Logs and diagnostics

  • Sensitive values are redacted before run logs are persisted.
  • Read and export paths apply the same redaction again as a fallback for older rows.
  • Redaction is best-effort defense in depth, not a reason to enable verbose authentication dumps in production.

Deployment choices

You can strengthen your security posture by:

  • running external runners in your own infrastructure
  • granting the narrowest Storage Repository permissions that still let the job work
  • configuring dedicated token-encryption keys
  • avoiding verbose provider-level debug modes during normal operation

See also