Control is a system, not a confirmation dialog.
Shopkeeper combines organization-scoped access, protected provider credentials, explicit action boundaries, and a reviewable operating record.
Product security model
Protect access. Bound actions. Preserve the record.
Workspace scope
Organization-bound access
Provider access
Encrypted stored credentials
Action boundary
Modes, permissions, and limits
Operating record
Proposal through outcome
Data stays tied to the owning workspace
Store, customer, conversation, and action access follows the organization scope.
Exports provide a path out
Workspace and customer data export as JSON; action history exports as CSV.
Protect the connection and the work it can perform.
Security on an action-taking support product includes who can access a workspace, what connected permissions enable, which actions are allowed, and what remains inspectable afterward.
Scope access
Keep product access and connected commerce data tied to the organization that owns the workspace.
- Organization-bound application access
- Workspace-scoped customer and store context
- Provider permissions requested for product functions
- Connected credentials encrypted before storage
Constrain work
Define what can draft, send, ask, execute, or stop before a customer request reaches an action.
- Draft only, Ask first, and Trusted modes
- Tool and action permissions
- Refund cap and eligibility checks
- Block or escalate outside policy
Keep evidence
Make consequential operating decisions and tool outcomes reviewable after the conversation moves on.
- Proposed action and source thread
- Merchant decision and approver
- Execution status and result
- JSON and CSV export paths
The boundary follows the action through its lifecycle.
- 01
Authorize access
Connect the organization and providers needed for the selected product functions.
- 02
Configure limits
Choose the autonomy mode, tool permissions, financial limits, and store policies.
- 03
Gate the action
Check eligibility and pause consequential or exceptional work when approval is required.
- 04
Record the result
Keep the proposal, decision, execution status, and customer output available for review.
Connect deliberately and review the boundary.
The merchant chooses the organization workspace, provider connections, product permissions, autonomy mode, and operating limits. Security claims here stay grounded in those product controls.
- An organization workspace with authorized members
- Only the provider connections required for the workflow
- Reviewed action permissions, refund cap, and autonomy mode
- Store policies plus a merchant escalation and approval path
Follow the product story.
The practical questions.
- Is Shopkeeper security-certified?
- This page does not claim an external audit or certification. It describes intended and implemented product controls such as organization scope, encrypted stored provider credentials, action limits, review history, and exports.
- How are connected-provider credentials stored?
- Connected-provider credentials are encrypted before storage. Access is used for the product functions the merchant authorizes through the relevant provider connection.
- Can Shopkeeper make any Shopify change once connected?
- No. Supported tools, Shopify eligibility, workspace permissions, autonomy mode, action-specific limits, and approval requirements all constrain the work. Unsupported or blocked actions should stop or escalate.
- What is kept in the action history?
- The history can tie the source request, proposed work, execution mode, merchant decision, tool status, timing, customer-facing output, and completed result together for review.
- Can workspace data be exported?
- Workspace and customer data can be exported as JSON, and action history can be exported as CSV. The export remains scoped to the organization workspace.
- Where can I read the legal data-use terms?
- The public Privacy Policy describes data use and handling in legal terms. This page focuses on the product's access, control, audit, and export model.