On this page

1. Security overview

Spek is operated by RELOAD TECHNOLOGIES - FZCO in Dubai, United Arab Emirates. We use layered technical and organizational safeguards to protect accounts, workspace data, store credentials, files, and publishing operations.

These safeguards work alongside the protections customers maintain for their accounts, devices, team access, and connected providers. The Terms of use govern your use of the Service.

2. Store connections

Spek connects to App Store Connect only through its supported, token-authenticated API. A workspace's private .p8 key is used to sign an ES256 JSON Web Token for official API requests.

Store access is authorized with provider-issued API credentials, while Apple ID passwords and authenticated browser sessions remain with Apple. Customers control each credential's permissions and can revoke it directly with Apple.

3. Credential protection

Store credentials are maintained separately for each workspace and are not shared across customer workspaces. Credential material is protected at rest with AES-256-GCM authenticated encryption and is context-bound to the relevant workspace and provider record.

Credentials are decrypted only when required to authorize a requested API operation. Customers should grant the minimum provider permissions required, rotate credentials when personnel or responsibilities change, and revoke a credential at the provider immediately if compromise is suspected.

4. Identity and sessions

Spek uses secure session handling, with Service cookies configured as Secure and SameSite=Lax. Multi-factor authentication is available to users and enforced for sensitive administrative and account-deletion actions.

Users remain responsible for protecting their email accounts, devices, authenticators, recovery methods, and sign-in credentials. A workspace administrator should remove access promptly when a user no longer needs it and should not permit accounts or authentication factors to be shared.

5. Workspace isolation

Access to customer data and sensitive actions is checked against the authenticated user's workspace membership and role. Database access controls further isolate workspace records, while workspace owners and administrators manage membership and role assignments.

6. Application safeguards

Spek applies browser security policies, request-origin validation, rate limits, and destination validation to sensitive operations.

Uploaded media is checked for supported format, file size, and image dimensions before processing.

7. AI and files

Files used for AI-assisted processing are stored privately and made available only through authenticated workspace access or time-limited links required for processing.

Customers should submit only information needed for the requested task and should not place passwords, private keys, payment-card data, or unrelated sensitive personal data in prompts, instructions, or uploaded files. How Spek handles personal data and service providers is described in the Privacy policy.

8. Publishing integrity

AI-assisted recommendations and generated material are prepared as drafts. Publishing to the App Store requires a separate action by an authorized user. Customers are responsible for reviewing the target app, locale, content, and provider state before approving a change.

Spek coordinates publishing operations so overlapping requests do not overwrite or misreport a newer request. Apple retains final control over processing App Store submissions.

9. Customer responsibilities

Customers and authorized users should:

  • connect only accounts and credentials they are authorized to use, with the minimum permissions reasonably required;
  • use unique sign-in credentials, enable multi-factor authentication, and protect recovery methods and devices;
  • review workspace membership and administrator access and remove access promptly when it is no longer required;
  • rotate or revoke provider credentials after suspected exposure or a material change in personnel or responsibility;
  • review every draft and destination before publishing and monitor provider accounts for unexpected activity; and
  • report suspected unauthorized access or security issues promptly without sending passwords or private keys by email.

10. Service providers

Spek uses selected infrastructure, authentication, app-store API, email, and AI providers to operate the Service. Provider access is limited to the services and information needed for the relevant function.

Customers retain direct control of their Apple store credential and third-party authentication accounts and can review, rotate, or revoke them with the relevant provider.

11. Incident handling

Reports or signals indicating a potential security incident are evaluated so proportionate containment, investigation, and remediation steps can be taken. If a confirmed incident creates a notification obligation under applicable law or a written agreement, Spek will provide the required notice to affected parties or authorities.

If you suspect that a Spek account or connected store credential has been compromised, contact us promptly and independently revoke or rotate the affected provider credential. Include the affected workspace and a description of the issue, but do not include a password, private key, service-account file, or active session token in the report.

12. Responsible disclosure

We welcome good-faith reports about a suspected vulnerability in Spek. Send a clear description, affected URL or feature, reproducible steps, impact, and relevant evidence to hello@spek.app. Do not include secrets or personal data that are unnecessary to explain the issue.

Any security research must comply with these conditions:

  • test only accounts, workspaces, and data you own or have express written authorization to test;
  • do not access, retain, alter, disclose, or destroy another person's data, and stop immediately if unexpected access occurs;
  • do not use denial-of-service, malware, spam, social engineering, phishing, physical attacks, or disruptive automated testing;
  • do not degrade the Service, evade usage controls, establish persistence, or use a finding for extortion or commercial leverage; and
  • keep the issue confidential unless and until Spek gives written permission to disclose it.

Research must comply with applicable law and these conditions. Testing outside this scope requires Spek's prior written authorization.

13. Security contact

Security questions and reports may be sent to RELOAD TECHNOLOGIES - FZCO, Dubai, United Arab Emirates, at hello@spek.app, or through our contact page.

14. Common questions

How do account permissions and store permissions work together?

Your workspace role sets what you can see and change in Spek. The store also has its own rules. Its API key must allow the action, and the app must be in the right state. Both sets of checks apply. For example, you may be able to read a draft while the store has locked that version. A viewer can read results without being able to change the store connection. If an action fails, check the workspace, app and role first. Then read the store's error message. Ask the person who manages access to review the issue. Do not grant wider access just to clear an error.

How should I read this policy alongside the security overview?

Start with the overview for a short guide to how Spek handles access. Use this policy for the full detail on each control, your role and how to report an issue. Read the section that covers your question. If a term is unclear, contact Spek before you rely on it. A logo or a short feature note is not proof of a certification. It does not add a promise to your contract. The Privacy policy covers how personal data is handled. The Cookie policy covers data kept in your browser. These pages serve different needs and should be read together when you review the service.

What should I include in a suspected security-issue report?

Tell us which page or feature is affected. Describe what you saw, what you expected and how the issue could cause harm. Add only the evidence needed to explain it. Follow the reporting rules in this policy. Test only accounts and data you have the right to use. Stop if you gain access you did not expect. Do not send private keys, passwords, session tokens or other people's personal data. Use the contact route listed here. Keep the report focused on the issue so the team can review it without making more copies of private material.

Does a security report replace revoking an exposed store key?

No. A report does not turn off a key or change store access. If a key may have been exposed, use the store provider's own controls to revoke or replace it. Then check the affected connection in Spek. Tell the team which workspace and store account are involved, but leave the secret out of the message. Note which apps use that connection. After the key has changed, check that those apps can still reach the store as intended. Also review work that was waiting on the connection. Sending a report helps the team look into the issue; it does not perform those account changes for you.

How should a team review access when responsibilities change?

Check the person's role in each Spek workspace they used. Then check their access to the store account and any other service. Removing someone from one workspace does not revoke every key they may hold elsewhere. Each service has its own controls. Keep a clear record of who owns each app and which client it belongs to. Use each person's own account where appropriate. Do not put private keys in handoff notes or team messages. The workspace and store connection guides explain the controls in Spek. Use the store provider's own guidance for changes to its accounts and keys.

What is the difference between service availability and account security?

The status page shows whether shared services are working and lists published incident updates. It does not confirm that every action on your account was allowed. An account may have a key or access problem while the service is healthy. If you suspect a security issue, use the security contact in this policy. Name the workspace and explain what you saw. A failed store action is not always a security incident. It may be due to your role, the store key or the app's current state. Read the actual error message before you decide which kind of help you need.

Can a support conversation be used to share private credentials?

Keep private keys and passwords in the account controls made for them. Do not paste them into a support message. Explain the issue and give the team enough context to find the affected workspace or app. A connection name or other non-secret label can help. The private key file, password or live session token is not needed to describe which account has a problem. Check any screenshot before you send it so it does not expose those values. Use the contact route and reporting steps in this policy. A clear report can be useful without giving another person the means to sign in.