Access & Security
Careful access. Controlled changes.
Production systems deserve more care than trial-and-error prompting. This page explains exactly what access we ask for during an incident, what we do with it, and what we will never do.
Our principles
Every incident is handled under the same four rules. They are not negotiable, and they do not change based on how urgent the incident is.
- Least privilege. We ask for the minimum access needed to investigate the reported incident — nothing broader, and nothing "just in case".
- No shared passwords. Access is granted through collaborator invitations, role-based accounts or a supervised screen-sharing session.
- No surprise changes. Nothing is changed in production until you have approved the specific repair, its scope and its price.
- You stay the owner. The application, the accounts, the source code and the data remain yours throughout and after the incident.
Never send us these
Do not send passwords, API keys, access tokens, database connection strings, recovery codes or private customer records through the intake form, by email, or over chat.
If you have already pasted a credential somewhere, treat it as exposed and rotate it. We will tell you the same thing.
If we ever appear to ask you for a password, assume the message is not from us and contact us at hello@apprescuedesk.com before responding. We do not need your passwords to diagnose or repair an incident.
How we request access
Most incidents can be diagnosed with read-level visibility. We start there and only ask for more if the repair genuinely requires it.
Preferred, in order
- Collaborator invitation. You invite our named account to the specific project — Lovable, Supabase, GitHub, Stripe or the relevant provider — with the lowest role that allows the work.
- Role-based or scoped access. Where the provider supports it, a restricted role or a scoped, time-limited key created specifically for this incident.
- Supervised screen sharing. You share your screen and stay in the session. You see every action, and you can stop at any moment. This is often the fastest and safest option for a single-owner project.
What we ask you to avoid
- Sharing your own login credentials with us.
- Granting owner or billing-level access when a lower role is enough.
- Sending exports of production data that contain real customer information.
Not sure what access is needed? Tell us in the intake that you need help identifying it. We will name the exact permissions, on which services, and explain why each one is required before you grant anything.
How we make changes
Diagnosis and repair are deliberately separated. The $99 diagnosis is an investigation — it does not authorise us to modify your production system.
- We investigate first. Symptoms, recent changes, logs, configuration and connected services, before touching anything.
- You approve the repair. You receive the likely root cause, the proposed change and a fixed or capped price. Work begins only after you say yes.
- We capture the current state. Where it is possible and meaningful, we back up, duplicate or document the affected configuration, schema or code before a material change.
- We test in the safest available environment. Preview, staging or a branch where one exists; production only when there is no alternative and you have approved it.
- We record what changed. You receive a short written summary of every change made and how the repaired workflow was verified end to end.
If an emergency repair looks risky — for example, anything touching live customer data — we will say so, describe the risk, and wait for an explicit decision from you rather than proceed on our own judgement.
What we see and store
Investigating a failing login flow or a broken payment webhook sometimes means we encounter real data — a user record, an email address, a transaction ID. We treat this as incidental exposure, not as a dataset.
- We do not copy, export or retain your production database.
- We do not use your data, code or business information to train models or for any purpose other than resolving your incident.
- We keep only what the incident record needs: your intake answers, our notes, the diagnosis and the change summary.
- Screenshots and recordings you upload are stored with the incident record and deleted on request.
What we collect, how long it is kept and how to have it deleted is described in the Privacy Policy.
After the incident
Access is temporary by default. When an incident is closed:
- We ask you to remove our collaborator access, or we remove ourselves where the platform allows it.
- Any temporary or scoped credential created for the incident should be revoked. We will remind you which ones.
- If a credential was exposed as part of the failure — an expired key, a secret committed to a repository — we tell you clearly that it must be rotated, and which one.
You should not have to remember to clean up after us. The change summary at the end of every incident lists the access to revoke.
Honest limitations
App Rescue Desk is an independent incident service run at pilot scale. It is not a certified security vendor, and this page describes a working process rather than a compliance programme.
- We do not hold SOC 2, ISO 27001 or comparable certification.
- We cannot secure or repair infrastructure controlled by a third-party provider such as Lovable, Supabase or Stripe.
- We do not guarantee recovery of deleted or corrupted data, and a potential data-loss incident may need a separate scope before anything is changed.
- We are an independent service and are not affiliated with or endorsed by any platform we work with.
If your organisation requires a signed NDA or a data processing agreement before granting access, contact us before opening an incident.
Report a security issue
If you believe you have found a vulnerability in this website, or you think an access grant related to your incident has been misused, email hello@apprescuedesk.com with the details.
We will acknowledge the report during published support hours and tell you what we intend to do about it. Please do not test against systems you do not own.